Это разумный для использования станд.:: basic_string <t> как непрерывный буфер при предназначении для C++ 03?

Короче говоря, он оптимизирован CLR (за вычетом памяти).

Кроме того, сравнение в верхнем регистре более оптимизировано, чем ToLower (), если эта небольшая степень производительности имеет значение.

В ответ на ваш пример существует более быстрый способ :

String.Equals(type.Name, controllerName + "Controller", 
              StringComparison.InvariantCultureIgnoreCase);

Некоторое время назад возник вопрос о возможности записи в место хранения для std:: string , как если бы это был массив символов, и он зависел от того, является ли содержимое std:: string были смежными:

• Законно ли писать в std:: последовательность?

Мой ответ показал, что согласно паре хорошо известных источников (Herb Sutter и Matt Austern) текущий стандарт C++ действительно требует std:: строка для сохранения своих данных смежными при определенных условиях (при вызове str [0] предполагается, что str является std:: string ) и что этот факт в значительной степени заставляет руку любой реализации.

В основном, при объединении обещаний, данных последовательностей:: data () и последовательности:: оператор [] () , делается вывод о том, что & str [0] необходимо вернуть смежный буфер. Поэтому Остерн предлагает комитету просто сделать это явным, и, видимо, это то, что произойдет в стандарте 0x (или они называют его стандартом 1x сейчас?).

Так строго говоря, реализация не должна реализовывать std:: string , используя непрерывное хранение, но она должна делать это практически по требованию. И ваш пример кода делает только это, передавая в и буфер [0] .

Ссылки:

• Комментарий Херба Саттера
• Стандартный отчет о дефектах библиотеки C++ Мэтта Остерна
• предыдущий ответ SO

Редактировать : Вы хотите вызвать & buffer [0] , не buffer.data () , потому что [] возвращает не const ссылка и уведомляет объект о том, что его содержимое может неожиданно измениться.

Было бы проще выполнить buffer.data () , но вам следует меньше беспокоиться о непрерывной памяти, чем о памяти, совместно используемой между структурами. string реализации могут ожидать и ожидают получения уведомления о том, что объект изменяется. string :: data конкретно требует, чтобы программа не изменяла возвращаемый внутренний буфер.

ОЧЕНЬ высока вероятность того, что какая-то реализация создаст один буфер для всех неинициализированных строк, за исключением того, что длина установлена ​​на 10 или что-то еще.

Используйте вектор или даже массив с new [] / delete [] . Если вы действительно не можете скопировать буфер, юридически инициализируйте строку чем-нибудь уникальным перед ее изменением.

Проблема заключается в том, что вы пытаетесь создать или обновить поля в объекте User, который еще не существует. Поэтому другие поля не обновляются, поскольку они не связаны ни с какими первичными ключами дочерних полей.

Каждый раз, когда создается экземпляр нового поля модели, необходимо убедиться, что вы сохраняете его, чтобы дочернее поле модели имело идентификатор (первичный ключ) для связи.

Вам нужно нечто более подобное:

def save(self):
    user = User(
        username = self.cleaned_data['username'],
        email = self.cleaned_data['email1'],
        first_name = self.cleaned_data['first_name'],
        last_name = self.cleaned_data['last_name'],
    )
    ## save user so we get an id
    user.save()

    ## make sure we have a user.id
    if user.id:
        ## this doesn't save the password, just updates the working instance
        user.set_password(self.cleaned_data['password1'])
        user.profile = Profile(
            primary_phone = self.cleaned_data['phone'],
        )
        ## save the profile so we get an id
        user.profile.save()

    ## make sure we have a profile.id
    if user.profile.id:
        user.profile.address = Address(
            country = self.cleaned_data['country'],
            province = self.cleaned_data['province'],
            city = self.cleaned_data['city'],
            postal_code = self.cleaned_data['postal_code'],
            street1 = self.cleaned_data['street1'],
            street2 = self.cleaned_data['street2'],
            street3 = self.cleaned_data['street3'],
        )
        ## save the profile address
        user.profile.address.save()

    ## final save to commit password and profile changes
    user.save()
    return user

Эта каскадная save () вещь, которая у вас здесь происходит, просто не чувствует себя правильно. Вы склонны путь слишком много ошибок, если какое-либо из полей не сохранит, вы окажетесь с частично полным экземпляром пользователя и, возможно, окажетесь с дубликатами, если пользователю придется вернуться и повторить попытку. Не весело!

Изменить: Удалено 2-е полугодие из-за неточности.

Предположим, что имеются два FSM со состояниями O ( n ). Затем можно создать FSM размера O ( n ² ), который распознает только симметричное различие их принимающих языков. (Создайте модуль FSM, который имеет состояния, соответствующие паре состояний, по одному из каждого модуля FSM. Затем на каждом шаге обновите каждую часть пары одновременно. Состояние в новом FSM - это состояние принятия iff, ровно одно из пары было состоянием принятия.) Теперь минимизируйте этот FSM и посмотрите, является ли он таким же, как тривиальный одногосударственный FSM, который отвергает все. Минимизация FSM с состояниями m занимает время O ( m регистраций m ), так что в целом можно сделать все во времени O ( n ² регистраций n ).

@ Агор правильно заявляет, что Sipser является хорошим ориентиром для такого рода вещей. Ключевым пунктом моего ответа является то, что вы можете сделать это за полиномиальное время, даже с небольшой экспонентой.

Конечно, выделение вектора здесь глупо. Использование std:: wstring здесь также не мудро. Лучше использовать массив char для вызова winapi. создайте строку при возврате значения.

Результат не определен, и я бы не стал этого делать. Стоимость чтения в вектор и последующего преобразования в строку тривиальна в современных кучах c++. VS риск, что ваш код умрет в windows 9

также, разве для этого не нужен const_cast на &buffer[0]?