The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Утвержден финальный черновой вариант стандарта C++0X"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Утвержден финальный черновой вариант стандарта C++0X"  +/
Сообщение от opennews (??) on 27-Мрт-11, 12:22 
Комитет ISO по стандартизации языка C++ утвердил (http://herbsutter.com/2011/03/25/we-have-fdis-trip-report-ma.../) финальный черновой вариант международного стандарта C++0X (http://www2.research.att.com/~bs/C++0xFAQ.html), идущего на смену ISO/IEC 14882:2003. Утверждение финального черновика подразумевает завершение фазы согласования состава стандарта и перехода к оформлению документов для передачи черновика в комитет ITTF. Завершить подготовку стандарта планируется в августе 2011 года. Стандарт выйдет под именем C++ 2011.


Большинство представленных в стандарте возможностей уже поддерживаются в таких компиляторах, как GCC и Visual C++ (http://blogs.msdn.com/b/vcblog/archive/2010/04/06/c-0x-core-...). Подробный обзор новшеств C++0X можно найти в википедии (http://ru.wikipedia.org/wiki/C%2B%2B0x). Статус поддержки элементов стандарта в GCC можно посмотреть здесь (http://gcc.gnu.org/projects/cxx0x.html).

URL: http://developers.slashdot.org/story/11/03/26/1949225/ISO-C-...
Новость: http://www.opennet.dev/opennews/art.shtml?num=30038

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


5. "Утвержден финальный черновой вариант стандарта C++0X"  +8 +/
Сообщение от anonymous (??) on 27-Мрт-11, 13:43 
> Ну в Visual C++ реализации более полные как всегда, в отличии от GCC

Самая полная как раз в GCC: http://wiki.apache.org/stdcxx/C++0xCompilerSupport

Ответить | Правка | Наверх | Cообщить модератору

3. "Утвержден финальный черновой вариант стандарта C++0X"  +5 +/
Сообщение от Аноним (??) on 27-Мрт-11, 12:51 
Давно наблюдаю за тем что пихают в C++0X.
Простите за выражение, но это 3.14здец.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Утвержден финальный черновой вариант стандарта C++0X"  +/
Сообщение от logosman (ok) on 27-Мрт-11, 14:00 
точно, 3.14здец^2
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

6. "Утвержден финальный черновой вариант стандарта C++0X"  +2 +/
Сообщение от gegMOPO4 (ok) on 27-Мрт-11, 13:47 
Неужели я дожил?

Интересно, а Visual C++ будет и с этим стандартом тормозить и криво его поддерживать, как было в 6.0 с C++98?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

55. "Утвержден финальный черновой вариант стандарта C++0X"  +/
Сообщение от vle (ok) on 28-Мрт-11, 19:53 
Я бы боялся не того, что что какая-то часть стандарта не поддерживается,
а того, что компилироваться будет "нестандартный" код, то есть
недостаточно жестких проверок в компиляторе.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

9. "Утвержден финальный черновой вариант стандарта C++0X"  +1 +/
Сообщение от Мужик32 (ok) on 27-Мрт-11, 14:10 
Не прошло и 20 лет.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

11. "Утвержден финальный черновой вариант стандарта C++0X"  +/
Сообщение от Anonym on 27-Мрт-11, 15:20 
а когда выйдет C1X?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

15. "Утвержден финальный черновой вариант стандарта C++0X"  +/
Сообщение от dmi3s email(ok) on 27-Мрт-11, 15:55 
The new International Standard for Programming Language C++ is expected to be published in summer 2011.

http://herbsutter.com/2011/03/25/we-have-fdis-trip-report-ma...

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

20. "Утвержден финальный черновой вариант стандарта C++0X"  +/
Сообщение от Anonym on 27-Мрт-11, 16:42 
да не C++0x, а C1X - это стандарт который вместо С99. Не С++, а С.
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

21. "Утвержден финальный черновой вариант стандарта C++0X"  +/
Сообщение от dmi3s email(ok) on 27-Мрт-11, 16:46 
> да не C++0x, а C1X - это стандарт который вместо С99. Не
> С++, а С.

Oops.

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

31. "Утвержден финальный черновой вариант стандарта C++0X"  +/
Сообщение от VarLog email(ok) on 27-Мрт-11, 22:56 
А зачем? Что нужно изменять в C99?
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

33. "Утвержден финальный черновой вариант стандарта C++0X"  +/
Сообщение от anonymous (??) on 28-Мрт-11, 00:15 
> А зачем? Что нужно изменять в C99?

упрощать. а то в m$ за 10 лет так и не осилили в m$vc его реализовать.

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

34. "Утвержден финальный черновой вариант стандарта C++0X"  +/
Сообщение от анонимус (??) on 28-Мрт-11, 04:19 
> а то в m$ за 10 лет так и не осилили в m$vc его реализовать.

Это проблемы m$, они постоянно тормозят

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

54. "Утвержден финальный черновой вариант стандарта C++0X"  +/
Сообщение от User294 (ok) on 28-Мрт-11, 19:45 
> упрощать.

MS может реализовать brainfuck. Проще особо некуда ;).

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

63. "Утвержден финальный черновой вариант стандарта C++0X"  +/
Сообщение от Ytch on 29-Мрт-11, 02:44 
>MS может реализовать brainfuck. Проще особо некуда ;).

Они и в нем, блин, какие-нибудь "крышечки" и "тильдочки" добавят (чтоб отличать managed-brainfuck от unsafe-brainfuck). А ораклу пора BfuckVM забубенить кроссплатформенный. Вот уж будет точно "write once, fuck brain everywhere".

Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

64. "Утвержден финальный черновой вариант стандарта C++0X"  +/
Сообщение от anonymous (??) on 29-Мрт-11, 07:15 
>> упрощать.
> MS может реализовать brainfuck. Проще особо некуда ;).

они-то конечно, могут. только m$ brainfuck будет, как обычно, ни с кем не совместим, дажем с оригиналом.

Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

19. "Утвержден финальный черновой вариант стандарта C++0X"  +1 +/
Сообщение от dmi3s email(ok) on 27-Мрт-11, 16:32 
Ну русскоязычную вики зря ссылку дали: там кастрированное описание. Лучше уж на английскую версию либо на FAQ Страуструпа.

http://www2.research.att.com/~bs/C++0xFAQ.html

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

26. "Утвержден финальный черновой вариант стандарта C++0X"  +/
Сообщение от hipom on 27-Мрт-11, 19:30 
>Утвержден финальный черновой вариант стандарта C++0X

очередной раз утвердили
тоесть утомили
в прошлом и позапрошлом году тоже что то подготавливали и утверждали

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

27. "Утвержден финальный черновой вариант стандарта C++0X"  +/
Сообщение от dq0s4y71 (??) on 27-Мрт-11, 19:35 
Многопоточность, сборщик мусора и кофеварку уже прикрутили?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

28. "Утвержден финальный черновой вариант стандарта C++0X"  +1 +/
Сообщение от linux_must_die (ok) on 27-Мрт-11, 20:13 
это уже есть, java называется
Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

29. "Утвержден финальный черновой вариант стандарта C++0X"  +/
Сообщение от const86 (ok) on 27-Мрт-11, 21:09 
> Многопоточность, сборщик мусора и кофеварку уже прикрутили?

Многопоточность прикрутили. А за кофеваркой и мусором, как уже сказали, к яве.

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

30. "Утвержден финальный черновой вариант стандарта C++0X"  +/
Сообщение от koblin (ok) on 27-Мрт-11, 21:44 
видимо предполагается, что на с++ пишут люди способные написать свой менеджер памяти и другие плюшки =)
Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

32. "Утвержден финальный черновой вариант стандарта C++0X"  +2 +/
Сообщение от jershell email on 27-Мрт-11, 23:02 
qt stl и boost никто не отменял...
Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

39. "Утвержден финальный черновой вариант стандарта C++0X"  +/
Сообщение от ананим on 28-Мрт-11, 14:17 
openmp входит в гцц уже изкаропки.
http://ru.wikipedia.org/wiki/OpenMP
Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

35. "почему не пойти другим путем?"  +1 +/
Сообщение от xcode on 28-Мрт-11, 12:03 
Впечатление - вносят кучу всякой хрени, лишь бы не нарушить совместимость.
Почему нельзя было пойти другим, более красивым и естественным путем? Тем, которым Стауструп пошел много лет назад, когда создавал С++ на основе Си.

* существующий С++ не трогать;
* разработать НОВЫЙ язык программирования, с новым синтаксисом, максимально близким по духу к С/С++ (правильнее - к "си-подобным языкам"), но все-же несовместимым с современным С++. Более простой, реализующий лучшие идеи из языков Java, C#, D, ObjectiveC, Go, Python, Ruby, Scala, Nemerle и т.д.
* придумать новое расширение файлов (типа cppx)
* сказать, что вот он, новый стандарт; компиляторы должны поддерживать ОБА синтаксиса, но в рамках одного файла должен быть какой-то один синтаксис. В проекте можно использовать оба типа файлов, объектники должны быть полностью совместимы и линковаться одним линкером.

что это даст?
+ не будет синтаксических извращений С++0x и прочего тяжелого бреда
+ будет четкое разделение "старых" и "новых" исходников, сразу будет понято чем можно компилировать код - достаточно посмотреть на расширение файла
+ появится возможность внести гораздо больше новшеств, не переусложняя язык (т.к. "переусложнения" как правило возникают не из-за новшеств, а из-за необходимости сохранения совместимости со старым кодом); появится возможность облегчить синтаксис языка, т.к. очевидно что в С++ он избыточен
+ программисты смогут постепенно переходить на новый язык, сохраняя полную совместимость со старым кодом (более того - даже не задумываясь о вопросах совместимости) - просто по мере необходимости добавлять новые файлы с новым расширением в проект, ну и при наличии желания/свободного времени неспеша переписывать старый код.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

41. "почему не пойти другим путем?"  +/
Сообщение от dmi3s email(ok) on 28-Мрт-11, 14:49 
> Впечатление - вносят кучу всякой хрени, лишь бы не нарушить совместимость.

Можно пояснить мысль? Какая именно хрень привнесена для сохранения совместимости? И если ничего не привносить, то совместимость, как я понимаю, должна полностью пропасть?

> Почему нельзя было пойти другим, более красивым и естественным путем? Тем, которым
> Стауструп пошел много лет назад, когда создавал С++ на основе Си.

Александреску, D. Кстати, где он?

> * существующий С++ не трогать;
> * разработать НОВЫЙ язык программирования, с новым синтаксисом, максимально близким по
> духу к С/С++ (правильнее - к "си-подобным языкам"), но все-же несовместимым
> с современным С++. Более простой, реализующий лучшие идеи из языков Java,
> C#, D, ObjectiveC, Go, Python, Ruby, Scala, Nemerle и т.д.

Smalltalk, Haskell, Forth, K/J одновременно? Очень любопытный шалтай-болтай получится. Им уж точно кого угодно запугать до икоты можно будет.

> * придумать новое расширение файлов (типа cppx)

Замечательное предложение для разработчика языка. От создателей win explorer.

> * сказать, что вот он, новый стандарт; компиляторы должны поддерживать ОБА синтаксиса,
> но в рамках одного файла должен быть какой-то один синтаксис. В
> проекте можно использовать оба типа файлов, объектники должны быть полностью совместимы
> и линковаться одним линкером.

Это просто прекрасно. Каждое предложение по отдельности красиво, но вместе - они создают картину мира, достойную кисти Сальвадора Дали.
Я аж прослезился, как представил: в этом исходнике у меня автоматическая сборка мусора, а вот в том - ручная. И так хорошо, светло на душе стало, что захотелось написать анонимную лямбду и передать ее в старый и теплый C++.

> что это даст?
> + не будет синтаксических извращений С++0x и прочего тяжелого бреда

Почему не будет тяжелого бреда не понятно. Достаточно неправильно выбрать имя для расширения, и все.

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

Фанаты eplorer-a ликуют. Остальные недоумевают, как же до этого собирали приложения с использованием разных ЯП в одном проекте.

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

Больше, больше новшеств! Воскресим Concepts, сделаем полноценный Reflection!
Да и вообще - недостаточное количество новшеств - основная претензия сообщества к разработчикам нового стандарта.

> появится возможность облегчить синтаксис языка, т.к. очевидно что
> в С++ он избыточен

Ох, не говорите. class/struct чего только стоят. И ведь, главное, ну ничего же не сделали в новом стандрарте. Нет чтобы ввести auto или decltype. Да и синтаксис - это действительно одно из самых больных мест. Хорошо хоть, с семантикой повезло. Ну и вообще, если уж создатели берут какую идею, то целиком. Не выдергивают по кусочкам сладости, а честно воплощают полноценную, строгую, ортогональную концепцию.
</sarcasm>

У вас назойливая церебральная встудия. Извините за плохую новость.

#include <best/regards>

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

42. "почему не пойти другим путем?"  +/
Сообщение от ананим on 28-Мрт-11, 15:19 
согласен по всем пунктам. тем более что в С++ и так всё от
>Java, C#, D, ObjectiveC, Go, Python, Ruby, Scala, Nemerle

есть. и даже больше. и вот это как раз для многих проблема.

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

Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

44. "почему не пойти другим путем?"  +/
Сообщение от dmi3s email(ok) on 28-Мрт-11, 15:46 
> согласен по всем пунктам. тем более что в С++ и так всё
> от
>>Java, C#, D, ObjectiveC, Go, Python, Ruby, Scala, Nemerle
> есть. и даже больше. и вот это как раз для многих проблема.

Альтернативная история пустила корни? Кстати, на вскидку, у каго из этих языков управление памятью такое же как в плюсах?

> рискую нарваться на холи вар со сторонниками чистоты ооп, но как-го фига
> в стандарт не встроят нечто подобное слотам/сигналам как в кутэ и
> интроспекцию?

boost::signal2 и boost::type_traits, если оперировать в рамках термина "что-то подобное".

> убили бы сразу все подобные разговоры.

Ну как? Ранил хотя бы?

#include <best/regards>


Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

46. "почему не пойти другим путем?"  +/
Сообщение от ананим on 28-Мрт-11, 16:07 
>Альтернативная история пустила корни? Кстати, на вскидку, у каго из этих языков управление памятью такое же как в плюсах?

вас интересует сегментная адресация памяти или страничная? или смешанная? :D
>boost::signal2 и boost::type_traits, если оперировать в рамках термина "что-то подобное".

boost - не стандарт.
и возможно хорошо что не стандарт.
>Ну как? Ранил хотя бы?

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

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

49. "почему не пойти другим путем?"  +/
Сообщение от dmi3s email(ok) on 28-Мрт-11, 17:50 
>>Кстати, на вскидку, у каго из этих языков управление памятью такое же как в плюсах?
> вас интересует сегментная адресация памяти или страничная? или смешанная? :D

В списке не было асма. Интересует управление кучей: ручное/автоматическое или, подсказываю про ObjectiveC, смешанное.

>>boost::signal2 и boost::type_traits, если оперировать в рамках термина "что-то подобное".
> boost - не стандарт.

В C++ 0x type_traits уже в std. Кроме того, это пример, что если чужое брать не позволяют убеждения, то вполне можно написать самому.

> и возможно хорошо что не стандарт.

Это полигон для обкатки вещей, которые войдут в стандарт: shared_ptr, tuple, static_assert, date_time. И полигон такого размера, что я уверен, что хорошо.

>>Ну как? Ранил хотя бы?
> скажем так, задел.
> как там Страуструп говаривал? где-то внутри С++ живёт очень простой и логичный
> язык.
> или что-то подобное.

"Любая достаточно сложная программа на C или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp"
— Филип Гринспен.

Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

50. "почему не пойти другим путем?"  +/
Сообщение от ананим on 28-Мрт-11, 18:25 
>В списке не было асма. Интересует управление кучей: ручное/автоматическое или, подсказываю про ObjectiveC, смешанное.

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

стр 138, том "Новые сложные задачи на C++".
вопрос управления памятью даже не хочу обсуждать. С++ тут вне конкуренции.
если вы путаете мощь в управлении с простотой использования, то это другой разговор. но как показывает практика, простота использования в большей степени достигается глубиной знаний и квалификацией.
о цитате Гринспина - хм. ну пусть моему ядру это скажет - 8Мб вместе со всеми необходимыми мне модулями.

Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

56. "почему не пойти другим путем?"  +/
Сообщение от dmi3s email(ok) on 28-Мрт-11, 19:54 
> вопрос по управлению памятью (и в частности кучей),
> включая мусоросборники, настолько широко освещён уже в С++ и настолько многообразен,
> что все остальные языки просто выглядят ограниченными на этом фоне, если
> не сказать больше.

Остальные языки ограничены из-за того, что в C++ он подробно описан? Или потому что без пол-литры не разберешься? Логика в этом предложении есть, но вот что-то с ней не то.

> если выбирать из многообразия выбора или его отсутствия - я выберу многообразие.

Зачем? Про запас что ли? Может, перед тем как выбирать что-то, лучше определиться с критериями выбора: какую задачу и в каких условиях придется решать.

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

Я ни где не говорил ни про мощь, ни про простоту использования. А C++ в если и в лидерах, то только по возможности прострелить себе сами знаете что. Про удобство работы для простых прикладных программистов, например, лучше не говорить. А уж фраза о том, что "простота использования достигается знаниями и квалификацией" - так это просто чушь. Если я, предположим, знаю про подводные камни std::string, то это не значит, что мне становится удобнее ее использовать. Если я знаю, что порядок инициализации статических переменных в разных единицах трансляции не определен, то от этого мне ни чуть не легче написать корректный синглтон, ну и т.д.

> о цитате Гринспина - хм. ну пусть моему ядру это скажет -
> 8Мб вместе со всеми необходимыми мне модулями.

Ну вот опять логика потерялась. Вот если бы, предположим, ядро было бы размером в 800 метров, то это бы подтвердило бы цитату? А если 0.8, то опровергло бы безоговорочно?
Теплое и мягкое.

Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

59. "почему не пойти другим путем?"  +/
Сообщение от dmi3s email(ok) on 28-Мрт-11, 21:56 
> остальные языки - кастраты.

Смелое утверждение. Мне в него поверить или у вас есть доказательства?
> некоторые говорят что и одного яйца хватает.

Я обычно глазунью из одного яйца делаю. Если вы из двух, то это вопрос вкуса.
> а задачу, в которой нужны все методы (для разных подзадач) вы уже
> не представляете?

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

У вас интересный досуг.
> на компах всё больше как-то на С/С++. интересно, почему?

Давайте не съезжать с темы. С++. Не количество яиц, не кастрация, и даже не C. Именно C++. На каких компах, на каких ОСях, какие программы, как считали статистику. Предметно. Идеально - со ссылками на отчеты cloc или похожей утилиты.
> у-у-у! сори что отвлёк. больше не смею беспокоить.

Если дальше про обсуждаемый язык, да еще и с какой-нибудь аргументацией - смейте на здоровье.

Ответить | Правка | Наверх | Cообщить модератору

61. "почему не пойти другим путем?"  +/
Сообщение от ананим on 28-Мрт-11, 23:37 
>> остальные языки - кастраты.
>Смелое утверждение. Мне в него поверить или у вас есть доказательства?

и ещё какие! в прошлом тысячелетии ещё подсчитали выгоду и рентабельность на подготовку кодера и необходимый минимум знаний. в частности что в языке должно быть не более 30 конструкций, что диспетчер памяти должен быть 1 на все случаи жизни и т.д, и т.п.
так и появились ынтырпрайзное программирование и ынтырпрайзные языки.
по принципу - пусть и безобразно, зато однообразно.

остальное обсуждать интереса нет.

Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

66. "почему не пойти другим путем?"  +/
Сообщение от dmi3s email(ok) on 29-Мрт-11, 12:54 
>>> остальные языки - кастраты.
>>Смелое утверждение. Мне в него поверить или у вас есть доказательства?
> и ещё какие! в прошлом тысячелетии ещё подсчитали выгоду и рентабельность на
> подготовку кодера и необходимый минимум знаний. в частности что в языке
> должно быть не более 30 конструкций, что диспетчер памяти должен быть
> 1 на все случаи жизни и т.д, и т.п.
> так и появились ынтырпрайзное программирование и ынтырпрайзные языки.
> по принципу - пусть и безобразно, зато однообразно.

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

Итак. "Ынтырпрайзное", видимо, означает Enterprise. Видимо, подразумевается использование чего-то из серии SAP ERP и SQL-PL/SQL, если говорить об этапе внедрения.

Раскрывая ваше высказывание, получается что основной недостаток как внутренних языков ERP систем (описание бизнес-логики, отчеты ну и т.д.), так и SQL заключается в малом количестве конструкций ЯП и отсутствии ручного управления памятью.

Я все правильно понял?

> остальное обсуждать интереса нет.

Да уж.

Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

67. "почему не пойти другим путем?"  +/
Сообщение от потому on 29-Мрт-11, 14:30 
Основной недостаток - не квалифицированные кадры. 3 недели стажировки и прграммист на яве готов.
Примерно как вы, раз ещё не поняли.
Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

45. "почему не пойти другим путем?"  +/
Сообщение от Аноним (??) on 28-Мрт-11, 15:53 
и каким же Путем пошел Страуструп когда создавал C++? Путем Обратной Совместимости, даже если она не полная. и всё равно хватает головной боли при портировании C -> C++, а вы предлагаете добавить еще и анальную при портировании C++ -> C+=2
такое никому не надо
Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

43. "Утвержден финальный черновой вариант стандарта C++0X"  +/
Сообщение от xcode on 28-Мрт-11, 15:35 
В С++ много чего есть, но там все это через многоэтажные шаблоны, макросы и т.д. А хочется прямого естественного способа.
Smalltalk, Haskell, Forth, K/J  - это не си-подобные языки, и впихивать их никто не предлагает. А вот например концепция сообщений из ObjC, сигналов/слотов qt и dynamic c#4 имеют общую базу, и их неплохо бы объединить в новом языке.
Интроспекция - да, на современном С++ ее можно делать извращенными макросами - но почему не сделать нормально?
Автоматическая и ручная сборка мусора вполне себе сочетаются для разных видов объектов. Никого ведь не смущает, что сочетаются стевовые переменные и переменые на куче? Я бы оставил ручное управление памятью для специальных случаев (все-же С++ низкоуровневый язык) и ввел синтаксис для выделения памяти со сборкой мусора.
Ну и лямбды с делегатами - даже в C# последнем не раскрыли всех возможностей этого средства. А для совместимости с С++ вполне можно сделать специальный класс с ограниченным функционалом. Если нужно больше - ну смени расширение файла и устрани несоответствия, как делали раньше при переходе с си на си++...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

48. "Утвержден финальный черновой вариант стандарта C++0X"  +/
Сообщение от dmi3s email(ok) on 28-Мрт-11, 17:20 
> В С++ много чего есть,

Там есть много кусочков всего.

> но там все это через многоэтажные шаблоны,
> макросы и т.д. А хочется прямого естественного способа.
> Smalltalk, Haskell, Forth, K/J  - это не си-подобные языки, и впихивать
> их никто не предлагает. А вот например концепция сообщений из ObjC,
> сигналов/слотов qt и dynamic c#4 имеют общую базу, и их неплохо
> бы объединить в новом языке.

Только вот для полноценной реализации signal/slot требуется не только сборщик мусора (qt в понятие "полноценный" не входит), но и нормальная объектная модель (все obejct, с чего начинался Smalltalk, а ныне - Java/C# и множество других). Любой пук - виртуальность, а то и dynamic_cast.
Расплата за такой подход - скорость, а ею плюсы пожертвовать никак не могут (что тогда останется?).

> Интроспекция - да, на современном С++ ее можно делать извращенными макросами -
> но почему не сделать нормально?

Не надо макросов - это отдельная и противная тема. Есть boost::type_traits, в C++ 0x есть std::type_traits для статики/метапрограммирования. Для динамики требуется много памяти под код и данные, что непозволительно для плюсов.

> Автоматическая и ручная сборка мусора вполне себе сочетаются для разных видов объектов.
> Никого ведь не смущает, что сочетаются стевовые переменные и переменые на
> куче? Я бы оставил ручное управление памятью для специальных случаев (все-же
> С++ низкоуровневый язык) и ввел синтаксис для выделения памяти со сборкой
> мусора.

Все перечисленное уже есть в C++/CLI. Проблема в том, что от этого диалекта блюют даже поклонники C++. Мертвенький такой ребеночек у МС вышел.
Autorelease Pools оказался значительно более живой идеей, но он уже есть. И возможности плюсов там, как я понимаю, не нужны.

> Ну и лямбды с делегатами - даже в C# последнем не раскрыли
> всех возможностей этого средства.

Тема лямбд была полностью раскрыта в Lisp-е около полувека тому назад.

> А для совместимости с С++ вполне можно
> сделать специальный класс с ограниченным функционалом.

Писали бы сразу - костыль. Интересный, конечно, подход. Примерно как в C передвать классы через структуры. И дергать виртуальные фунции копаясь в vtbl. А как удалять такие объекты, я вот с ходу даже не придумаю.

> Если нужно больше - ну
> смени расширение файла и устрани несоответствия, как делали раньше при переходе
> с си на си++...

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

Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

53. "Утвержден финальный черновой вариант стандарта C++0X"  +/
Сообщение от yakovm on 28-Мрт-11, 19:10 
> В С++ много чего есть, но там все это через многоэтажные шаблоны,
> макросы и т.д. А хочется прямого естественного способа.

When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop.
(Alan Perlis)

Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

47. "Утвержден финальный черновой вариант стандарта C++0X"  +/
Сообщение от Stax (ok) on 28-Мрт-11, 17:15 
Интересно, почему thread-local storage не поддерживается в GCC совсем никак :o Даже MSVC держит, судя по таблице. Фича-то реально весьма полезная, да и в варианте C99 она давно работает в GCC.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

51. "Утвержден финальный черновой вариант стандарта C++0X"  +/
Сообщение от ананим on 28-Мрт-11, 18:43 
это случаем не там, где стоит ***?
где *** — Partial support
нет уж! partial support от мс - это головная боль того кто её будет юзать. нафиг.
согласно таблице гцц поддерживает гораздо больше фич. и без partial support. например Unicode String Literals в гцц есть. и это куда важнее.

а для tls/tsd и другие реализации есть - для примера см. класс QThreadStorage<T> в qt http://doc.qt.nokia.com/4.7/qthreadstorage.html

Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

60. "Утвержден финальный черновой вариант стандарта C++0X"  +/
Сообщение от Аноним (??) on 28-Мрт-11, 22:48 
> Интересно, почему thread-local storage не поддерживается в GCC совсем никак

http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Thread_002dLocal...

Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

52. "Утвержден финальный черновой вариант стандарта C++0X"  +/
Сообщение от sergey (??) on 28-Мрт-11, 19:07 
Attributes хоть будет по нормальному, после имён функций юзаться, Sutter продавил, а не угрёбищный синтаксис  с квадратными скобками.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n320...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

65. "Утвержден финальный черновой вариант стандарта C++0X"  +/
Сообщение от dq0s4y71 (??) on 29-Мрт-11, 12:02 
Можно подумать, без квадратных скобок синтаксис С++ сейчас недостаточно угрёбищен. Мне лично хватает угрёбищных угловых скобок в шаблонах и операторах ввода\вывода...
Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру