Какие новые возможности пользовательские литералы добавляют в C ++?

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

UDLs являются namespaced (и может быть импортирован при помощи объявлений/директив, но Вы не можете явно пространство имен литерал как 3.14std::i), что означает там (надо надеяться), не будет тонна столкновений.

То, что они могут на самом деле быть шаблонными (и constexpr'd) означает, что можно сделать некоторый довольно мощный материал с UDLs. Авторы Bigint будут действительно счастливы, поскольку у них могут наконец быть произвольно большие константы, вычисленные во время компиляции (через constexpr или шаблоны).

Мне просто грустно, что мы не будем видеть пару полезных литералов в стандарте (от взглядов его), как s для std::string и i для мнимой единицы.

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

Хм... Я еще не думал об этой функции. Ваш образец был хорошо продуман и конечно интересен. C++ очень мощен, как это теперь, но к сожалению синтаксис, используемый в частях кода, который Вы читаете, время от времени чрезмерно сложен. Удобочитаемость, если не все, то по крайней мере очень. И такая функция была бы приспособлена для большей удобочитаемости. Если я беру Ваш последний пример

assert(1_kg == 2.2_lb); // give or take 0.00462262 pounds

... Интересно, как Вы выразили бы это сегодня. У Вас были бы KG и класс LB, и Вы сравните неявные объекты:

assert(KG(1.0f) == LB(2.2f));

И это сделало бы также. С типами, которые имеют более длинные имена или типы, для которых у Вас нет надежд на наличие такого хорошего конструктора, не пишущий адаптер, это могло бы быть хорошее дополнение для непрерывного неявного создания объекта и инициализации. С другой стороны, можно уже создать и инициализировать методы использования объектов, также.

Но я соглашаюсь с Nils на математике. C и функции тригонометрии C++, например, требуют входа в радианах. Я думаю в градусах, хотя, таким образом, очень короткое неявное преобразование как отправленный Nils очень хорошо.

В конечном счете это будет синтаксическим сахаром однако, но это будет иметь небольшой эффект на удобочитаемость. И, вероятно, будет легче записать, что некоторые выражения также (sin(180.0 градуса) легче записать, чем градус sin((180.0)). И затем будут люди, которые злоупотребляют понятием. Но затем, оскорбительные для языка люди должны использовать очень строгие языки, а не что-то столь же выразительное как C++.

А-ч, в моем сообщении не говорится в основном ничто кроме: это будет хорошо, влияние не будет слишком большим. Давайте не волноваться.:-)

Это очень хорошо для математического кода. Не в своем уме я вижу использование для следующих операторов:

градус для градусов. Это делает пишущие абсолютные углы намного более интуитивными.

double operator ""_deg(long double d)
{ 
    // returns radians
    return d*M_PI/180; 
}

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

int operator ""_fix(long double d)
{ 
    // returns d as a 1.15.16 fixed point number
    return (int)(d*65536.0f); 
}

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

На первый взгляд это, кажется, простой синтаксический сахар.

Но выглядя глубже, мы видим, что это - больше, чем синтаксический сахар, поскольку это расширяет опции пользователя C++ создать пользовательские типы, которые ведут себя точно как отличные встроенные типы. В этом этой небольшой "премией" является очень интересный C++ 11 дополнений к C++.

Нам действительно нужен он в C++?

Я вижу небольшое количество использования в коде, который я написал в прошлых годах, но просто потому что я не использовал его в C++, не означает, что это не интересно для другого разработчика C++.

Мы использовали в C++ (и в C, я предполагаю), определенные компилятором литералы, для ввода целых чисел как коротких или длинных целых, вещественные числа как плавание или дважды (или даже длинный двойной), и символьные строки как нормальные или широкие символы.

В C++ у нас была возможность создать наши собственные типы (т.е. классы), с потенциально никакими издержками (встраивание, и т.д.). У нас была возможность добавить операторы к их типам, сделать, чтобы они вели себя как подобные встроенные типы, который позволяет разработчикам C++ использовать матрицы и комплексные числа так естественно, как они имели бы, если они были добавлены к самому языку. Мы можем даже добавить операторы броска (который обычно является плохой идеей, но иногда, это - просто правильное решение).

Мы все еще отсутствовали, одна вещь иметь пользовательские типы ведут себя как встроенные типы: пользовательские литералы.

Так, я предполагаю, что это - естественная эволюция для языка, но быть максимально завершенным: "Если Вы хотите создать тип, и Вы хотите, чтобы он вел себя так же возможный как встроенные типы, вот инструменты..."

Я предположил бы, что это очень похоже на решение.NET сделать каждый примитив структурой, включая булевские переменные, целые числа, и т.д., и иметь все структуры происходят из Объекта. Одно только это решение помещает.NET далеко вне досягаемости Java при работе с примитивами, неважно, сколько упаковки/распаковывания Java взломов добавит к своей спецификации.

ВАМ действительно нужен он в C++?

Этот вопрос состоит в том, чтобы ВЫ ответили. Не Bjarne Stroustrup. Не Herb Sutter. Не безотносительно члена комитета по стандарту C++. Поэтому у Вас есть выбор в C++, и они не ограничат полезную нотацию одними только встроенными типами.

Если Вам нужен он, то это - желанное дополнение. Если Вы не делаете, хорошо... Не используйте его. Это ничего не будет стоить Вам.

Добро пожаловать в C++, язык, где функции являются дополнительными.

Чрезмерно увеличенный в размерах??? Покажите мне свои комплексы!!!

Существует различие между чрезмерно увеличенным в размерах и сложным (предназначенная игра слов).

Как показанный Niels в том, Что новые возможности пользовательские литералы добавляют к C++?, способность записать комплексное число является одной из этих двух опций, добавленных "недавно" к C и C++:

// C89:
MyComplex z1 = { 1, 2 } ;

// C99: You'll note I is a macro, which can lead
// to very interesting situations...
double complex z1 = 1 + 2*I;

// C++:
std::complex<double> z1(1, 2) ;

// C++11: You'll note that "i" won't ever bother
// you elsewhere
std::complex<double> z1 = 1 + 2_i ;

Теперь, и C99 "удваивают сложный" тип и C++ "станд.:: сложный" тип может быть умноженным, добавленным, вычтенным, и т.д., с помощью перегрузки оператора.

Но в C99, они просто добавили другой тип как встроенный тип и встроенную поддержку перегрузки оператора. И они добавили другую встроенную литеральную опцию.

В C++ они просто использовали существующие функции языка, видел, что литеральная функция была естественной эволюцией языка и таким образом добавила его.

В C при необходимости в том же улучшении нотации для другого типа Вам не повезло до Вашего лоббирования для добавления квантовых волновых функций (или 3D точки, или безотносительно основного типа Вы используете в своем поле работы) к стандарту C, поскольку встроенный тип успешно выполняется.

В C++ 11, просто можно сделать это сами:

Point p = 25_x + 13_y + 3_z ; // 3D point

Это чрезмерно увеличено в размере? Нет, потребность там, как показано тем, как и C и комплексам C++ нужен способ представить их литеральные сложные значения.

Разве это неправильно разработано? Нет, это разработано как любая функция C++ с расширяемостью в памяти.

Это в целях нотации только? Нет, поскольку это может даже добавить безопасность типов к Вашему коду.

Например, давайте предположим, что CSS ориентировал код:

css::Font::Size p0 = 12_pt ;       // Ok
css::Font::Size p1 = 50_percent ;  // Ok
css::Font::Size p2 = 15_px ;       // Ok
css::Font::Size p3 = 10_em ;       // Ok
css::Font::Size p4 = 15 ;         // ERROR : Won't compile !

Затем очень легко осуществить строгий контроль типов к присвоению значений.

Опасно?

Хороший вопрос. Эти функции могут быть namespaced? Если да, то Джекпот!

Так или иначе, как все, можно уничтожить себя, если инструмент используется неправильно. C мощен, и можно стрелять голову прочь при неправильном использовании оружия C. C++ имеет оружие C, но также и скальпель, тазер, и безотносительно другого инструмента, который Вы найдете в инструментарии. Можно неправильно использовать скальпель и заставить себя истекать кровью. Или можно создать очень изящный и устойчивый код.

Так, как каждая функция C++, Вам действительно нужен он? Это - вопрос, на который необходимо ответить перед использованием его в C++. Если Вы не сделаете, то это ничего не будет стоить Вам. Но если Вам действительно будет нужен он, по крайней мере, то язык не подведет Вас.

Пример даты?

Ваша ошибка, это кажется мне, состоит в том, что Вы смешиваете операторы:

1974/01/06AD
    ^  ^  ^

Этого нельзя избежать, потому что / быть оператором, компилятор должен интерпретировать его. И, AFAIK, хорошо.

Для нахождения решения для проблемы я записал бы литерал некоторым другим способом. Например:

"1974-01-06"_AD ;   // ISO-like notation
"06/01/1974"_AD ;   // french-date-like notation
"jan 06 1974"_AD ;  // US-date-like notation
19740106_AD ;       // integer-date-like notation

Лично, я выбрал бы целое число и даты ISO, но оно зависит от ВАШИХ потребностей. Который является смыслом разрешения пользователю определить его собственные литеральные имена.

Шум в линии в той вещи огромен. Также ужасно читать.

Сообщите мне, они обосновывали что новое дополнение синтаксиса с каким-либо видом примеров? Например, у них есть несколько программ, которые уже используют C++ 0x?

Для меня, этой части:

auto val = 3.14_i

Не выравнивает по ширине эту часть:

std::complex<double> operator ""_i(long double d) // cooked form
{ 
    return std::complex(0, d);
}

Даже, если Вы не использовали бы i-синтаксис в 1 000 других строк также. Если Вы пишете, Вы, вероятно, пишете 10 000 строк чего-то еще вдоль этого также. Особенно, когда Вы все еще, вероятно, запишете главным образом везде это:

std::complex<double> val = 3.14i

'автоматический' - ключевое слово может быть выровнено по ширине хотя, только возможно. Но позволяет, берут просто C++, потому что это лучше, чем C++ 0x в этом аспекте.

std::complex<double> val = std::complex(0, 3.14);

Это похоже.. то простое. Даже мысль, всем станд. и заостренными скобками является просто Ламе при использовании его о везде. Я не начинаю предполагать что синтаксис, там находится в C++ 0x для превращения станд.:: комплекс под комплексом.

complex = std::complex<double>;

Это - возможно, что-то простое, но я не полагаю, что это настолько просто в C++ 0x.

typedef std::complex<double> complex;

complex val = std::complex(0, 3.14);

Возможно?>:)

Так или иначе точка: запись 3.14i вместо станд.:: комплекс (0, 3.14); не экономит Вам много времени в в целом кроме немногих супер особых случаев.

C++ обычно очень строг об используемом синтаксисе - запрет препроцессора нет очень, можно использовать для определения пользовательского синтаксиса/грамматики. Например, мы можем перегрузить существующий operatos, но мы не можем определить новые - IMO, это очень соответствует духу C++.

Я не возражаю против некоторых путей к более специализированному исходному коду - но выбранная точка кажется очень изолированной мне, который смущает меня больше всего.

Даже надлежащее использование может сделать его намного тяжелее для чтения исходного кода: одна буква может иметь обширно достигающие побочные эффекты, которые никоим образом не могут быть определены от контекста. С симметрией Вам, l и f, большинство разработчиков выберет одни буквы.

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

Я вижу некоторую заслугу в сочетании с "автоматическим", также в сочетании с библиотекой единицы как единицы повышения, но недостаточно заслужить это дополнение.

Интересно, однако, какие умные мысли мы придумываем.