Здравствуйте, Roman Odaisky, Вы писали:

RO>На C++ пишут меньше прикладных программ, чем он того заслуживает, в первую очередь потому, что мало хороших прикладных библиотек. А вот хотелось бы выяснить: если бы на C++ были удобные библиотеки для всего-всего, то все перешли бы (обратно) на C++, или индусы в любом случае будут продолжать писать на Java, Python и т. п., потому что там сложнее обстрелять свои ноги? Для каких задач C++ останется неприменим даже с самыми лучшими библиотеками?

Проблемы с которыми сталкиваюсь постоянно:

Отсутсвие метаданных во времени компиляции

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

Убогие макросы

Баги компиляторов. Язык проще делать нужно, а не сложнее.

Недоступность стандартных фич во всех компиляторах.
Например: мистический эскпорт шаблоннов, throw specification.
И вообще всякие баги в стандарте

Нет нормальных макросов.
Да и вообще проблемы с макросами постоянные.
Вот кто-то решил в MS SDK, что ANY_SIZE хорошее название для макроса, а другой решил, что это хорошее название для константы, иди пойми в чем ошибка

Медленная скорость компиляции.

Несовместимость меджу компиляторами.
Каджый компилятор добавляет свои специфичиские фичи для удобства.
Было бы очень хорошо если бы каждый мог делать те же самые дополнительные функции, с синтаксисом уже можно разобраться как-нибудь.

А еще стандартная библиотека.
Она стандартная в стандарте, но как для использования никак не стандартная.
Каждый пользуется чем-то другим, а использование стандартной библиотеки чистая случайность.
Особенно если это код написанный достаточно давно, когда еще были баги в стандартных библиотеках.
Тем более пихать все больше и больше классов в стандарт к хорошему не приведет, только к багам

На пой взгляд это все исходит из того, что С++ позиционируется как язык для всех платформ в отличии от других языков.
Может пора прекратить это дело.
Все равно не на все embedded есть С++, да и процессоров с размером int в 36 бит мало встречается.

Здравствуйте, StevenIvanov, Вы писали:

SI>Ко всему прочему стоит заметить, что, видимо, написание аналогичного кода на С++ потребует большей подготовки и большей квалификации девелопера.

Потому, что С можно изучить за 2 дня, а С++ "несколько" дольше? Значит, для библиотечного кода — да, для пользовательсокго кода — наоборот. Как минимум, квалификация С кодера должна быть таковой, что он не имеет права забыть освободить любой ресурс. Тоже самое делает RAII...

SI>Элементарно простой пример: std::map (а так же, например, стандартнуя реализация AVL tree) нельзя (ну или скажем, неблагоразумно) использовать в коде ядра. Насчет Windows не уверен, но в Linux'е точно.

В чём проблема то, в памяти? Это обычный trade-off — стоит или нет, решает пользователь. Или у Линуса не получилось в 92м году? Тут есть один нюанс — подобный биржевым медведю и быку — мнение может быть не объективно.

SI>Вот, к примеру, память в ядре линукса экономится настолько сильно, что нужно помечать инициализирующую функцию и данные для инициализации в модуле ядра специальными ключами (__init/__initdata вроде), которые помещаются линкером в специальную секцию ELF файла, которая будет удалена после инициализации модуля ядром.

В виндосе так же, плюс еще разделение на (non)pageable секции. Это, кстати единственное непреодолимое ограничение для С++ — нельзя сделать для функций с C++ linkage. Можно конечно делать обходные манёвры с обертками на С... Но, как правило, забивают, если пишут на "С с классами". Вообще, непоняно, почему еще не доработан транслятор

SI>Нет, ну почему же нету, есть, только по стандарту ISO C89 (если не изменяет память). Нету <stdbool.h> и иже с ним, возможности объявлять переменные не только в начале функции и ряда других вещей.

Угу, чего только нет: этого нет, того нет

Здравствуйте, jazzer, Вы писали:

J>Логика простая, если вспомнить, о чем мы говорим. А именно: из-за отсутствия GC　использоваться С++ для быстрой разработки и прототипирования проблематично.
J>Не надо мой тезис превращать в "С++ отстой, так как нет GC".

1) Странно, вроде как получалось прототипы писать на M$ конструкции. Вроде проблем не возникало особых...
2) Нужность GC тоже обсуждаемая вещь, хотя это уже очень от методологии разработки зависит...

Здравствуйте, eao197, Вы писали:

E>Что до трудозатрат на разработку без GC в C++, то тут у меня такое наблюдение: очень редко сталкиваешься с ситуациями, когда GC явно снимает с тебя большую проблему. Но зато это ситуации, когда приходится потрудиться, чтобы в C++ обойтись без GC явным управлением памятью.

IMHO всё так, но в целом "трудно только в первый раз"...

Здравствуйте, jazzer, Вы писали:

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

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, jazzer, Вы писали:

J>>Логика простая, если вспомнить, о чем мы говорим. А именно: из-за отсутствия GC　использоваться С++ для быстрой разработки и прототипирования проблематично.
J>>Не надо мой тезис превращать в "С++ отстой, так как нет GC".

E>1) Странно, вроде как получалось прототипы писать на M$ конструкции. Вроде проблем не возникало особых...
Ну что я могу сказать... Только позавидовать!
У меня быстро не получается, все время натыкаешься на что-то, чему надо уделять повышенное внимание, причем это "что-то" в твои планы не входило.

E>2) Нужность GC тоже обсуждаемая вещь, хотя это уже очень от методологии разработки зависит...
Просто при прототипировании хочется как можно меньше думать о посторонних вещах и как можно меньше уделять им внимание.
Лучше всего, когда их нет вовсе.
И управление владением к этим посторонним вещам и относится, пока ты не начнешь прототипировать собственно их, да и то на только последних этапах.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, NikeByNike, Вы писали:

NBN>Здравствуйте, jazzer, Вы писали:

J>>Но на скриптах (питоне каком-нть) все равно быстрее, согласись, даже если ты на С++ забьешь на память.

NBN>Смотря в каких ситуациях. В последних прототипах которые я делал — важной частью были разные алгоритмы, на отладку которых я потратил большую часть времени. В тех случаях было глубоко без разницы на каком языке писать.
Так в том-то и дело, что хочется все доступное время посвятить алгоритмам, а не борьбе с различными граблями.
А в С++ у меня так не получается, хотя я, вроде, и не могу пожаловаться, что не знаю С++.
Постоянно на что-то напарываешься, и чаще всего, по моему опыту, это время жизни объекта.

Естественно, когда прототип закончен и понятно, как будет выглядеть финальный результат, схема владения продумывается окончательно и там уже умные указатели работают в полный рост.
Но на этапе проектирования и прототипирования это как шило в одном месте. Один enable_shared_from_this чего стоит.

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

You will always get what you always got
  If you always do  what you always did

Здравствуйте, jazzer, Вы писали:

J>>>кроме pi — он должен оставаться обычным голым указателем.
E>>А почему?
J>Потому что я сомневался именно в том, что GC может отследить голые указатели.
J>Особенно которые void* (сишных интерфейсов пока никто не отменял)

Как раз голые указатели консервативный GC (например Boehm GC) отслеживает без проблем http://www.digitalmars.com/d/2.0/garbage.html он не любит только фокусы с совпадениями. Прикрутить и использовать такой GC к C++ несложно, я в небольших проектах использовал.

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, jazzer, Вы писали:

J>>>>кроме pi — он должен оставаться обычным голым указателем.
E>>>А почему?
J>>Потому что я сомневался именно в том, что GC может отследить голые указатели.
J>>Особенно которые void* (сишных интерфейсов пока никто не отменял)

FR>Как раз голые указатели консервативный GC (например Boehm GC) отслеживает без проблем http://www.digitalmars.com/d/2.0/garbage.html он не любит только фокусы с совпадениями. Прикрутить и использовать такой GC к C++ несложно, я в небольших проектах использовал.

Он указатели внутрь управляемых объектов видит (как в моем примере)?
Я такого не нашел на странице, которую ты указал.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, jazzer, Вы писали:

J>Он указатели внутрь управляемых объектов видит (как в моем примере)?
J>Я такого не нашел на странице, которую ты указал.

Видит, он помнит все выделенные интервалы. Вот пример на D:

import std.stdio;
import std.gc;

struct S
{
  int i;
};

int* f()
{
  S *s = new S;
  //s = null;  
  return &s.i;
}

void main()
{
int* pi = f();
fullCollect();

*pi = 123;
writefln(*pi);
}

отрабатывает нормально, если раскомментировать //s = null; будет Access Violation

E>В языке D использовался консервативный GC, который считал указателями все, что было похоже на указатели. После чего пользователи стали жаловаться на неправильную работу программ, обрабатывающих большие массивы вещественных данных -- определенные значения float-ов и double-ов воспринимались таким GC как указатели и соответствующим образом обрабатывались. После чего в D были добавлены специальные функции, позволяющие пометить область памяти как гарантированно не содержащую указателей.

Так в Boehm GC они изначально были, D шный же на нем основан.

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

E>Согласись, что GC, в котором нужно явно указавать характер данных в определенных областях памяти, не сильно похож на GC из C#/Java.

Но это лучше чем ничего, а для C++ мелочью больше — меньше значения не имеет

Здравствуйте, eao197, Вы писали:

E>Проблема в том, что разработчик, выделяя буфер для шифрования или массив для перемножения матриц, даже не будет задумываться о том, что это может повлиять на GC.

Он должен знать как функционируют такие GC. Если не знает то не должен использовать.

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

Ничего у его программмы не снесет, просто будут утечки памяти.

Здравствуйте, jazzer, Вы писали:


E>>1) Странно, вроде как получалось прототипы писать на M$ конструкции. Вроде проблем не возникало особых...
J>Ну что я могу сказать... Только позавидовать!
J>У меня быстро не получается, все время натыкаешься на что-то, чему надо уделять повышенное внимание, причем это "что-то" в твои планы не входило.
Ну, видимо, ты слишком фиксируешься на эффективности прототипа

E>>2) Нужность GC тоже обсуждаемая вещь, хотя это уже очень от методологии разработки зависит...
J>Просто при прототипировании хочется как можно меньше думать о посторонних вещах и как можно меньше уделять им внимание.
J>Лучше всего, когда их нет вовсе.
J>И управление владением к этим посторонним вещам и относится, пока ты не начнешь прототипировать собственно их, да и то на только последних этапах.

Ну "нет вовсе" всё равно иллюзия. С GC пофиг на владение маленькими объектами, зато очень всё плохо при наличии больших (скажем по 100 метров). В коде о управлении их существованием вообще никто не думает, а память на таких масштабах всё-таки не резиновая...
Всё от задач и методологии зависит...

Здравствуйте, eao197, Вы писали:

E>Имхо, с таким количеством ограничений нельзя считать, что GC есть. Средства для облегчения управлением памятью -- да, но не GC. Иначе понятие GC сильно девальвируется.

Ограничений не так уж и много, если разбиратся в C++ даже при использовании вроде тривиального std::vector нужно знать его устройство и помнить об ограничениях. В общем GC тут мало чем выделяется, просто еще одна библиотека

E>Что до трудозатрат на разработку без GC в C++, то тут у меня такое наблюдение: очень редко сталкиваешься с ситуациями, когда GC явно снимает с тебя большую проблему. Но зато это ситуации, когда приходится потрудиться, чтобы в C++ обойтись без GC явным управлением памятью.

Здесь согласен.

Здравствуйте, jazzer, Вы писали:

J>Постоянно на что-то напарываешься, и чаще всего, по моему опыту, это время жизни объекта.
IMHO ты пишешь на C++ слишком сложно. Это конечно может быть хорошо в финальном коде, но совсем не нужно в прототипах. Попробуй как-то ограничить себя по сложности кода, скажем boost не использовать (кроме ptr), например...

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

Дык это просто культура программирования в этом направлении плохая. Ты не можешь почему-то управлять степениь проработанности своего кода с точки зрения подробностей реализации. Правда я согласен, что STL этому, как ни странно, не способствует, вынуждая программиста учитывать слимшком мелкие подробности реализации в очень абстрактном коде, ну да STL-way не догма на самом деле...
Если у тебя проблема с владением в С++, ну просто реализуй себе умный указатель простой какой-ниубдь интрузивный, и в прототипах всегда владей через него. И будет тебе таки счастье. Ну, на крайняк будут иногда циклические ссылки => будет течь в прототипе память. Ну и что?

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, jazzer, Вы писали:


E>>>1) Странно, вроде как получалось прототипы писать на M$ конструкции. Вроде проблем не возникало особых...
J>>Ну что я могу сказать... Только позавидовать!
J>>У меня быстро не получается, все время натыкаешься на что-то, чему надо уделять повышенное внимание, причем это "что-то" в твои планы не входило.
E>Ну, видимо, ты слишком фиксируешься на эффективности прототипа
ну, оценки сложности алгоритмов ведь надо на этапе прототипирования делать, не согласен?

E>>>2) Нужность GC тоже обсуждаемая вещь, хотя это уже очень от методологии разработки зависит...
J>>Просто при прототипировании хочется как можно меньше думать о посторонних вещах и как можно меньше уделять им внимание.
J>>Лучше всего, когда их нет вовсе.
J>>И управление владением к этим посторонним вещам и относится, пока ты не начнешь прототипировать собственно их, да и то на только последних этапах.

E>Ну "нет вовсе" всё равно иллюзия. С GC пофиг на владение маленькими объектами, зато очень всё плохо при наличии больших (скажем по 100 метров). В коде о управлении их существованием вообще никто не думает, а память на таких масштабах всё-таки не резиновая...
E>Всё от задач и методологии зависит...
Ну да, и я про то же (про задачи, в смысле)

А про "нет вовсе" — даже если ты используешь умные указатели, все равно тебе придется многократно писать shared_ptr<...> и прочая, везде ходить по указателям и т.д.
Неудобно, путается под ногами и мешает сконцентрироваться на деле.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, jazzer, Вы писали:

J>>Он указатели внутрь управляемых объектов видит (как в моем примере)?
J>>Я такого не нашел на странице, которую ты указал.

FR>Видит, он помнит все выделенные интервалы. Вот пример на D:

Наконец-то ответ по делу

А в С++ он такое тоже сможет?
Или для этого требуется внешняя поддержка (может, Д регистрирует там где-нть все созданные указатели).

You will always get what you always got
  If you always do  what you always did

Здравствуйте, jazzer, Вы писали:

J>А в С++ он такое тоже сможет?
J>Или для этого требуется внешняя поддержка (может, Д регистрирует там где-нть все созданные указатели).

Может, в D все усовершенствование ограничиваются ускорением работы за счет знаний о типах.

Здравствуйте, jazzer, Вы писали:

E>>Ну, видимо, ты слишком фиксируешься на эффективности прототипа
J>ну, оценки сложности алгоритмов ведь надо на этапе прототипирования делать, не согласен?
1) При чём тут вообще управление памятью, включая GC?
2) Зачем для оценки сложности алгоритмов вообще какой-то язык программирования?


J>А про "нет вовсе" — даже если ты используешь умные указатели, все равно тебе придется многократно писать shared_ptr<...> и прочая, везде ходить по указателям и т.д.
Ну всегда -> -- доступ к аттрибуту + указатель зовёшь Ptr<xxx> и счастье...
На всяк случай: Про то, что STL + boost враги краткости и простоты кода я не спорю

J>Неудобно, путается под ногами и мешает сконцентрироваться на деле.
Ну, IMHO, это всё равно, что сказать: "Ну не умею я быстро на С++ кодировать, а на Жабе умею"...
Мне кажется, что это персонально твои навыки и склонности всего лишь.

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, jazzer, Вы писали:

E>>>Ну, видимо, ты слишком фиксируешься на эффективности прототипа
J>>ну, оценки сложности алгоритмов ведь надо на этапе прототипирования делать, не согласен?
E>1) При чём тут вообще управление памятью, включая GC?
E>2) Зачем для оценки сложности алгоритмов вообще какой-то язык программирования?
Потому что бывает, что алгоритм вырисовывается на этапе прототипирования, а для прототипирования нужен какой-то язык программирования.
И структура данных тоже не сразу ясна, потому что вдруг оказывается, что то, что ты спрятал вот сюда, нужно еще и вот здесь, и приходится все переделывать, и вот это хотелось бы делать легко и быстро.

Но это не эффективность прототипа, конечно

J>>А про "нет вовсе" — даже если ты используешь умные указатели, все равно тебе придется многократно писать shared_ptr<...> и прочая, везде ходить по указателям и т.д.
E>Ну всегда -> -- доступ к аттрибуту + указатель зовёшь Ptr<xxx> и счастье...
ну да, и везде чтоб только они и летали, и не дай бог ссылку передать, и чтоб атрибуты сами тоже указателями были и, соответственно, конструкторы из гроздьев new состояли + конструкторы копирования и операторы присваивания везде придется руками организовывать, чтоб было глубокое копирование, потому что те, что по умолчанию генерятся, никак с смарт-поинтерами не дружат, и так далее...
Можно, конечно, не спорю, только на поддержку быстрой разработки это, имхо, слабо тянет.

E>На всяк случай: Про то, что STL + boost враги краткости и простоты кода я не спорю
При чем тут буст с стлем.
Все проблемы, которые я тут озвучивал, возникают до буста/стля.

А насчет работы с контейнерами — имхо, те же самые проблемы, если не хуже, будут с ручными циклами: попробуй тут заменить вектор на список, скажем.
буст в этом смысле как раз очень хорош, особенно BOOST_FOREACH — ему вообще на тип контейнера начихать, лишь бы был стл-совместимый.

J>>Неудобно, путается под ногами и мешает сконцентрироваться на деле.
E>Ну, IMHO, это всё равно, что сказать: "Ну не умею я быстро на С++ кодировать, а на Жабе умею"...

Да, можно и так сказать, только не о жабе (в ней я особого ускорения не видел, но я ее бросил юзать до того, как появились умные IDE), а о скриптовых языках.
Потому что в плюсах чтоб просто, например, распечатать нечто (в прототипах печатать много приходится, не все ж под дебаггером запускать), надо присесть двадцать раз, а в скрипты все это встроено сразу (помнишь такой чудо-синтаксис: "asd $qwe zxc $qweqweqwe"?)

E>Мне кажется, что это персонально твои навыки и склонности всего лишь.
Они, конечно, тоже есть, но нельзя и отрицать того, что определенные языки (типа перла, скажем) объективно специально заточены под то, чтоб определенные задачи решались минимальным количеством нажатий и мозговых усилий.
Чего о С++ не скажешь, сила С++ совсем в другом: возможность сваять что угодно любой сложности, а вот цена ваяния — дело десятое.

You will always get what you always got
  If you always do  what you always did