| 1.3, Аноним (-), 12:51, 27/03/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +5 +/– |
Давно наблюдаю за тем что пихают в C++0X.
Простите за выражение, но это 3.14здец.
| | |
| 1.6, gegMOPO4 (ok), 13:47, 27/03/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
 Неужели я дожил?
Интересно, а Visual C++ будет и с этим стандартом тормозить и криво его поддерживать, как было в 6.0 с C++98?
| | |
| |
| 2.55, vle (ok), 19:53, 28/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
 Я бы боялся не того, что что какая-то часть стандарта не поддерживается,
а того, что компилироваться будет "нестандартный" код, то есть
недостаточно жестких проверок в компиляторе.
| | |
|
| |
| |
| 3.20, Anonym (?), 16:42, 27/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
да не C++0x, а C1X - это стандарт который вместо С99. Не С++, а С.
| | |
| |
| 4.21, dmi3s (ok), 16:46, 27/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
 > да не C++0x, а C1X - это стандарт который вместо С99. Не
> С++, а С.
Oops.
| | |
|
|
| |
| 3.33, anonymous (??), 00:15, 28/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
 > А зачем? Что нужно изменять в C99?
упрощать. а то в m$ за 10 лет так и не осилили в m$vc его реализовать.
| | |
| |
| 4.34, анонимус (??), 04:19, 28/03/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> а то в m$ за 10 лет так и не осилили в m$vc его реализовать.
Это проблемы m$, они постоянно тормозят
| | |
| |
| 5.63, Ytch (?), 02:44, 29/03/2011 [^] [^^] [^^^] [ответить]
| +/– | |
>MS может реализовать brainfuck. Проще особо некуда ;).
Они и в нем, блин, какие-нибудь "крышечки" и "тильдочки" добавят (чтоб отличать managed-brainfuck от unsafe-brainfuck). А ораклу пора BfuckVM забубенить кроссплатформенный. Вот уж будет точно "write once, fuck brain everywhere".
| | |
| 5.64, anonymous (??), 07:15, 29/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
>> упрощать.
> MS может реализовать brainfuck. Проще особо некуда ;).
они-то конечно, могут. только m$ brainfuck будет, как обычно, ни с кем не совместим, дажем с оригиналом.
| | |
|
|
|
|
| 1.26, hipom (?), 19:30, 27/03/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>Утвержден финальный черновой вариант стандарта C++0X
очередной раз утвердили
тоесть утомили
в прошлом и позапрошлом году тоже что то подготавливали и утверждали
пока не будет финальная, промежуточные результаты не интересны
| | |
| |
| 2.29, const86 (ok), 21:09, 27/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
 > Многопоточность, сборщик мусора и кофеварку уже прикрутили?
Многопоточность прикрутили. А за кофеваркой и мусором, как уже сказали, к яве.
| | |
| 2.30, koblin (ok), 21:44, 27/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
 видимо предполагается, что на с++ пишут люди способные написать свой менеджер памяти и другие плюшки =)
| | |
|
| 1.35, xcode (?), 12:03, 28/03/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Впечатление - вносят кучу всякой хрени, лишь бы не нарушить совместимость.
Почему нельзя было пойти другим, более красивым и естественным путем? Тем, которым Стауструп пошел много лет назад, когда создавал С++ на основе Си.
* существующий С++ не трогать;
* разработать НОВЫЙ язык программирования, с новым синтаксисом, максимально близким по духу к С/С++ (правильнее - к "си-подобным языкам"), но все-же несовместимым с современным С++. Более простой, реализующий лучшие идеи из языков Java, C#, D, ObjectiveC, Go, Python, Ruby, Scala, Nemerle и т.д.
* придумать новое расширение файлов (типа cppx)
* сказать, что вот он, новый стандарт; компиляторы должны поддерживать ОБА синтаксиса, но в рамках одного файла должен быть какой-то один синтаксис. В проекте можно использовать оба типа файлов, объектники должны быть полностью совместимы и линковаться одним линкером.
что это даст?
+ не будет синтаксических извращений С++0x и прочего тяжелого бреда
+ будет четкое разделение "старых" и "новых" исходников, сразу будет понято чем можно компилировать код - достаточно посмотреть на расширение файла
+ появится возможность внести гораздо больше новшеств, не переусложняя язык (т.к. "переусложнения" как правило возникают не из-за новшеств, а из-за необходимости сохранения совместимости со старым кодом); появится возможность облегчить синтаксис языка, т.к. очевидно что в С++ он избыточен
+ программисты смогут постепенно переходить на новый язык, сохраняя полную совместимость со старым кодом (более того - даже не задумываясь о вопросах совместимости) - просто по мере необходимости добавлять новые файлы с новым расширением в проект, ну и при наличии желания/свободного времени неспеша переписывать старый код.
| | |
| |
| 2.41, dmi3s (ok), 14:49, 28/03/2011 [^] [^^] [^^^] [ответить] | +/– | Можно пояснить мысль Какая именно хрень привнесена для сохранения совместимости... большой текст свёрнут, показать | | |
| |
| 3.42, ананим (?), 15:19, 28/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
согласен по всем пунктам. тем более что в С++ и так всё от
>Java, C#, D, ObjectiveC, Go, Python, Ruby, Scala, Nemerle
есть. и даже больше. и вот это как раз для многих проблема.
рискую нарваться на холи вар со сторонниками чистоты ооп, но как-го фига в стандарт не встроят нечто подобное слотам/сигналам как в кутэ и интроспекцию?
убили бы сразу все подобные разговоры.
| | |
| |
| 4.44, dmi3s (ok), 15:46, 28/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
> согласен по всем пунктам. тем более что в С++ и так всё
> от
>>Java, C#, D, ObjectiveC, Go, Python, Ruby, Scala, Nemerle
> есть. и даже больше. и вот это как раз для многих проблема.
Альтернативная история пустила корни? Кстати, на вскидку, у каго из этих языков управление памятью такое же как в плюсах?
> рискую нарваться на холи вар со сторонниками чистоты ооп, но как-го фига
> в стандарт не встроят нечто подобное слотам/сигналам как в кутэ и
> интроспекцию?
boost::signal2 и boost::type_traits, если оперировать в рамках термина "что-то подобное".
> убили бы сразу все подобные разговоры.
Ну как? Ранил хотя бы?
#include <best/regards>
| | |
| |
| 5.46, ананим (?), 16:07, 28/03/2011 [^] [^^] [^^^] [ответить]
| +/– | |
>Альтернативная история пустила корни? Кстати, на вскидку, у каго из этих языков управление памятью такое же как в плюсах?
вас интересует сегментная адресация памяти или страничная? или смешанная? :D
>boost::signal2 и boost::type_traits, если оперировать в рамках термина "что-то подобное".
boost - не стандарт.
и возможно хорошо что не стандарт.
>Ну как? Ранил хотя бы?
скажем так, задел.
как там Страуструп говаривал? где-то внутри С++ живёт очень простой и логичный язык.
или что-то подобное.
| | |
| |
| 6.49, dmi3s (ok), 17:50, 28/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
>>Кстати, на вскидку, у каго из этих языков управление памятью такое же как в плюсах?
> вас интересует сегментная адресация памяти или страничная? или смешанная? :D
В списке не было асма. Интересует управление кучей: ручное/автоматическое или, подсказываю про ObjectiveC, смешанное.
>>boost::signal2 и boost::type_traits, если оперировать в рамках термина "что-то подобное".
> boost - не стандарт.
В C++ 0x type_traits уже в std. Кроме того, это пример, что если чужое брать не позволяют убеждения, то вполне можно написать самому.
> и возможно хорошо что не стандарт.
Это полигон для обкатки вещей, которые войдут в стандарт: shared_ptr, tuple, static_assert, date_time. И полигон такого размера, что я уверен, что хорошо.
>>Ну как? Ранил хотя бы?
> скажем так, задел.
> как там Страуструп говаривал? где-то внутри С++ живёт очень простой и логичный
> язык.
> или что-то подобное.
"Любая достаточно сложная программа на C или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp"
— Филип Гринспен.
| | |
| |
| 7.50, ананим (?), 18:25, 28/03/2011 [^] [^^] [^^^] [ответить]
| +/– | |
>В списке не было асма. Интересует управление кучей: ручное/автоматическое или, подсказываю про ObjectiveC, смешанное.
право, не стоит подсказывать. вопрос по управлению памятью (и в частности кучей), включая мусоросборники, настолько широко освещён уже в С++ и настолько многообразен, что все остальные языки просто выглядят ограниченными на этом фоне, если не сказать больше.
если выбирать из многообразия выбора или его отсутствия - я выберу многообразие.
данный вопрос освещён у Александреску и Саттера. цитата:
>Одна из самых сильных сторон C++ по сравнению с другими языками заключается в той мощи, которую C++ предоставляет программисту для управления памятью и другими ресурсами, в частности, для выборочного автоматического управления памятью.....
стр 138, том "Новые сложные задачи на C++".
вопрос управления памятью даже не хочу обсуждать. С++ тут вне конкуренции.
если вы путаете мощь в управлении с простотой использования, то это другой разговор. но как показывает практика, простота использования в большей степени достигается глубиной знаний и квалификацией.
о цитате Гринспина - хм. ну пусть моему ядру это скажет - 8Мб вместе со всеми необходимыми мне модулями.
| | |
| |
| 8.56, dmi3s (ok), 19:54, 28/03/2011 [^] [^^] [^^^] [ответить] | +/– | Остальные языки ограничены из-за того, что в C он подробно описан Или потому ... текст свёрнут, показать | | |
| |
| |
| Часть нити удалена модератором |
| 10.59, dmi3s (ok), 21:56, 28/03/2011 [ответить] | +/– | Смелое утверждение Мне в него поверить или у вас есть доказательства Я обычно ... текст свёрнут, показать | | |
| |
| |
| 12.66, dmi3s (ok), 12:54, 29/03/2011 [^] [^^] [^^^] [ответить] | +/– | Я не силен в сленге и в беспредметном разговоре Поэтому, перед вынесением окноч... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
|
|
| 2.45, Аноним (-), 15:53, 28/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
и каким же Путем пошел Страуструп когда создавал C++? Путем Обратной Совместимости, даже если она не полная. и всё равно хватает головной боли при портировании C -> C++, а вы предлагаете добавить еще и анальную при портировании C++ -> C+=2
такое никому не надо
| | |
|
| 1.43, xcode (?), 15:35, 28/03/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
В С++ много чего есть, но там все это через многоэтажные шаблоны, макросы и т.д. А хочется прямого естественного способа.
Smalltalk, Haskell, Forth, K/J - это не си-подобные языки, и впихивать их никто не предлагает. А вот например концепция сообщений из ObjC, сигналов/слотов qt и dynamic c#4 имеют общую базу, и их неплохо бы объединить в новом языке.
Интроспекция - да, на современном С++ ее можно делать извращенными макросами - но почему не сделать нормально?
Автоматическая и ручная сборка мусора вполне себе сочетаются для разных видов объектов. Никого ведь не смущает, что сочетаются стевовые переменные и переменые на куче? Я бы оставил ручное управление памятью для специальных случаев (все-же С++ низкоуровневый язык) и ввел синтаксис для выделения памяти со сборкой мусора.
Ну и лямбды с делегатами - даже в C# последнем не раскрыли всех возможностей этого средства. А для совместимости с С++ вполне можно сделать специальный класс с ограниченным функционалом. Если нужно больше - ну смени расширение файла и устрани несоответствия, как делали раньше при переходе с си на си++...
| | |
| |
| 2.48, dmi3s (ok), 17:20, 28/03/2011 [^] [^^] [^^^] [ответить] | +/– | Там есть много кусочков всего Только вот для полноценной реализации signal slot... большой текст свёрнут, показать | | |
| 2.53, yakovm (?), 19:10, 28/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
> В С++ много чего есть, но там все это через многоэтажные шаблоны,
> макросы и т.д. А хочется прямого естественного способа.
When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop.
(Alan Perlis)
| | |
|
| 1.47, Stax (ok), 17:15, 28/03/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Интересно, почему thread-local storage не поддерживается в GCC совсем никак :o Даже MSVC держит, судя по таблице. Фича-то реально весьма полезная, да и в варианте C99 она давно работает в GCC.
| | |
| |
| 2.51, ананим (?), 18:43, 28/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
это случаем не там, где стоит ***?
где *** — Partial support
нет уж! partial support от мс - это головная боль того кто её будет юзать. нафиг.
согласно таблице гцц поддерживает гораздо больше фич. и без partial support. например Unicode String Literals в гцц есть. и это куда важнее.
а для tls/tsd и другие реализации есть - для примера см. класс QThreadStorage<T> в qt http://doc.qt.nokia.com/4.7/qthreadstorage.html
| | |
|
| |
| 2.65, dq0s4y71 (??), 12:02, 29/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
Можно подумать, без квадратных скобок синтаксис С++ сейчас недостаточно угрёбищен. Мне лично хватает угрёбищных угловых скобок в шаблонах и операторах ввода\вывода...
| | |
|
|
