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

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

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

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

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

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

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

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

Так для этого JS есть.

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

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

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

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

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

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

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 );
  }

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

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

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

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

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

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

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

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

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

Эксперты ITT.

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

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

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

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

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

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

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

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

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

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

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

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

#define NULL (void*)0

struct A;
void Foo( A* a );

int main( void )
{
    Foo( NULL ); 
}

> Я сам удивлся, что в 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.

И?

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

Evaluates to 0, а не equals to 0.

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

> И?

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

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

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

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

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

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

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

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

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

Да, верно. Я понял, о чём ты, просто протупил.

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

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

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

Да, а что?

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

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

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

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

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

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

потому, что:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На bare metal тоже.

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

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

На bare metal тоже.

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

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

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

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

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

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

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

Веский.

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

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

На bare metal тоже.

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

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

> И что?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Знаю, а ты?

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

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

И где он?

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

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

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

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

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

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

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

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

> Знаю, а ты?

Догадайся.

И где он?

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

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

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

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

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

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

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

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