форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Утвержден финальный черновой вариант стандарта 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.me/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 (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 (ok) on 27-Мрт-11, 16:46
	> да не C++0x, а C1X - это стандарт который вместо С99. Не > С++, а С. Oops.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	31. "Утвержден финальный черновой вариант стандарта C++0X"	+/–
	Сообщение от VarLog (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 (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 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 (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 (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 (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 (ok) on 28-Мрт-11, 19:54
	> вопрос по управлению памятью (и в частности кучей), > включая мусоросборники, настолько широко освещён уже в С++ и настолько многообразен, > что все остальные языки просто выглядят ограниченными на этом фоне, если > не сказать больше. Остальные языки ограничены из-за того, что в C++ он подробно описан? Или потому что без пол-литры не разберешься? Логика в этом предложении есть, но вот что-то с ней не то. > если выбирать из многообразия выбора или его отсутствия - я выберу многообразие. Зачем? Про запас что ли? Может, перед тем как выбирать что-то, лучше определиться с критериями выбора: какую задачу и в каких условиях придется решать. > вопрос управления памятью даже не хочу обсуждать. С++ тут вне конкуренции. > если вы путаете мощь в управлении с простотой использования, то это другой > разговор. но как показывает практика, простота использования в большей степени достигается > глубиной знаний и квалификацией. Я ни где не говорил ни про мощь, ни про простоту использования. А C++ в если и в лидерах, то только по возможности прострелить себе сами знаете что. Про удобство работы для простых прикладных программистов, например, лучше не говорить. А уж фраза о том, что "простота использования достигается знаниями и квалификацией" - так это просто чушь. Если я, предположим, знаю про подводные камни std::string, то это не значит, что мне становится удобнее ее использовать. Если я знаю, что порядок инициализации статических переменных в разных единицах трансляции не определен, то от этого мне ни чуть не легче написать корректный синглтон, ну и т.д. > о цитате Гринспина - хм. ну пусть моему ядру это скажет - > 8Мб вместе со всеми необходимыми мне модулями. Ну вот опять логика потерялась. Вот если бы, предположим, ядро было бы размером в 800 метров, то это бы подтвердило бы цитату? А если 0.8, то опровергло бы безоговорочно? Теплое и мягкое.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	59. "почему не пойти другим путем?"	+/–
	Сообщение от dmi3s (ok) on 28-Мрт-11, 21:56
	> остальные языки - кастраты. Смелое утверждение. Мне в него поверить или у вас есть доказательства? > некоторые говорят что и одного яйца хватает. Я обычно глазунью из одного яйца делаю. Если вы из двух, то это вопрос вкуса. > а задачу, в которой нужны все методы (для разных подзадач) вы уже > не представляете? Мне казалось, что для обсуждения двумя или более людьми какой-либо задачи, ее неплохо бы сформулировать. А представлять себе каждый может много чего, но обсуждать будет нечего. > я слышу много таких умников изо дня в день, а вот программ У вас интересный досуг. > на компах всё больше как-то на С/С++. интересно, почему? Давайте не съезжать с темы. С++. Не количество яиц, не кастрация, и даже не C. Именно C++. На каких компах, на каких ОСях, какие программы, как считали статистику. Предметно. Идеально - со ссылками на отчеты cloc или похожей утилиты. > у-у-у! сори что отвлёк. больше не смею беспокоить. Если дальше про обсуждаемый язык, да еще и с какой-нибудь аргументацией - смейте на здоровье.
	Ответить | Правка | Наверх | Cообщить модератору

	61. "почему не пойти другим путем?"	+/–
	Сообщение от ананим on 28-Мрт-11, 23:37
	>> остальные языки - кастраты. >Смелое утверждение. Мне в него поверить или у вас есть доказательства? и ещё какие! в прошлом тысячелетии ещё подсчитали выгоду и рентабельность на подготовку кодера и необходимый минимум знаний. в частности что в языке должно быть не более 30 конструкций, что диспетчер памяти должен быть 1 на все случаи жизни и т.д, и т.п. так и появились ынтырпрайзное программирование и ынтырпрайзные языки. по принципу - пусть и безобразно, зато однообразно. остальное обсуждать интереса нет.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	66. "почему не пойти другим путем?"	+/–
	Сообщение от dmi3s (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 (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 | Индекс форумов | Темы | Пред. тема | След. тема