Вы сами же и ответили на вопрос, почему это не надо вносить в стандартную библиотеку C++ - потому что это уже хорошо реализовано сторонними библиотеками.

Все просто. Это обычный баланс (и уже поэтому, здесь можно дискутировать бесконечно):

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

Я не против того, что уже внесено в C++0x, например, потоки (особенно в части требований к компиляторам). Но, как в известной сказке, если в дом полезут все (потащат все, что кому-то может и действительно нужно, но не обязтельно нужно всем и всегда), то дом треснет и развалится (на анклавы-платформы).


Неужели кто-то всерьез полагает, что серьезное поизводство ПО на базе C++ возможно без какого-то дополнительного набора библиотек (или даже framework-ов), пусть даже и довольно стабильно переходящего из проекта в проект? Для меня это, как минимум, Boost C++ Libraries.

Наверное, тема "На каких платформах (аппаратные платформы, ОС) Вы бы хотели видеть (Вам нужны) полноценные/современные компиляторы C++, полностью (без багов!) и эффективно поддерживающие хотя бы стандарт C++ 2003 года?" была бы менее противоречивой (для меня). Это так, отступление от темы нашего вопроса, отчасти связанное с ним.

Это сообщение отредактировал(а) mabrarov - 14.4.2011, 12:26

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


если этот фреймворк будет частью стандарта - то да, естественно можно. На .NET люди же как-то пишут.


это далеко не все, я к примеру не предлагал включать в стандарт библиотеку для работы с протоколом x.501, а вот минимальные средства для разработки этого протокола все таки должны быть включены. Я не вижу чем сокеты хуже потоков, мьютексов или тех же файлов.

Например в одной довольно серьезной компании, в которой я работал, использование какой либо внешней библиотеки было вообще запрещено. В моей теперешней компании на многих проектах буст также запрещен. В последний раз смена версии буста остановила мою работу на сутки (и не только мою), а смена версии Qt уже продолжается на протяжении месяцев. Удовольствия от всего этого как Вы понимаете мало. Мне гораздо приятнее знать, что кто-то долго сидел, думал и заботился о работе 2-х гигабайтов кода, написанного 7 лет назад и при смене версии библиотеки/компилятора нам не придется сидеть и искать где и в какой функции добавили новый аргумент.

Это сообщение отредактировал(а) azesmcar - 14.4.2011, 12:30

.NET Framework. Ну да, именно как-то. Т.е. вполне нормально, пока дело не доходит до распространения или, упаси боже, переноса на др. платформу. Впрочем, тут проблемы есть у всех. Просто кто-то может (имеет время, силы и "скиллы") потратить на их решение больше (тех же ресурсов), а кто-то меньше. Вот только не надо того "сахара" и обилия "из коробки", что есть в .NET. Кому нужно, как в .NET, те на нем и пишут (не в упрек Вам, data-race.com я видел - хороший ресурс).

Как я и писал - баланс противоречив и дискутировать дальше не вижу смысла   

Так в том то и дело, что очень многие так и поступают и именно из за наличия сахара из коробки. Если мне надо написать программу под windows (без планов переноса под *nix) то я долго думать надо выбором платформы и языка не стану, хотя C++ как язык мне нравиться.


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

Бывает. Все, наверное, читали "JSF C++ Coding standards" - там и STL (фактически) под запретом. Требования разные бывают, а подобрать правильный инструмент иногда становится настоящим искусством (которым, к сожалению, могут заниматься некомпетентые личности).


Serialization? (по этому поводу и без меня ответов хватает)
Все пользователи Boost (если читали то место в документации Boost) знают, что Boost не дает никаких гарантий касаемо ABI и даже совместимости на уровне исходных кодов (за исключением разве что устоявшихся библиотек) - это в общем случае, если обратное не указано явно.


Ну Qt-то как раз даже в плане ABI много чего гарантирует при определенных условиях - надо это учитывать при разработке.

Хотите 100%-ной ABI совместимости - пишите C-like внешние интерфейсы или используйте COM (лучше, пожалуй, XPCOM). Зачем "плакаться", если "всех предупреждали".

Когда, порой, слышишь "мне в C++ не хватает того-то и того-то как там-то и там-то", то предложение использовать это самое "там-то и там-то" (Java, C#, Python) оказывается очень даже уместным и вполне принимается вопрошающим. Потому что не зря существуют другие языки программирования и иногда стоит объективно оценивать нежелание их использовать, замечая в нем обычную, человеческую инертность.

Добавлено через 10 минут и 51 секунду

Обогнали   
Я, кстати, свои деньги за Java получаю уже года 2, "хотя C++ как язык мне нравиться" - ну ооочень.

Это сообщение отредактировал(а) mabrarov - 14.4.2011, 13:04

Ну и на кой фиг так извращаться?


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


т.е. по Вашему нам надо ничего не хотеть, ни к чему не стремиться и сидеть довольствоваться тем, что у нас есть?

Правда? Поделись, пожалуйста, ссылочкой на новость!
Нашёл что примут примерно в следующем году, но текущий драфт последний. Значительных изменений не будет. Ура, товарищи!

Это сообщение отредактировал(а) Леопольд - 19.4.2011, 13:45

http://forum.try-catch.ru/index.php?topic=426.0

Это сообщение отредактировал(а) borisbn - 19.4.2011, 13:49

Тоже считаю, что возможность создания указателя на метод класса с привязкой к конкретному объекту была бы очень полезна. Есть подозрение, что std::function (копия boost::function, если не ошибаюсь) имеет значительный оверхэд (new/delete) против простого указателя (пусть даже двойного размера). Тем более, что в этом случае решалась бы проблема с виртуальными функциями и прочей фигней - на машинном уровне это выглядело бы как два указателя, один на объект, а второй на функцию (причем, так как на момент создания указателя объект известен, можно сразу подставить нужный вариант виртуального метода).

В принципе, сокеты можно включить в стандарт на тех же правах, что и потоки. Ведь бывают системы, где нет потоков, бывают, где нет сети... Но тупо включать asio я не считаю разумным. Для начала следует сделать серьезный его рефакторинг. В частности, переименовать io_service в task_manager (ну или что-то в этом духе).

Это сообщение отредактировал(а) bsa - 19.4.2011, 22:58

имеет в случае хранения функционального объекта.. а без оверхеда тут никак, ибо размер объекта не известен.. А при хранении функций и методов никакого оверхеда нет..

Добавлено через 2 минуты и 20 секунд

о какой именно проблеме идет речь ? чем она в случае s std::function не решена ?

Добавлено через 8 минут и 54 секунды

а стоит ли эта лишняя сущность, того чтоб отказываться от более мощного и удобного инструмента bind ?

Точно нет? Даже при связывании метода с объектом? Просто синтаксис связывания метода с объектом не особо удобен... Имхо, значительно красивее было бы что-то вроде:

результат bind`a - функциональный объект .. его естественно приходится хранить в куче.. 

  
какой же он task_manager ? откуда такие выводы?


например?

ну до ++0x вообще монструозно .* и ->* кого угодно введут в ступор

все логично.
есть адрес объекта, и есть адрес метода. чтоб произвести вызов метода, нужно знать И адрес объекта.
не понимаю, что тут не логично..

Добавлено @ 21:46

а в с++0х разве что-то изменилось?

Это сообщение отредактировал(а) boostcoder - 20.4.2011, 21:50