В статье "The Biggest Changes in C++11 (http://www.softwarequalityconnection.com/2011/06/the-biggest.../)" один из членов комитета по стандартизации языка C++ привел практические примеры изменений, ожидаемых в будущем стандарте C++11. Изменения ожидаются значительные, например, Бьерн Страуструп, создатель C++, упомянул (http://www.codeguru.com/article.php/c18357) в одном из интервью, что C++11 ощущается как новый язык, части которого сочетаются друг с другом лучше. В статье показано как язык C++ может быть улучшен и как эти улучшения могут помочь в написании более качественного кода.URL: http://www.softwarequalityconnection.com/2011/06/the-biggest.../
Новость: http://www.opennet.me/opennews/art.shtml?num=30960
от макросов избавляться не планируется?...всё также нельзя будет создавать имена переменных с именем "stdout" [и прочими бесчисленными количествами подводных макросов] ? :-D
int main()
{
int stdout = 42;
std::cout<<stdout<<std::endl;
}Выводит 42, ЧЯДНТ?
хм... да....
> от макросов избавляться не планируется?Каким образом и зачем? Для большей части и в C++ есть замена макросам - от enum до перегруженных функций и шаблонов, для остального до сих пор нет лучшего решения, чем препроцессор; скажем, D'шные (забыл как это у них называется, аналог #ifdef _linux_) не работают вообще. Более того, в любом другом языке есть и всегда будут такие же C'шные макросы (ибо пользоваться cpp никто никогда не запретит). Так что нет, не планируется.
И хорошо что не планируется. Ломать - не строить!
Макросы - очень мощный инструмент. Отказываться от него бредово. И я больше чем уверен, что этого не будет НИКОГДА. Так что не парьтесь и переходите на Яву, если считаете С++ сложным, запутанным и пр.
> от макросов избавляться не планируется?Ни в коем случае. Макросы позволяют очень много полезнейших вещей. К примеру, эмулировать "reflection", писать прекрасные отладочные сообщения, делать многоплатформенные программы и т.д.
И они это позволяют делать просто и удобно. Еще не хватало - отказываться от них.
> от макросов избавляться не планируется?А как же метапрограммирование? Без макросов особо не напишешь такого.
мне кажется из С++ уже пора выкидывать фичи а не добавлять
>мне кажется из С++ уже пора выкидывать фичи а не добавлятьАга, только вот адекватной замены так и не видно. До сих пор.
> Ага, только вот адекватной замены так и не видно. До сих пор.Вообще-то возможности компьютеров сильно выросли с момента создания С++.
Поэтому нет необходимости насиловать себе мозг С++, можно взять любой язык высокого уровня и писать на нём, а какой-нибудь критичный к скорости алгоритм сделать на С. Для с компьютеров с ограниченными возможностями есть опять таки же С, который (в стандарте С99) очень удобен и прост.
> Вообще-то возможности компьютеров сильно выросли с момента создания С++И? Сложность задач растёт всё равно бысрее, а выкинуть три четверти производительности и большую часть памяти ради неноучек от программирования которые не хотят делать delete? Не будет этого.
Уже сто лет как вышел D. Вылезаем из танка?
> Уже сто лет как вышел D. Вылезаем из танка?Это который сам с собой не совместим? ;)
> Уже сто лет как вышел D. Вылезаем из танка?Вылезли. Посмотрели. Обломались найти хоть один нормальный компилер и хоть одну убедительную программу. Залезли обратно и поехали дальше своей дорогой...
> мне кажется из С++ уже пора выкидывать фичи а не добавлятьмне так не кажется
не умеете использовать фичи - не пользуйтесь этими фичами
> не умеете использовать фичи - не пользуйтесь этими фичамиВ том-то и дело, что большинство фич C++ это хуже, чем ничего.
Сначала радостно используешь фичу, потом понимаешь, что без неё всё гораздо проще,
в следующий раз уже сразу отбрасываешь этот хлам.В любом С++ проекте есть список фич языка, которые нельзя использовать.
Наверное никто не умеет ими пользоваться :-)
> Наверное никто не умеет ими пользоваться :-)На что Вы хотели? Уровень программистов падает с каждым годом.
> На что Вы хотели? Уровень программистов падает с каждым годом.А меня вот бесит что чемпион мира по бегу бегает быстрее чем я. Давайте ему ноги ампутируем?! Тогда я смогу бегать быстрее чемпиона мира по бегу! \m/ \m/
> А меня вот бесит что чемпион мира по бегу бегает быстрее чем
> я. Давайте ему ноги ампутируем?! Тогда я смогу бегать быстрее чемпиона
> мира по бегу! \m/ \m/Что курил? Если тебе так нравятся сравнения жопы с пальцем, насладись моим ответом:
Мы не хотим бегать в неудобных кроссовках, поэтому выкидываем их из нашей команды :-D
> Мы не хотим бегать в неудобных кроссовках, поэтому выкидываем их из нашей команды :-DБегайте босиком, ага. Только это слегка травмоопасно...
> Наверное никто не умеет ими пользоваться :-)Хм, а если кто-то не умеет вообще ни одной фичой пользоваться - тогда видимо надо запретить языки программирования вообще? :)
Если под "умением использовать" ты понимаешь умение ловко обходить все грабли щедро рассыпанные создателями языка, то это называется "есть кактус", а не "умение использовать".Скажи например разработчикам LLVM, что они не умеют использовать исключения в С++, а то понимаешь ламера собрались компиляторы пишут.
> Если под "умением использовать" ты понимаешь умение ловко обходить все грабли щедро
> рассыпанные создателями языка, то это называется "есть кактус", а не "умение
> использовать".
> Скажи например разработчикам LLVM, что они не умеют использовать исключения в С++,
> а то понимаешь ламера собрались компиляторы пишут.Да, спецификация исключений - общеизвестное зло.
> Да, спецификация исключений - общеизвестное зло.Что всё-таки плохого в исключениях ? Только возможность нового исключения при обработке перехваченного ? Или что-то ещё ?
Речь не об исключениях как приёме программирования, а именно об спецификации исключений при объявлении функций/методов. В более-менее сложном проекте - это верный путь к сегфалтам.
Ну вперёд - рассказывайте что бы вы выкинули, и чем бы вы это заменили.
Всё уже придумано, называется D. Andrei Alexandrescu seal of approval.
> Всё уже придумано, называется D. Andrei Alexandrescu seal of approval.В D нет принципиальных отличий от C++. Только вы об этом не знаете, потому что в глаза его не видели. И никто не видел, потому что мертврoжденный язык никому не нyжен.
Объясните, пожалуйста, зачем в языке нужны три способа преобразования типов?1) (type)x
2) type(x)
3) static_cast<type>(x), dynamic_cast<type>(x), ...(Особенно последнее уродство убивает. Оно, наверное, специально так было задумано, чтобы программист лишний раз подумал, а нужно ли ему преобразовывать типы...)
Зачем нужны два способа вывода на стандартный вывод?
1) printf(...)
2) cout << "..."(Я не спрашиваю, что нужно было курить, чтобы начать использовать привычный оператор сдвига в качестве оператора вывода... Оо)
Зачем нужны ссылки (&), когда есть указатели (*), и на уровне машинного кода они чаще всего работают одинаково?
Зачем в Boost нужны 10 типов указателей (auto_ptr, linked_ptr, scoped_ptr, shared_ptr, smart_ptr, weak_ptr, intrusive_ptr, exception_ptr...) и знаете ли вы как пользоваться каждым из них?
Почему все существующие библиотеки (STL, Boost, MFC, VCL...) определяют одни и те же структуры данных типа List или Matrix, несовместимые между собой?
Продолжать? :)
Теперь о том, чем бы я все это заменил. Я бы, честно говоря, все это выкинул вместе с С++ и заменил бы языком, более подходящим для решения каждой конкретной задачи.
Три способа преобразования типов работают по-разному, если применяются не к примитивным типам. "Последнее уродство" позволяет программисту быть однозначно уверенным в том, как именно будет произведено преобразование.Два способа вывода - это С и С++, что вас смущает?
Передача аргумента по ссылке удобна, например, тогда, когда этот аргумент является указателем. С чего она вам помешала, если вы понимаете, что это просто способ передать указатель на объект?
Boost - тестовая лаборатория с кучей велосипедов, именно поэтому он не входит в стандарт.
Из существующих библиотек к стандарту языка относится только одна - STL. Почему МС и Борланд сделали свои, несовместимые ни с кем классы? Да потому что они всегда так делали и делают!
> Три способа преобразования типов работают по-разному, если применяются не к примитивным типам. "Последнее уродство" позволяет программисту быть однозначно уверенным в том, как именно будет произведено преобразование.Да? Ну и как же по-разному работают преобразования в трех последних строчках следующего кода?
class A {
// очень сложный класс ...
};
class B {
// другой очень сложный класс ...
};
typedef B * Bptr; // бесполезный указатель - только для иллюстрации
...
A * a = new A;
...
B * b = (B*)a;
B * b = Bptr(a);
B * b = reinterpret_cast<B*>(a);> Два способа вывода - это С и С++, что вас смущает?
Зачем в ОДНОМ языке ДВА способа вывода на stdin? Почему одного не достаточно?
> Передача аргумента по ссылке удобна, например, тогда, когда этот аргумент является указателем. С чего она вам помешала, если вы понимаете, что это просто способ передать указатель на объект?
Зачем изобретать лишнюю сущность? Если я понимаю, что это указатель, почему бы и не передавать и не использовать его как указатель?
> Boost - тестовая лаборатория с кучей велосипедов, именно поэтому он не входит в стандарт.
А что, есть надежда, что эти 10 типов указателей там когда-нибудь будут упразднены и заменены одним, универсальным?
> Ну и как же по-разному работают преобразования в трех последних строчках следующего кода?Если вы этого не знаете, почитайте учебник или хотя бы блоги. Например, http://alenacpp.blogspot.com/2005/08/c.html
Вообще, классический тролль-пост. Фу.
> Если вы этого не знаете, почитайте учебник или хотя бы блоги. Например, http://alenacpp.blogspot.com/2005/08/c.htmlЧто, не можете дать ответ? Значит, вы и не знаете. А ответ очень прост: во всех трёх случаях преобразования работают АБСОЛЮТНО ОДИНАКОВО, то есть мы имеем дело с классическим "велосипедом".
> Вообще, классический тролль-пост. Фу.
Ну, это понятно. Если аргументы по теме кончились, нужно обозвать оппонента троллем.
> Оно, наверное, специально так было задумано, чтобы программист лишний раз подумал, а нужно ли ему преобразовывать типы.Да, в том числе и поэтому! О чём Страуструп честно рассказывает в D&E.
> во всех трёх случаях преобразования работают АБСОЛЮТНО ОДИНАКОВО
Работают они, может быть, и одинаково. Но представьте такую задачу: найти в большом наборе исходных файлов все случаи приведения типов. С использованием static_cast задача решается мгновенно простым поиском по тексту. С использованием традиционного синтаксиса - для поиска придётся стать компилятором.
И, конечно, dynamic_cast мешать в общую кучу не следует, это совсем другой случай.
> Да, в том числе и поэтому! О чём Страуструп честно рассказывает в D&E.Чем рассказывать, лучше бы сделал свой язык нетипизированным, тогда проблема приведения типов даже не возникла бы. Ан нет! Гораздо удобнее взять хорошо распиаренный Си, приделать к нему своих костылей, и потом рассказывать всем, что это и есть правильно.
> Но представьте такую задачу: найти в большом наборе исходных файлов все случаи приведения типов.
Скажите, когда в последний раз вам приходилось искать в исходниках все приведения типов? Я, например, такого случая в своей 15-летней программистской практике вспомнить не могу. На написание этого уродского оператора за весь этот период ушло бы больше времени, чем на поиск всех приведений типов.
>[оверквотинг удален]
> кода они чаще всего работают одинаково?
> Зачем в Boost нужны 10 типов указателей (auto_ptr, linked_ptr, scoped_ptr, shared_ptr,
> smart_ptr, weak_ptr, intrusive_ptr, exception_ptr...) и знаете ли вы как пользоваться
> каждым из них?
> Почему все существующие библиотеки (STL, Boost, MFC, VCL...) определяют одни и те
> же структуры данных типа List или Matrix, несовместимые между собой?
> Продолжать? :)
> Теперь о том, чем бы я все это заменил. Я бы, честно
> говоря, все это выкинул вместе с С++ и заменил бы языком,
> более подходящим для решения каждой конкретной задачи.Sorry man, but you are a total lamer in C++, according to your kindergarten questions?
Please don't humiliate yourself.
По поводу ссылок и указателей... Указатель бывает нулевым, а ссылка - нет. Соответственно для указателей нужно добавлять проверку на нулевой указатель, возвращать какой-то код ответа или исключение, в вызывающей функции делать то же самое и т.д. вплоть до функции самого нижнего уровня (main, например). Кроме того, при передаче по ссылке может неявно вызываться конструктор передаваемого объекта. С указателем такого нет. Так что не путайте ссылки и указатели. Это совсем разные вещи.
> Так что не путайте ссылки и указатели. Это совсем разные вещи.Для процессора это абсолютно одинаковые вещи. Разница существует только на уровне синтаксиса языка, и только потому, что Страусструп придумал этот костыль и решил, что наряду с универсальным указателем он будет жутко удобным.
Удобство я вижу только одно: нужно писать '.' вместо '->' :) Но, как всегда в С++, одно небольшое удобство оборачивается бОльшим геморроем. Во-первых, как вы сами упомянули, при передаче по ссылке может неявно вызываться конструктор передаваемого объекта. Это делает код менее предсказуемым и программист должен всегда об этом помнить. Во-вторых, объект, передаваемый по ссылке, должен всегда существовать, даже если он мне не нужен. Например:
int my_write(const void * data, size_t bytes_to_write, size_t * bytes_written) {
// ...
if (bytes_written)
bytes_written = count;
}// ...
my_write(my_data, n, 0); // мне не интересно знать, сколько байтов было записано
В С++ со ссылками такой номер не пройдет: если bytes_written - ссылка, хочешь - не хочешь, нужно заводить переменную и передавать ее в функцию.
Указатель можно передать левый, а ссылку нет.
> Указатель можно передать левый, а ссылку нет.С указателями можно использовать арифметику, что позволяет в ряде случаев сделать очень эффективные в плане производительности фокусы, например избавившись от лишнего копирования данных в памяти ("zero-copy").А кто-то потом еще искренне удивляется чего это явы и дотнеты сливают в 4 раза в тяжелых вычислениях, и почему все игры в итоге на си++ как один пишут, да и тяжело нагруженные проекты нынче тоже на нем переписывают почему-то. Наверное потому что в 4 раза меньше серверов стоят в 4 раза меньше денег :)
Ссылку можно легко преобразовать в указатель операцией получения адреса &, а потом играться с указателем сколько угодно.
> Указатель можно передать левый, а ссылку нет.Если постараться, то можно и член сломать :)
>> Указатель можно передать левый, а ссылку нет.
> Если постараться, то можно и член сломать :)Передача нулевого указателя - очень часто встречающийся глюк. Ссылки спасают от этого. Кроме того, т.к. не нужно добавлять проверку на нулевой указатель и кучу проверок в родительских функциях, то код со ссылками работает быстрее.
>> Так что не путайте ссылки и указатели. Это совсем разные вещи.
> Для процессора это абсолютно одинаковые вещи. Разница существует только на уровне синтаксиса языкаУчитывая, что код, который пишет программист и генерирует компилятор до передачи в функцию и внутри функции, разный, то на уровне ассемлера это всё таки разные вещи: иногда неявный вызов конструктора для ссылок и проверка на NULL для указателя.
Но повторюсь, лично я не противопоставляю эти два инструмента, а использую их оба в зависимости от ситуации.
> мне кажется из С++ уже пора выкидывать фичи а не добавлятьЭто и Страуструпу кажется. Только вот, к сожалению, невозможно. Иначе бы он давным давно этим воспользовался.
"Страусс" уже давно живой памятник, от которого мало что зависит в его собственном детище.
> "Страусс" уже давно живой памятник, от которого мало что зависит в его
> собственном детище.Просто если вы выбросите фичи - придут те у кого сломались программы. Отщипнут от вас по кусочку. И в результате от вас очень скоро останется отполированный до блеска ... скелет.
> мне кажется из С++ уже пора выкидывать фичи а не добавлятьЗачем? Потеряется обратная совместимость, перестанет работать куча софта, кто-то не сможет пользоваться удобными ему конструкциями. В каком месте наступит профит?
эта новость здесь только для того, что бы отправить читателя по ссылке? по моему, без списка изменений, хотя бы краткого, это даже на заметку не тянет
Вообще-то в мини-новостях изначально кидали только ссылки на подобные статьи с краткой аннотацией. Но в последние годы разбаловали вас. Общество потребителей, нет что бы дополнить, под новостью есть кнопка "исправить".
новая стратегия маркетинга? плоха не новость, а плох тот кто её читает? вообще это называется критика и нужна она для того, что бы держать новости на уровне. думаю даже ты догадываешься на сайт с какими новостями скорее придёт читатель
> эта новость здесь только для того, что бы отправить читателя по ссылке?
> по моему, без списка изменений, хотя бы краткого, это даже на
> заметку не тянетты ошибся ресурсом, это не лор.
Наверное очень трудно создавать стандарты, которые будут использовать лет через 10. Это сколько всего нужно предусмотреть, тяжелая работа наверное.
Вот потому, что это трудно, нельзя допускать в индустрию "поделки" одиночных "гениев" - сначала они должны доказать, что каждое их решение было взвешенным и не имеет альтернатив. А то, что Страус прикрутил ООП к ассемблеру - так это хобби, а не "стандарт"!
> Вот потому, что это трудно, нельзя допускать в индустрию "поделки" одиночных "гениев"
> - сначала они должны доказать, что каждое их решение было взвешенным
> и не имеет альтернатив. А то, что Страус прикрутил ООП к
> ассемблеру - так это хобби, а не "стандарт"!Как-то так получилось, что это одиг из самых популярных языков программирования и альтернативы ему нет. Так что адекватные программисты смотрят на тебя как на известно что.
>> Вот потому, что это трудно, нельзя допускать в индустрию "поделки" одиночных "гениев"
>> - сначала они должны доказать, что каждое их решение было взвешенным
>> и не имеет альтернатив. А то, что Страус прикрутил ООП к
>> ассемблеру - так это хобби, а не "стандарт"!
> Как-то так получилось, что это одиг из самых популярных языков программирования и
> альтернативы ему нет. Так что адекватные программисты смотрят на тебя как
> на известно что.Не путайте C и С++
Ну ничего, оно, наверн, к 2025му году только выйдет. Сколько там уже 0х делается? )
C++11 и есть C++0x
Прочитал всю статью по ссылке, спасибо за информацию. Единственная проблема состоит в том, что будет необходимо создание новых (и переписывание старых приложений), использующих новые фишки языка, а на это уйдет немало времени.
> Прочитал всю статью по ссылке, спасибо за информацию. Единственная проблема состоит в
> том, что будет необходимо создание новых (и переписывание старых приложений), использующих
> новые фишки языка, а на это уйдет немало времени.Зачем? Это, блин, не проприетарные "фичи" отдельных производителей CPU из 80-x, для поддержки которых надо было специальный ассемблерный код писать. И переписывать ничего не надо. Хочешь - бери и пиши новый код с C++0x фичами (что можно было делать и делали уже много лет), не хочешь - не пиши.
Как ни странно, "специальный ассемблерный код" пишут и в 2011 году. Кто же виноват что аккуратное переписывание критичного куска на ассемблере (например с SIMD командами) повышает скорость работы этого куска порой в несколько раз? Яркий пример - кодеки ;). Или совершенно любая задача для скоростных вычислений, например любой уважающий себя крэкер хешей внаглую использует жесточайший asm. А то и GPU вообще.
>Хочешь - бери и пиши новый код с C++0x фичами (что можно было делать и делали уже много лет), не хочешь - не пиши.Если не писать новый код, то тогда и смысла во внедрении нового стандарта никакого, так как текущий код прекрасно компилируется и старыми компиляторами.
> C++11 supports in-class initialization of data members:Вот эта мелочь реально могла появиться в этом языке еще лет двадцать назад. Неужели никому до сих пор не мешала необходимость запихивать инициализацию даже самых тривиальных членов в конструктор класса?
> In C++11 a constructor may call another constructor of the same class
Аналогично - что мешало сделать это раньше? Правда, более интересным вариантом был бы вызов одного конструктора из любой точки другого. Чаще варианты конструктора требуют предварительной подготовки, сводящей исходные данные к тем, которые нужны классу для создания. Естественно, операции в конструкторе до вызова другого конструктора не должны обращаться к нестатическим членам и методам класса.
Кстати инициализация не статичных членов класса в месте их объявления реализована в последних сборках gcc в флагом стандарта 0x.
>> C++11 supports in-class initialization of data members:
> Вот эта мелочь реально могла появиться в этом языке еще лет двадцать назад20 лет назад программирование было более строгим. Создание экземпляра класса происходит нигде, кроме конструктора - значит только там и должна быть инициализация мемберов. Сейчас, видимо, уже всем похрен - запихнём в объявление, хренли.
>> In C++11 a constructor may call another constructor of the same class
> Аналогично - что мешало сделать это раньше?Вот тут, пожалуй, согласен - это нужно.
> Правда, более интересным вариантом был бы вызов одного конструктора из любой точки другого.
А вот это уже бред.
Ну представьте, что у вас сложный класс с кучей, например, нестатичных переключателей (bool), которые нужно инициализировать в конструкторе.
Причем классов несколько, они все наследники некоего базового, и переключатели инициализируются по-разному.
У каждого из классов три конструктора: один - без аргументов, второй - с аргументами, рассыпанными по переменным, третий - с теми же аргументами, нетривиально собранными в один класс.
Не многовато ли тупого, однотипного кода придется писать с текущими ограничениями?И главное - в чем принципиальная невозможность для компилятора подставить инициализацию нестатических членов в каждый объявленный конструктор автоматически?
> Бьерн Страуструп, создатель C++, упомянул
> в одном из интервью, что C++11 ощущается как новый язык, части
> которого сочетаются друг с другом лучше.Положительная новость! Наконец-то у старика Страустрапа есть железная отмазка!! %) "Наше .....ммммм.... язык! в _следующем _релизе _стандарта станет ......ммммммм.... уже не так плох. Нет, правда!"
Блин, а пропертей как небыло так и нет :(
Если они вам действительно нужны:
http://en.wikipedia.org/wiki/Property_%28programming�...
> Блин, а пропертей как небыло так и нет :(И, надеюсь, никогда не будет.
С++ в лучших традициях голивудского хорора: на последнем кадре из могилы вдруг высовывается рука. И становится ясно: труп все еще не труп.Лично мне С++ напоминает автомобиль с ручной коробкой: все через это должны пройти, чтобы больше к этому не возвращаться.
Крутая освоения - почти ветикальна ( освоить нужно все и сразу, не всем дано :( ) потому и нытье.
> С++ в лучших традициях голивудского хорора: на последнем кадре из могилы вдруг
> высовывается рука. И становится ясно: труп все еще не труп.Звездите дальше. Весь софт написан на C и C++, и ничего на милых вашему сердцу тормозных динамических язычках с VM и GC.
> Лично мне С++ напоминает автомобиль с ручной коробкой: все через это должны
> пройти, чтобы больше к этому не возвращаться.Вы банальнейший криворукий неосилятор :)
та нормальные плюсы. конечно можно было бы упростить некоторые абсолютно рутинные и ненужные в современном мире вещи, но в списке их нет к сожалению. авторы заядлые плюсищники, готов поспорить что они на других языках никогда ничего не разрабатывали и потому ихнее видение улучшений именно такое..
> та нормальные плюсы. конечно можно было бы упростить некоторые абсолютно рутинные и
> ненужные в современном мире вещи, но в списке их нет кТут скорее учитывая опыт C++ сделают новый язык. Примерно как с perl6.
>готов поспорить что они на других языках никогда ничего не разрабатывали и потому ихнее видение улучшений именно такоеДело не только в том, что они заядлые плюсищники, а еще и в обратной совместимости. А это накладывает ограничения на возможность выбрасывания чего-либо из языка.