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 ()

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

Хех, дело не в том, что у данной функции отличается только тип возврата. Пример, напомню, вырожденный, в реальной жизни, если приспичит, можно сделать так, чтобы T фигурировал [явно] и в наборе параметров. Хотя и так сработает.

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

> Хотя бы есть надежда. А на С++ только легаси и ни одного нового проекта.

Сильная заява, да :)

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

KDE к 5 версии будет почти весь на QML. Смиритесь, не нужен никому монстр в виде С++.

1. ты не понимаешь что такое QML
2. угадай на чём будет написан интерпретатор js

shty ★★★★★ ()

Отлично. В любимом C++ появилось то, что требуется временем. Пусть и с отставанием на несколько лет, но на то и нужна стабильность - использовать только зарекомендовавшие себя техники. Лямбды, foreach и auto - наверное, самое ожидаемое от этого стандарта

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

QML - лишь декларативный язык для описаниия интерфейса и конечный результат проработки state machine в Qt. Бизнес-логику ты на нём не напишешь.

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

>> при реализации ручками

Реализации ручками чего? Компилятора?

нет, именно дженериков в рамках стандарта с++

и опять я уже писал — это будет весьма костыльно

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

> Реализации ручками чего? Компилятора?

примерно вот так:


private:
  _List* add(_List* l, void* e) { ... }
public:
  template<class Element> 
  List<Element>* add(List<Element>* l, Element* e) {
    return (List<Element>*) add( (_List*)l, (void*) e );
  }
www_linux_org_ru ★★★★★ ()

> введена отдельная константа нулевого указателя nullptr

Ура, товагисчи! (В Паскале NIL есть уже лет 30.)

Но на самом деле я рад.

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

А еще не существует законов гравитации.

Сущестует Hindley–Milner type inference algorithm, а Hindley–Milner algorithm не существует.

Всегда ваш, К.О.

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

>угадай на чём будет написан интерпретатор js

Ну почему же «будет»...

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

> Сущестует Hindley–Milner type inference algorithm, а Hindley–Milner algorithm не существует.

Эксперты ITT.

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

> Да вот ещё что о чём все молчат! Ваш любимый boost теперь станет похож на человека.

Хотя пока они сообразят что в OSS есть только одна версия компилятора - последняя, пройдёт пара лет.

То, что бусту уже существенно больше пары лет, ни на что не намекает?

Сначала накопятся ошибки в поддержке старых компиляторов, потом геммороя всё больше, пока не признают что оно нафиг не надо.

Сначала пофиксятся ошибки в поддержке новых компиляторов, потом буст продолжит работать по разному в зависимости от компилятора, потому что всем это нужно.

Очевидная правка.

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

> что кстати очевидно - (void*)0 для С++ никак не подходит

Что тут очевидного?

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

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

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

Я налетал на ошибку std::move + rvalue refernce. Копать детали времени небыло. Будет - запощу пример.

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

Что тут очевидного?

#define NULL (void*)0

struct A;
void Foo( A* a );

int main( void )
{
    Foo( NULL ); 
}
aho ()
Ответ на: комментарий от tailgunner

> Я сам удивлся, что в C99 не прописано совпадение значения NULL и представления невалидного указателя в памяти.

Во-1ых, зачем для описания языка С99 описывать понятие обобщенного невалидного указателя в памяти?

А во-2ых, это не только не странно, это правильно, нормально и абсолютно необходимо. Просто потому, что NULL - это _ВАЛИДНОЕ_ представление указателя в памяти на невалидный объект - почувствуй разницу. То, что NULL - валидное представление указателя, позволяет делать вот так:

#define offsetof(st, m) ((size_t) ( (char *)&((st *)(NULL))->m - (char *)NULL ))

Для чего в стандарте специально указано:

The unary & operator yields the address of its operand. If the operand has type ‘‘type’’, the result has type ‘‘pointer to type’’. If the operand is the result of a unary * operator, neither that operator nor the & operator is evaluated and the result is as if both were omitted, except that the constraints on the operators still apply and the result is not an lvalue.

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

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

Evaluates to 0, а не equals to 0.

Это только с С++03.

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

> Странно, почему тогда в прошлый C++ такая фича не попала?

Попала в стандарте 2003. А до этого в рамках войны с void* NULL везде меняли на 0.

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

> и попробуй собрать

А почему это должно собраться?

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

> А почему это должно собраться?

оно и не должно

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

> NULL - это _ВАЛИДНОЕ_ представление указателя в памяти на невалидный объект

Ты сам-то понял, что сказал?

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

> Ты сам-то понял, что сказал?

Да, а что? Тебе кажется что-то непонятным или слишком сложным? ;)

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

>> Ты сам-то понял, что сказал?

Да, а что?

«If it makes sense to you, you've got a problem» (c)

Тебе кажется что-то непонятным или слишком сложным? ;)

Мне отквоченное словосочетание кажется бессмысленным.

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

Бизнес-логика на JS? Ну-ну. На JS максимум можно интерфейсом опять же управлять. Для большего его использовать не стоит.

some-body ★★ ()
Ответ на: комментарий от annulen

>угадай на чём будет написан интерпретатор js

Ну почему же «будет»...

потому, что:

KDE к 5 версии __будет__

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

> На JS максимум можно интерфейсом опять же управлять.

Ну почему же, еще на нем можно писать эмуляторы процессоров.

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

> Мне отквоченное словосочетание кажется бессмысленным.

В силу моей к тебе симпатии, я тебе помогу: чем является указатель на объект следующий (в терминах адресной арифметики) за последним элементом действительно выделенного массива элементов?

Является ли он не валидным?

Является ли валидным объект, на который он указывает?

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

> В силу моей к тебе симпатии, я тебе помогу: чем является указатель на объект следующий

Я польщен, но не надо мне помогать _в этом_. Потому что речь не о том, какие адреса являются валидными. Речь о том, что представление невалидного указателя _в памяти_ не обязательно является битовой строкой «все нули». И меня удивило, что такое представление не прописано в стантдарте - куча кода для инициализации объекта с указателями делает просто memset(ptr, 0, sizeof(*ptr)). В результате, на платформе, где невалидный указатель в памяти представляется _не_ всеми нулевыми битами, случится ХЗ что.

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

я к тому, что JS движки, которые могут быть, уже написаны на С++ :)

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

Да вообще что-либо стоящее и не тормозное написано либо на плюсах либо на сях

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

> Речь о том, что представление невалидного указателя _в памяти_ не обязательно является битовой строкой «все нули».

А ты не знал? О_О

Уж тыщу раз говорено на лоре: NULL != 0

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

Как же оно может быть прописано, если 0 может быть корректным адресом?

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

>> Речь о том, что представление невалидного указателя _в памяти_ не обязательно является битовой строкой «все нули».

А ты не знал? О_О

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

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

Ну, считай, что этот «современный код» рассчитан на работу на платформах, где это так. Одним условием к среде выполнения больше, одним меньше...

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

mv сказал, что на zSystem NULL != все_нули. А это не какая-то там богом забытая DSP-платформа, для нее Linux есть.

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

я к тому, что JS движки, которые могут быть, уже написаны на С++ :)

ну, кто бы спорил, я просто подчеркнул, что куда бы там и на какие qml'и не переходили «погромисты» kde, базовый движок, по крайней мере в обозримом будущем, останется на С++, и, следовательно, заявляя что С++ не нужен, тот ретивый товарищ пытается отпилить себе левую руку мотивируя это тем, что всё равно он дрочит правой

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

> mv сказал, что на zSystem NULL != все_нули.

Блин, так это верно практически для всех платформ. С нуля начинается адресация и на PS2/3, и даже на x86. Просто у пользовательских процессов при обращении к первым нескольким кило программно выбрасывается ошибка доступа. У линукса на x86 под это дело отведено, емнип, первые 4 Mib виртуального адресного пространства.

это не какая-то там богом забытая DSP-платформа, для нее Linux есть.

Один хрен, этот Linux работает в виртуалке под управлением zOs.

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

> С нуля начинается адресация и на PS2/3, и даже на x86. Просто у пользовательских процессов при обращении к первым нескольким кило программно выбрасывается ошибка доступа.

Я знаю, как именно это работает. Но это как раз довод в пользу «невалидный указатель - это битовые нули».

этот Linux работает в виртуалке под управлением zOs.

На bare metal тоже.

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

> Но это как раз довод в пользу

Какой же это «довод»? Поддержка адресации по нулю как особый случай адресации обеспечивается средой выполнения. Подозреваю, что для прикладых приложений и в zOs - тоже.

На bare metal тоже.

С доступам ко всем ресурсам и аппаратным возможностям мейнфрейма? ;)

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

Ну на брейнфаке тоже можно что-то интересное написать. Я всё же про освновное назначение говорил.

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

> Ну на брейнфаке тоже можно что-то интересное написать.

Да неужели? И как, написали уже?

Я всё же про освновное назначение говорил.

А я говорил о том, что область применения JS расширяется.

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

> Какой же это «довод»?

Веский.

Поддержка адресации по нулю как особый случай адресации обеспечивается средой выполнения.

Опять ты говоришь общеизвестные вещи. Да, обеспечивается средой выполнения (менеджером виртуальной памяти в ядре). И что?

На bare metal тоже.

С доступам ко всем ресурсам и аппаратным возможностям мейнфрейма? ;)

Является ли это полным доступом - нерелевантно для разговора.

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

> И что?

И то, что в таком случае это не может быть «доводом», и тем более «веским». Тут рантайм один, там - другой. Что теперь, все рантаймы как оглашенные должны выкидывать мегабайты памяти, чтобы поддерживать чисто условное NULL == 0 ? Естественно, что такую глупость никто в стандарт не впишет.

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

> Тут рантайм один, там - другой.

Где «тут». где «там»? Ты можешь назвать хоть одну платформу, где NULL _не_ представляется в памяти битовой строкой «все нули»?

Что теперь, все рантаймы как оглашенные должны выкидывать мегабайты памяти, чтобы поддерживать чисто условное NULL == 0 ?

Ыыы... Какие нафиг мегабайты? На системах с виртуальной памятью нужна страница, всего одна. На системах без виртуальной памяти по нулевому адресу всё равно лежит какая-нибудь фигня вроде векторов прерываний.

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

> Где «тут». где «там»?

Ты не знаешь никаких других вычислительных сред, кроме ОС общего назначения? ;)

Ты можешь назвать хоть одну платформу, где NULL _не_ представляется в памяти битовой строкой «все нули»?

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

Ыыы... Какие нафиг мегабайты? На системах с виртуальной памятью нужна страница, всего одна.

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

На системах без виртуальной памяти по нулевому адресу всё равно лежит какая-нибудь фигня вроде векторов прерываний.

И? Теперь стандарт должен запретить доступ к этим адресам и возможность работать с этой «фигнёй», только потому, что тебе это не нужно? Тебе не кажется, что это немного странноватая позиция?

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

> Ты не знаешь никаких других вычислительных сред, кроме ОС общего назначения? ;)

Знаю, а ты?

Ты можешь назвать хоть одну платформу, где NULL _не_ представляется в памяти битовой строкой «все нули»?

Я ж тебе уже привёл список.

И где он?

Аппартно такого требования нет ни на одной из известных мне архитектур

И тогда что именно мешает всем архитектурам использовать соглашение «NULL представляется в памяти строкой нулевых витов»?

Ыыы... Какие нафиг мегабайты? На системах с виртуальной памятью нужна страница, всего одна.

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

Потому что у него виртуальное адресное пространство большое. А необходима - одна страница (для протокола: не 4килобайтапамяти, а одна незамапленная страница).

На системах без виртуальной памяти по нулевому адресу всё равно лежит какая-нибудь фигня вроде векторов прерываний.

И? Теперь стандарт должен запретить доступ к этим адресам и возможность работать с этой «фигнёй»

У тебя удивительная способность видеть в написанном то, что тебе хочется, а не то, что на самом деле написано.

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

> Знаю, а ты?

Догадайся.

И где он?


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

У тебя удивительная способность видеть в написанном то, что тебе хочется, а не то, что на самом деле написано.


Ну это же логически вытекает из всего разговора:

Ты: Ух ты, оказывается где-то NULL !=0
Я: Ну да, это общеизвестная вещь.
Ты: Так все на это плюют
Я: Ну да, такой код будет работать только в определенных условиях. Можно и плюнуть.
Ты: И в их числе zOs.
Я: Формально, в их числе любая аппартная платформа. На парктике нуль банят софтеврно для прикладных процессов.
И тут ты внезапно: Вооот! Это же аргумент, чтобы внести побитовый нуль в стандарт!
Я: С чего бы это? Ведь это же поддержка только некоего подмножества сред выполнения.
Ты: И это делает подовод еще более веским!!1
Я: Каким образом поддеркжа этого свойства на некотором подмножестве делает его веским? Ведь среды вычисления бывают разными.
Ты: По нулую всё равно лежит какая-нибудь фигня.

Ну и какой я должен сделать вывод? Что тебя заботит доступ к этой «фигне»?

Аппартно такого требования нет ни на одной из известных мне архитектур


И тогда что именно мешает всем архитектурам использовать соглашение «NULL представляется в памяти строкой нулевых витов»?


Где логика? Если аппартного/арифметико-вычислительного требования нет, то зачем его придумывать?

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