LINUX.ORG.RU

быстрый взгляд на C++0x


0

0

Страуструп описал вкратце улучшения, грозящие всем программёрам С++ в следующем стандарте, который должен выйти к 2009 году. Немалая толика софта под линукс пишется на С++ поэтому новость будет интересна не только разработчикам, пишущим на С++. Итак, что же нам светит:

* язык будет лучше поддерживать системное программирование
* язык будет проще в обучении и преподавании

Обещается опциональная сборка мусора и поддержка параллелизма. Внимание разработчиков стандарта фокусируется на расширениях, которые "меняют способ которым люди думают" (дословно!). Добавлено наиболее значительное расширение - "концепция" как "тип типов" (посредством where-выражения) и обобщенный список инициализации. Обещано, что вектора базовых типов будут работать не медленнее встроенных массивов тех же типов. В общем всё для того, чтобы сделать обощённое программирование таким же мейнстримом как объектно-ориентированное.
Также комитет по языку уже проголосовал за добавку в STL хешей, регекспов, смарт-поинтеров, генераторов случайных чисел и математических спец-функций. Появится новый тип итераторов - auto с автоопределением своего типа. Наконец-то стандартизаторы обещают уделять внимания простоте не меньше, чем гибкости но, тем не менее, не в ущерб последней.

Просьба языковой флейм не начинать, языки всякие важны, языки всякие нужны.

>>> Подробности

★★

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

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

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

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

В том и прикол, что язык и средства разработки в данном случае хорошо помогают. Дебаггер запускать, как тут для плюсов выше предлагали, не приходится :)

anonymous
()

Поражаюсь убогости некоторых посетителей ЛОРа.

Такое ощущение, что 90% посетителей - 15-летние гормонально озабоченные идиоты.

Пора понять, что НЕТ, НЕ БЫЛО И НИКОГДА НЕ БУДЕТ "Серебряной пули" -- универсального средства от всех проблем или универсального ЯП.

Ну нельзя, НЕЛЬЗЯ на Питоне/Perl/Java/C++/(добавить свой любимый ЯП) написать ядро RTOS. Также как нельзя на C / ассемблере сделать дешевое, расширяемое и легко поддерживаемое вебприложение.

Из этого совершенно не следует, что один ЯП - дерьмо, а другой - крут везде и всегда.

Попытайтесь на любом бестиповом ЯП разложить матрицу 8 000 000 * 8 000 000. Угу?

Попытайтесь в три строчки на С реализовать хэш хэшей.

У каждого языка есть своя ниша. Да-да, и у C++ она тоже есть, как это ни странно. Или это не так, многоуважаемые любители KDE? Или, быть может, поклонники Gnome, вы скажете, что C фтопку?

Сколько еще примеров надо привести?

Короче: пофессионал от красноглазика отличается тем, что умеет выбирать инструмент под конкретную задачу, а не подгоняет задачу под инструмент.

P.S. Если ЯП позволяет сделать что-то (например, использовать указатели), совершенно необязятельно, их использовать, если не разбираешься во всех тонкостях. А вопить по поводу "указатели - это ужасно, нах такой ЯП" - это уровень детсада.

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

> Да-да, и у C++ она тоже есть, как это ни странно. Или это не так, многоуважаемые любители KDE?

...

> Короче: пофессионал от красноглазика отличается тем, что умеет выбирать инструмент под конкретную задачу, а не подгоняет задачу под инструмент.

Вроде когда зачинали KDE, его авторы были именно что красноглазиками, едва окончившими колледж. В котором их ничему кроме С++ не учили. Или это я с qt перепутал?

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

> Прошу обратить внимание на "в разумное время". Когда объём .tar.gz с исходниками несколько [десятков] мегабайт а классов -- за несколько тысяч, и часть из них генерится из макросов с десятком аргументов, которые сами вызывают другие макросы, и в итоге оказывается, что за всем этим скрывается template от template'а (ну обчитался кто-то Александреску, а головой подумать забыл)...

Макросы в общем-то к С++ относятся ровно на столько, насколько они относятся и к Си. Когда вы пугаете макросами, вы в общем-то льете бочку именно на Си.

Вложенные шаблоны? Ужас!!! Давайте не будем рассматривать код, написаный идиотами. Это же просто абсурдно! Просто все(надеюсь) знают, какое кол-во кода генерится при использовании вложенных шаблонов и так не делают. Я тоже могу предложить обсудить код на Си, который наполовину состоит из макросов и системных вызовов, чем докажу, что Си плохой язык. Вот Basic - это язык!

>> С++ как раз и позиционируется как язык с мощьнейшим уровнем reuse кода. То есть, это выходит неправда?

> Да, это неправда. Неправда, причём _абсолютная_.

Докажите! :)

> Хотите пример? Попробуйте хоть в одной книге, посвящённой OO & C++ найти пример сложнее однокнопочной микроволновой печки. Сомневаюсь, что найдёте.

Учебники по OLE :))))

> Кавалерийский наскок "отладчиком" годиться только если количество классов не превышает десятки. В реальной же жизни это не работает. Причём именно тогда, когда это особенно нужно.

Это уже совсем лирика какая-то просто.

P.S: Никто не говорит, что Си - плохой язык. Просто С++ - лучше, чем Си. Так уж вышло, что лучшее враг хорошего.

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

svu *** (*) (06.01.2006 17:29:54)

> В принципе, мне даже добавить нечего.

svu, что-то страшилки быстро закончились. Спасибо за поднятое настроение. Юмор оценил, а местами даже смеялся. Пофлеймили таки. Предлагаю, оставить тему на откуп питонистам. У нас, как я понимаю, все копья уже сломаны :)))

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

Ядро RTOS можно хоть на Жабе написать, дурачок. А ниши у C++ как раз таки и нет. Везде, где он применяется, гораздо лучше было бы что либо другое. Нет области, где он был бы лучшим.

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

>Учебники по OLE :))))

О валяется тут у меня один. Там все сплош код генерированный студией с комментариями "руками не трогать". ;))

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

>> gcj, вроде как в натив компилит, нет? Потом, практика показала, что JIT не шибко хуже.

> gcj хуже hotspot'а как по скорости, так и по потреблению памяти. почему он должен быть лучше то?

Ты не понял, это было два разных ответа. Один - что, вроде как есть нативный компилятор, худо-бедно, а второй, что JIT по скорости не особенно уступает компиляторам вообще.

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

>Ядро RTOS можно хоть на Жабе написать, дурачок.

Примеры в студию, ага?

>А ниши у C++ как раз таки и нет. Везде, где он применяется, гораздо лучше было бы что либо другое. Нет области, где он был бы лучшим.

Ай-Ай! Конечно же, анонимный аналитик с ЛОРа знает на чем лучше писать софт.

Скажите, аналитик, Вы где работаете? Вы можете дать ссылку на Ваше резюме и/или портфолио?

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

Советую тебе ознакомиться со смыслом термина "real time", жывотное. Супер-производительности от RTOS не требуется, жывотное. Требуется гарантированное время отклика, жывотное. А это даже на жабке достижимо, жывотное.

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

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

>а я тебе показываю технологию, которая будет в этой задаче эффективнее.

Та небудет эффективнее небудет, еслиб было эффективнее то уже давно былоб а пока нет и небудет.

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

Дебил ты. Рынок НИКОГДА не руководствуется эффективностью. Умри.

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

Ну ок, закончим. Особенно мне понравилась мысль что плюсы - это такое лучшее, которое враг хорошего С. ;)

О, кстати, могу перевести беседу в иную плоскость. У меня последнее время начинает появляться подозрение, что пресловутый шестой перл - тоже "враг хорошего" (при том, что я не любитель перла вообще). История с шестым перлом навевает ассоциации с тем, что Брукс называл "второй системой";)

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

> Ядро RTOS можно хоть на Жабе написать, дурачок.

Нельзя. Не выкинув из нее garbage collector. Иначе нельзя гарантировать время отклика.

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

>>>Сами приложения памяти много не жрут. GHC такой прожорливый от шибко умных оптимизаций.

>>>anonymous (*) (06.01.2006 14:21:56)

http://shootout.alioth.debian.org/benchmark.php?test=revcomp&lang=all&...

>Ну и бде там жаба? У жабы шибко больше рантайм.

Хаскель (ghc) использует _очень_ много _памяти_ на нетривиальных (типа реализации ДСЛ) программах, даже легендарная по прожорливости ява просто отдыхает.

Если надо обработать десятки запросов одновременно, то преимущества PF языка по распаралеливанию на кластер - мертвому припарка - памяти все равно нехватит, а мерить рантам программы в свопе - это конечно круто.

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

Определенно согласен с Вами, сэр. В добавку хочу добавить такую ссылку: http://www.osp.ru/os/2000/12/045.htm#incuts

Правда статейка старая, если кто-то уверен что что-то изменилось, мне интересно узнать.

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

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

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

> История с шестым перлом навевает ассоциации с тем, что Брукс называл "второй системой";)

Хорошо, что не с "третьим Рейхом" или "пятой колонной" ;)

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

Что-то они про gc там мало написали. Его непредсказуемость (в обычной j2se) убивает гарантию времени отклика.

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

Если ты не выделяешь память и не плодишь мусор, он и не используется, проход по young generation занимает фиксированное время, а второго прохода просто не будет.

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

>Его непредсказуемость (в обычной j2se) убивает гарантию времени отклика.

А слабо другой gc включить а не дефаултный? Например -Xincgc?

Уж не говоря о том что в 6той java будет gc который вообще никогда stop-the-world не делает.

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

Гхм. Если не выделять память - это как же код-то вяать? В жабе крайне тяжело (если вообще возможно) реально работать, не создавая объектов по ходу жизни... И обойтись одним young generation - тоже весьма проблематично.

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

Вопрос такой: можно ли построить gc, время работы которого будет гарантированно О(1) на произвольном жабском коде (при этом он будет реально очищать память от всего мусора)? Если да - тогда все мои опасения беспочвенны и я их забираю назад.

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

> > Ядро RTOS можно хоть на Жабе написать, дурачок.

> Нельзя. Не выкинув из нее garbage collector. Иначе нельзя гарантировать время отклика.

JSR1: Real-time Specification for Java

http://www.jcp.org/en/jsr/detail?id=1

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

Но проблема в том, что C++ и Java (в большей степени) - по языковому design - это языки 70-х, а с тех пор было много чего сделано... Так что D - мертворожденный (это не к тому, что хуже C++ или Java - как и многие языки, несправедливо забытые).

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

> это языки 70-х, а с тех пор было много чего сделано...

Да?!?

Интересненько. Перечисли по пунктам, что же нового было сделано с 70-х. Кроме GADT как-то даже ничего в голову и не приходит.

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

А применение монад в функциональных языках? Расширенные системы типов на основе СТ Хиндли-Милнера (e.g. в Haskell)?

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

> А применение монад в функциональных языках?

Ещё в Миранде было, ну а теории и вовсе сто лет в обед будет.

> Расширенные системы типов на основе СТ Хиндли-Милнера (e.g. в Haskell)?

А это вообще в 50х было придумано, тов. Робин Милнер его догадался заюзать последовательно только в 88-м, но известен он был задолго до того, и применялся эпизодически.

Так что реально новые идеи в теормии типов - разве что только вокруг GADT.

Да, в 80-е было придумано много полезных техник компиляции, но непосредственно к семантике языков это отношения не имеет.

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

1. Я говорил о применении в языках - не о базовой теории. По сравнению с упомянутым языком D - любое из расширений языка в GHC - большое достижение :-(

2. Тезники компиляции тоже нельзя забывать - как ни как именно они определяют эффективность реализации того или иного языка.

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

А техническое превосходство никак не коррелирует с распространенностью языка. Сейчас это больше вопрос грамотного маркетинга.

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

Дешевенькие достоинства. Непонятно, почему OCaml, CL, Haskell не получили распространения - рядом с ними все эти жабы и близко не валялись.

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

Да и техническое превосходство D над C++ мало, тем более нет принципиальных преимуществ (кроме GC?).

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

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

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

А-а понял: они будут программы на Haskell полностью в монаде IO писать! Настоящие быдлокодеры на любом языке пишут как на Basic'е ;-)

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

Но ведь C++ - императивный язык с привычными быдлокодерам переменными (про const не все знают), циклами for/while/do-while, функциями, структурами и классами. Об управлении памятью они не беспокоятся. Ну не будешь же ты ПТУшникам объяснять лямбда-счисление ;-)) Они этого не поймут.

Да и Java, и C# создавались с учетом знания быдлокодерами синтаксиса С (типа легче учить ;-)))))))

Есть интересный (в практическом плане) язык для .NET: Nemerle - функциональный (не чисто) язык с поддержкой ООП и, ЕМНИП, метапрограммирования.

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

Не, быдлокодеров дисциплинировать можно, введением строгого Q/A и стандартов кодирования. Даже с Хаскеллем.

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

За год новых можно наклепать, без груза императивных знаний, да и не нужны птушники, можно выпускников CS-факультетов задействовать.

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

Да за@#$%^& уже со своими быдлокодерами, образованцы!

Здесь обсуждаются вопросы развития языков С-семейства, а не ваши кульхакселы! Создайте другую тему и там обсуждайте свои проблемы!

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