The OpenNET Project / Index page

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



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

Оглавление

Утвержден финальный черновой вариант стандарта C++0X, opennews (??), 27-Мрт-11, (0) [смотреть все]

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


41. "почему не пойти другим путем?"  +/
Сообщение от dmi3semail (ok), 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>

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

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

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

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

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

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

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

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

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

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

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

#include <best/regards>


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

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

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

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

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

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

49. "почему не пойти другим путем?"  +/
Сообщение от dmi3semail (ok), 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"
— Филип Гринспен.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да уж.

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

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

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

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




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

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