LINUX.ORG.RU

Опубликован стандарт C++11 (бывший C++0x)

 , ,


0

4

ISO объявила о публикации стандарта C++11. Это первое значительное изменение стандарта с 1998-го года. Вот несколько новых объявленных возможностей:

  • ссылки на временные объекты и семантика переноса (rvalue reference);
  • обобщённые константные выражения (ключевое слово constexpr);
  • внешние шаблоны — возможность запретить компилятору инстанцировать шаблон в единице трансляции (extern template class);
  • ключевое слово auto для задания типа переменной на этапе компиляции;
  • цикл for по коллекции данных;
  • lambda-функции;
  • введена отдельная константа нулевого указателя nullptr;
  • шаблоны с переменным числом параметров (variadic templates);
  • thread-local хранилище, модель памяти с поддержкой потоков;
  • изменения в стандартной библиотеке: включение hash tables, регулярных выражений, smart pointers, элементов синхронизации потоков и т.п.

Полный список новых возможностей с подробным объяснением каждой из них можно посмотреть на http://en.wikipedia.org/wiki/C 11 или же более сжато на русском: http://ru.wikipedia.org/wiki/C 11

Полная поддержка C++11 обещается в GCC 4.7, объем поддержки на текущий момент можно оценить по таблице http://gcc.gnu.org/onlinedocs/libstdc /manual/status.html#status.iso.200x

ISO продает текст стандарта по 352 швейцарских франка ($386), но можно бесплатно скачать, например, его финальный черновик (практически не отличающийся от конечной версии) с сайта рабочей группы: http://www.open-std.org/jtc1/sc22/wg21/

>>> Пресс-релиз

★★

Проверено: maxcom ()

Ответ на: комментарий от anonymous

> Ясно же что имелось ввиду

Нет, имелось ввиду совершенно другое. А то, о чем ты говоришь - просто неосиляторство. Не смогли сделать ограниченную квантификацию, вот и все.

anonymous ()
Ответ на: комментарий от www_linux_org_ru

> ничего (0 байт в объектном файле)

Вот именно. Это и есть type erasure.

anonymous ()
Ответ на: комментарий от www_linux_org_ru

> в первом приближении type erasure это когда компилируется именно шаблон

Да.

, т.е. бинарный код, реализующий some_function<Class1> и some_function<Class2>, один и тот же

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

anonymous ()
Ответ на: комментарий от anonymous

> (когда в скомпилированном коде нету информации о типовых аргументах, то есть полиморфная функция не может быть first-class объектом).

скорее наоборот — наличие информации о типовых аргументах мешает полиморфной функции быть 1 объектом, а не группой из многих-многих объектов

впрочем, шаблонами можно обернуть любой код, оперирующий void*, и так дешево и сердито получить type erasure (но компилятор тут уже не помощник)

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от x4DA

>что за штука properties? аннотации как в жабе?

Пример похожий на борман с++: class SomeWindow {

public:

void setTitle(AnsiString newTitle);

AnsiString getTitle();

__property AnsiString Title=

{read=getTitle, write=setTitle, default=«»};

}

Теперь при SomeWindow.Title=«HELLO!» будет вызываться сеттер setTitle(), который, кроме всего прочего еще и перерисует окно с нужным заголовком и провалидирует значение, если нужно. Плюс у свойства может быть гетер но не будет сетера и наоборот. Плюшка, на самом деле удобная. Получается более интуитивно понятная семантика.

yurkis ()
Ответ на: комментарий от x4DA

В C# выглядит так:

public class MyClass
{
    public string Property { get; private set; }
}

encyrtid ★★★★★ ()
Ответ на: комментарий от anonymous

Там имелось ввиду именно это, даже если тот кто об этом говорил думал иначе.

Осиляторством не занимаюсь, у меня девушка есть.

anonymous ()
Ответ на: комментарий от encyrtid

> encyrtid

а еще в C# вот что есть (ковариация в C#4.0):

class Base {} class Derived : Base {} void Main() { Derived[] a1 = new Derived[10]; Base[] b1 = a1; // boom baby.

List<Derived> a2 = new List<Derived>(10); List<Base> b2 = a; // boom baby 2X :D }

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

anonymous ()
Ответ на: комментарий от anonymous

>> ничего (0 байт в объектном файле)

Вот именно. Это и есть type erasure.

вовсе нет; в яве результатом будет занимающий сколько-то байт байт-код, у которого везде, где были типы-параметры, будет стоять Object

в плюсах, чтобы добиться аналогичного, надо сделать нетривиальные движения руками

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от anonymous

Не распарсил. В случае массивов ковариантность допустима, в случае генериков - нет.

encyrtid ★★★★★ ()
Ответ на: комментарий от encyrtid

> encyrtid

Вот ведь.. хотел понтануться не вышло. Видимо только IEnumerable<> работает... :D

anonymous ()
Ответ на: комментарий от anonymous

>давно пытался в C++ сделать подобное
auto a1 = new list<derived*>(10);
list<base*>* a2 = reinterpret_cast<list<base*>*>(a1);
Оно? Только не надо про чистоту кода - какая задача такой и код.

son_of_a_gun ()
Ответ на: комментарий от encyrtid

> encyrtid

Но это правильно в любом случае, на примере функции добавления List.Add. Если я буду потом добавлять в список с Derived одиночные элементы Base - получится каша - список из разных типов. А просто массивы они статичны, не позволяют добавлять новые элементы, поэтому им всё дозволено :D

anonymous ()
Ответ на: комментарий от son_of_a_gun

> son_of_a_gun

Проверил, вроде да, проверяет что Derived это предок Base, так что похоже это то что я пытался реализовать. :).

anonymous ()
Ответ на: комментарий от alx_me

> Комитет C/C++ слишком консервативен, там у всех пубертатный период окончился.

Вчера собирал старый плюсовый код компилятором с включенной поддержкой нового стандарта. Обратная совместимость ушла лесом. А Вы говорите «пубертатный период окончился». Скорей всего он еще и не начался.

rtvd ★★★★★ ()
Ответ на: комментарий от rtvd

> Обратная совместимость ушла лесом.

пример можно?

aho ()
Ответ на: комментарий от son_of_a_gun

> son_of_a_gun

А нет вру, это не то. И проверки что Base является родителем Derived тут нет. Я могу привести хоть к типу int* и компилятор проглотит. А я делал типобезопасную версию, такую что конвертация была возможна только если Base действительно родитель Derived.

anonymous ()
Ответ на: комментарий от tailgunner

> Но претензия была вполне очевидная - при модификации программ с тотальным Хиндли-Милнером ошибки могут вылезать в неожиданных (и далеких от точки модификации) местах, поэтому область применения вывода типов неплохо бы ограничивать, например, границами модуля.

Ну так это вроде очевидно и не является проблемой. Разве нет?

Более того, во всяких там хаскелях объявление сигнатур для интерфейса модуля является общепринятой и здравой практикой. А в Agda, если не изменяет память, так вообще сигнатуры всех определений верхнего уровня должны прописываться явно (правда там это из-за особенностей системы типов). И все чудесно.

rtvd ★★★★★ ()
Ответ на: комментарий от alx_me

> В строгой вы ничего не напишете. История с pascal-ем ничему не учит.

Что за история и чему она не учит?

rtvd ★★★★★ ()
Ответ на: комментарий от son_of_a_gun

> son_of_a_gun

И более того, была проверка что Base имеет виртуальный деструктор, перед конвертацией - и всё это в компайл тайме, с помощью __has_virtual_destructor и прочих наворотов языка. На случай если я захочу вызвать Clear с помощью второй ссылки. Короче там всё должно было быть безопасно и типобезопасно. А не просто насильно преобразовать один тип указателя в другой и наслаждаться рантайм багами.

anonymous ()
Ответ на: комментарий от rtvd

Ладно пацаны, как бывший C++ сник я за вас рад, что вы наконец дождались нового стандарта. Но если честно когда я вспоминаю о C++ и о его не только новых, но и старых фичах у меня жутко начинает болеть голова. И кстати да, теперь C++ реально стал сложнее в обучении, это мне стало просто очевидно когда я просмотрел полный список фич нового стандарта. Мозги просто в трубочку закручиваются если честно :). В общем удачи, C++ сники всё равно нужны для грязной работы, я буду ждать в свою очередь C#5.0 будем надеется я там увижу обещанный скриптинг и C# наконец превратится в убийцу JavaScript, async если честно не очень сильно жду, и без него пока нормально живется.

anonymous ()
Ответ на: комментарий от rtvd

>> Но претензия была вполне очевидная - при модификации программ с тотальным Хиндли-Милнером ошибки могут вылезать в неожиданных (и далеких от точки модификации) местах, поэтому область применения вывода типов неплохо бы ограничивать, например, границами модуля.

Ну так это вроде очевидно и не является проблемой. Разве нет?

Это очевидно тебе, но не угодайчегу. Насчет «не является проблемой» - ХЗ, у меня нет опыта. По тому, что я читал, таки является.

tailgunner ★★★★★ ()
Ответ на: комментарий от mv

> > Скорее, предполагается, что NULL будет определяться не как (void*)0, а через nullptr.

А он и так не 0. Есть платформы, на которых C++ существует, но NULL там не равен 0.


В c++ по стандарту null есть 0.

andreyu ★★★★★ ()
Ответ на: комментарий от andreyu

В c++ по стандарту null есть 0.

Evaluates to 0, а не equals to 0.

mv ★★★★★ ()

на говне сметану не сделаешь...

anonymous ()
Ответ на: комментарий от anonymous

>на говне сметану не сделаешь...

Да на нём и делается, вообще-то.

говно → почва → трава → корова → молоко → сливки → сметана

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

> говно → почва → трава → корова → молоко → сливки → сметана

→ человек → деньги → говно

andreyu ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

Еще раз, type erasure - это когда такого объекта как «полиморфная ф-я» в рамках ЯП просто не существует. Так дело обстоит в плюсах, жабе, том же хаскеле. Если же затирания типов нет, то полиморфная функция выступает как полноправный объект - как, например, в C#.

anonymous ()
Ответ на: комментарий от anonymous

> Там имелось ввиду именно это

Там имело ввиду именно то, что я сказал. Инфа 100%.

anonymous ()
Ответ на: комментарий от rtvd

> Ну так это вроде очевидно и не является проблемой. Разве нет?

Конечно же нет. Является.

anonymous ()
Ответ на: комментарий от V0ID

Не в курсе что он там делает у Вас, а у меня он - производит код 8)

а у меня конпеляет, и, по сообщениям отдельных товарищей, всю свою сознательную жизнь этим и занимался

а уж код для него я произвожу сам

shty ★★★★★ ()
Ответ на: комментарий от alx_me

gcc производит промежуточный lisp-о подобный платформонезависимый код.

какой-какой, лиспообразный? oh, shi~

наверное потому-что комитет плотно взаимодейсвтует с создателями компиляторов

да там половина чуваков в том комитете, из compiler teams

shty ★★★★★ ()
Ответ на: комментарий от rtvd

Вчера собирал старый плюсовый код компилятором с включенной поддержкой нового стандарта. Обратная совместимость ушла лесом.

ну-ка, ну-ка, на каком куске кода оно сломалось, не приведёте ли?

shty ★★★★★ ()
Ответ на: комментарий от ugoday

> Для справки: есть языки умеющие всё это и многое другое и их стандарт занимает 50 листов А4.

Спасибо за справку. Так вроде я о том же самом сказал.

atoku ★★★ ()
Ответ на: комментарий от encyrtid

В C# выглядит так:

public class MyClass
{
    public string Property { get; private set; }
}

Красиво, но мне на практике приходиться разбивать get и set, так как много проверок и различных действий висит на set, а порой и на get. И стараюсь делать по-старинке: процедура SetProperty(Value) и функция GetProperty().

alexl83u ()
Ответ на: комментарий от ugoday

Я так понимаю, что вы тоже про Хиндли-Миндлера только в содержании курса читали.

dr_dobermann ()
Ответ на: комментарий от V_L_A_D

> Между «Point p(...); p.setX(...); p.setY(...)» и «Point p(...); p.moveTo(...);» есть огромная разница. А пропертиз помогают писать код, как в первом варианте, и совершенно бесполезны при использовании второго.

Чето я не понял, а где тут пропертиз? Что в первом, что во втором случае - простые вызовы методов класса. Разве что в первом это два вызова, а во втором агрегированный метод, который, возможно объявлен как инлайн и вызывает эти же два метода.

Проперти это когда Point p(...); p.x = ...; при том, что x - не паблик мембер.

Не?

dr_dobermann ()
Ответ на: комментарий от anonymous

>И проверки что Base является родителем Derived тут нет.
Внезапно. reinterpret_cast

son_of_a_gun ()
Ответ на: комментарий от anonymous

> Ладно пацаны, как бывший C++ сник я за вас рад, что вы наконец дождались нового стандарта. Но если честно когда я вспоминаю о C++ и о его не только новых, но и старых фичах у меня жутко начинает болеть голова. И кстати да, теперь C++ реально стал сложнее в обучении, это мне стало просто очевидно когда я просмотрел полный список фич нового стандарта. Мозги просто в трубочку закручиваются если честно :). В общем удачи, C++ сники всё равно нужны для грязной работы, я буду ждать в свою очередь C#5.0 будем надеется я там увижу обещанный скриптинг и C# наконец превратится в убийцу JavaScript, async если честно не очень сильно жду, и без него пока нормально живется.

Во-первых мимо тазика. Меня C++ не особо волнует. :-) А шарп - тем более.

А во-вторых речь шла о какой-то там «истории с паскалем, которая ничему не учит». А я спрашивал, что это за история такая. Может там какие-то скандалы, интриги и расследования, а я все пропустил?

rtvd ★★★★★ ()
Ответ на: комментарий от tailgunner

> > Ну так это вроде очевидно и не является проблемой. Разве нет?

Это очевидно тебе, но не угодайчегу. Насчет «не является проблемой» - ХЗ, у меня нет опыта. По тому, что я читал, таки является.

Угодайчег это вообще особый случай.

Я же интересуюсь, в чем проблема с Хиндли-Милнером, т.к. сам с проблемами не сталкивался. Может я просто не стремился нарушать стандарты и стрелять себе по ногам?

Правда софт у меня был небольшой. Так, несколько проектиков строк на 5-20K каждый. Связывалось все без проблем. И свой код со своим, и свой с чужим.

rtvd ★★★★★ ()
Ответ на: комментарий от son_of_a_gun

Внезапно: reinterpret_cast никаких гарантий не дает. Компилятор проглотит этот код, вне зависимости от того какой указатель ты подсунешь в reinterpret_cast.

encyrtid ★★★★★ ()
Ответ на: комментарий от anonymous

А спроектировать приличную архитектуру, где не требуется всей этой свистопляски с бубенцами - никак?

son_of_a_gun ()
Ответ на: комментарий от encyrtid

>Внезапно: reinterpret_cast никаких гарантий не дает
Для вас может и внезапно, а я об этом и говорил.

son_of_a_gun ()
Ответ на: комментарий от son_of_a_gun

>И проверки что Base является родителем Derived тут нет.

Внезапно. reinterpret_cast

А это что? Как reinterpret_cast поможет проверить наследование в compile-time?

encyrtid ★★★★★ ()
Ответ на: комментарий от ugoday

> только кривую, тормозную и до нельзя примитивную.

Ух ты какой годный вброс! Или я ошибся, и Вы всерьёз это утверждали? :)

AlexM ★★★★★ ()
Ответ на: комментарий от rtvd

> Правда софт у меня был небольшой. Так, несколько проектиков строк на 5-20K каждый.

Проблемы проявляются при обширной модификации, насколько я понял. Только размера недостаточно.

tailgunner ★★★★★ ()
Ответ на: комментарий от AlexM

>> только кривую, тормозную и до нельзя примитивную.

Ух ты какой годный вброс!

Жалкий плагиат Гринспена.

tailgunner ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.