Здравствуйте, <Аноним>, Вы писали:

А>Везде==Windows&UNIX?
А>А знаете почему в С++ нету стандартных средств для работы со структурой каталогов? Потому что не везде есть каталоги.
А>Знаете почему в С++ существуют триграфы? Потому что не везде есть { и }
А>Знаете почему в RFC на сетевые протоколы байты называются странным словом октеты? А потому что не везде байт — это 8 бит.
А>А вы тут про какието dll....
А ты знаешь куда идут доказательства по аналогии?

В любом случае никто не мешает линьковать статически.

WH>>По тому dll-hell и есть что не в курсе.
А>Потрудитесь настроить генерацию манифестов для своих проектов в студии.
Как мне это поможет в 4х версиях линуха под которые я пишу?

А>>Везде==Windows&UNIX?
А>>А знаете почему в С++ нету стандартных средств для работы со структурой каталогов? Потому что не везде есть каталоги.
А>>Знаете почему в С++ существуют триграфы? Потому что не везде есть { и }
А>>Знаете почему в RFC на сетевые протоколы байты называются странным словом октеты? А потому что не везде байт — это 8 бит.
А>>А вы тут про какието dll....
WH>А ты знаешь куда идут доказательства по аналогии?
Это не аналогии, а тонкие намеки на толстые обстоятельства

WH>В любом случае никто не мешает линьковать статически.
WH>>>По тому dll-hell и есть что не в курсе.
А>>Потрудитесь настроить генерацию манифестов для своих проектов в студии.
WH>Как мне это поможет в 4х версиях линуха под которые я пишу?
Никак Сделайте в makefile'е автоматическое дополнение имени либы ее версией и не парьтесь, если вам это критично Манифесты то по сути эо тоже самое, но нифига не UNIX-way

Здравствуйте, <Аноним>, Вы писали:

А>Это не аналогии, а тонкие намеки на толстые обстоятельства
Единственное толстое обстоятельство это раздолбайство авторов С.

А>Никак Сделайте в makefile'е автоматическое дополнение имени либы ее версией и не парьтесь, если вам это критично Манифесты то по сути эо тоже самое, но нифига не UNIX-way
Как избавлятся от so-hell я и сам знаю.
Тем не менее... еслиб изначально это все продумали таких слов в лексиконе программистов вобще бы небыло.

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

R>Что Вам мешает в С++?
Отсутствие приватных методов и членнов которые бы не были видны в .hpp фаилах. Например.

Foo.hpp

class Foo
{
public:
  void print();
};

Foo.cpp

private int Foo::m_params;

private void Foo::print_impl( int _p )
{
 ...
}

void Foo::print()
{
  this->print_impl( this->m_params );
}

R>

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

[]

про модель компиляции, и соответственно, скорость, уже сказали?

Здравствуйте, remark.

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

Здравствуйте, <Аноним>, Вы писали:

А>юзать SxS с ее манифестами
Это блин бомба замедленного действия, предназначенная для ускоренного пожирания места на системном диске!

А>>Это не аналогии, а тонкие намеки на толстые обстоятельства
WH>Единственное толстое обстоятельство это раздолбайство авторов С.
Язык С изначально вообще никак не привязан к какому либо формату получившихся исполняемых файлов. Это может быть и виндовая длл и образ flash ROM безо всякой файловой системы.
Забота о бинарных файлах и их форматах — это уж дело абстракций более высокого уровня — target платформы и компилятора под нее. То что существующие реализации компонентов под юниксы говенные — язык С совершенно не колышет, точно так же как проблемы индейцев шерифа.
Незачем пихать совершенно все сущности в один уровень абстракции. Есть синтаксис языка, потом — стандартные библиотеки, потом — компиляторы и платформы. Это три разных, совершенно независимых уровня абстракции. Первые две стандартизированы и называются стандарт С++. Другие две — совершенно никак не стандартизированы. Хотите — сделайте свою систему конторя совместимости версий бинарных файлов, — сделайте приблуду к GCC, может быть вам даже спасибо скажут, если повезет конечно. Микрософт сделал свою в пределах своей платформы, линуксоиды как-то этим не озаботились, и в принципе правы — проблема то решается гораздо проще (см мессаги выше).

интерфейсы — наше все

Объяснюсь немного проще — С++ предназначен для того чтобы компилировать исходный текст программы (определенного вида) в исполняемый код (любой). Стандарт С++ накладывает ряд ограничений именно на исходный текст программы — синтаксис и набор стандартных функций и классов. Но на "выхлоп" компилятора — объектники, библиотеки, исполняемые файлы, просто plain код, да хоть код на др ЯП — стандарт никаких правил не накладывает потому, что это означает что target платформа должна была бы быть совместима с С++, а не наоборот. Из этого прямо следует отсутствие каких либо средств борьбы с dll-hell, тк сам язык С++ не стандартизует формат библиотек (статических или динамических) и правил их использования, тк это бинарные файлы, которые могут быть ЛЮБЫМИ.

Здравствуйте, Аноним, Вы писали:

А>Объяснюсь немного проще — С++ предназначен для того чтобы компилировать исходный текст программы (определенного вида) в исполняемый код (любой). Стандарт С++ накладывает ряд ограничений именно на исходный текст программы — синтаксис и набор стандартных функций и классов. Но на "выхлоп" компилятора — объектники, библиотеки, исполняемые файлы, просто plain код, да хоть код на др ЯП — стандарт никаких правил не накладывает потому, что это означает что target платформа должна была бы быть совместима с С++, а не наоборот. Из этого прямо следует отсутствие каких либо средств борьбы с dll-hell, тк сам язык С++ не стандартизует формат библиотек (статических или динамических) и правил их использования, тк это бинарные файлы, которые могут быть ЛЮБЫМИ.

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

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

int x
#include "file"

знаете что это?
нет.
варианты
int x;
int x[];
int x(int fx, in fy);
и вообще черт знает что.

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

M>с и с++ этого не поддерживают.
M>хидер вообще не стандартизован, насколько я понимаю, и есть лишь общепринятое соглашение. можете не поддерживать! сколько раз я видел людей, что просто не умеют писать хидеры, причем спецы между прочим.
То что вы называете "хидер" это просто исходный файл, который вставляется в единицу трансляции. С++ выше понятий хидер и тп. Не думайте о тех файлах которые пишутся в include как о неких библиотеках. Думайте как просто о "вставленных" в текст программы кусках кода.
Да, это большой недостаток любых универсальных систем — к реальной жизни и реальных людей их надо местами притягивать за уши. С++ универсален, как набор шарниров и палочек из которых можно сделать что угодно. Но делать что угодно из шарниров и палочек накладно, потому появились некие дополнительные соглашения, которые никак не оговариваются стандартом:
— способ использования хедеров, который не нравится вам — их можно использовать как угодно, ваше дело лишь использовать как вам удобно.
— способ построение модульной архмитектуры, используя прекомпилированные бинарные библиотеки — объектники, статические или динамические библиотеки — вообще никак стандартом не покрывается. Опять же — стройте сами свою архитектуру и пользуйте 3rd party framework'и модульной архитектуры, к коим относится и венда с ее дллками и манифестами, и юниксовые so etc
— просто стиль написания кода — о чем я писал уже тут — http://www.rsdn.ru/forum/message/2995741.1.aspx

Автор:
Дата: 21.06.08

Просто стандарт языка описывает сам язык. Синтаксис и набор стандартных сущностей. Так же как правила русского языка — описывают грамматику и фонетику, а писать на нем бульварные романы, падонкавские посты или стихи — дело ваше. В универсальности С++ нет места ничему, что можно реализовать как доп библиотеку, доп набор правил для конкретной платформы/платформ, или просто как набор человеческих правил в файле, хранящемся в дереве CVS'а под названием coding_style.txt . В этом же и его беда

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

ST>Здравствуйте, Alexander G, Вы писали:

AG>>Я начинал с Delphi, поэтому что мешает:

AG>>1. Отуствие finally. Да, я в курсе про RAII, смарт-поинтеры в т.ч. с кастомными деаллокаторами и скоп гарды. Но меня не устраивает навязывание ООП здесь. Выходит, что С++ не поддершивает стиль старого дорбого С (хотя вроде как пытается поддерживать и С и ООП и даже ФП). Сюда же то, что деструктор не вызовется для недоделаных объектов (в Delphi — вызовется), что требует не только помещать ресурсы в классы, но и помещать кажды ресурс в свой класс. If I hear the phrase``everything is an object'' once more, I think I will scream.

ST>Одна из причин "невызова" деструктора в том, что в плюсах объект никак не инициализирован на момент вызова конструктора.
ST>В Delphi производится инициализация по умолчанию нулями до вызова конструктора, потому в деструкторе вполне можно писать x.Free для всех динамически аллоцированных членов класса.
ST>В плюсах же, если даже деструктор и вызывался бы, все равно было бы не понятно что там делать.
ST>Ибо часть объектов инициализирована, а часть содержит мусор. Но кто есть кто — не понять.
ST>Потому даются лишь гарантии для списка инициализации, а в теле конструктора контроль можно производить вручную.

AG>>2. Наследие С. Выражается в недостаточной типизации. Пример: '\0' NULL и 0 — совместимы, причём последние 2 вообще одно и то же. В паскале nil 0 и #0 компилятор не даст попутать if (p) p = 0 /* я пропустил * перед p но компилятор не проглотил, т.к. nil и 0 одно и то же */. Также в С путают указатель с массивом. И выражение с операцией. Возможностью написать короче пользоваться не приходится, т.к. требуется написать понятнее, но ошибки типа if (a = b) сделать всё равно можно.

ST>+

AG>>3. Я не могу клепать формы на WTL так быстро, как это получалось в Delphi

ST>+

чета вы гоните.
не явлется обьект с забитыми в него нулями никаким — "дефолтно-инициализированным".
поскольку на деструктор не накладывается никаких фунциональных ограничений, он может, например, по некоему нулю в поле обьекта делать нечто необычное. в реальности же конструктор должен инициализировать поля таким образом, чтобы даже если будет исключение, обьект был корректным для деструктора.
корректная реализация finally может быть сделана, если оно вообще нужно, но только не через нули.
инициализируйте короче свои мусорные поля ручками, потом вызывайте то, что может генерить исключение.

finnaly реализуется просто как первоначальный jump на кусок кода обьявленный как finally, а потом уж поиск по стеку подходящего по типу обработчика исключания. finally аналогичен тут дополнительно вставленному в цепочку обработчиков исключения, еще одному обработчику, что выполняется при ЛЮБОМ исключении, и потом ищется уже обработчик по типу выброшенного.
и неча тут дров наламывать.
finally можно в любом дельфи нарисовать некорректным.

Здравствуйте, Аноним, Вы писали:

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

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

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

>> Эта беда в первую очередь от хреновой модульности, когда слишком много
>> всего приходится класть в хедеры. Те же шаблоны, например.
>> Опять-таки, это связано с единым форматом объектных файлов, в которых
>> всё должно быть уже скомпилировано. Без этого не получится дешёвая
>> интеграция с другими языками.

S>Это надуманная причина — никто не запрещает ввести еще один формат
S>объектников, подразумевающий наличие центрального репозитария.
S>Поддерживает же в конце концов VC одновременно и COFF и OMF.

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

А хреновая модульность, кстати, вылезает ещё и в том, что хедеры можно писать как попало и включать как попало, получая всю мощь и всю головную боль условной компиляции.
И это тоже сдерживает. Даже если компилятор каждому хедеру сопоставил pch в надежде, что линкер потом сам соберёт — то эта надежда может быть жестоко разбита: один и тот же хедер можно дважды включить с разным смыслом. А тащить в pch все варианты (со всеми возможными подстановками и ветвлениями) — это комбинаторный взрыв, как минимум.

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

M>чета вы гоните.

чета кто-та по ночам не то-та чета пишет

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

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

M>корректная реализация finally может быть сделана, если оно вообще нужно, но только не через нули.
M>инициализируйте короче свои мусорные поля ручками, потом вызывайте то, что может генерить исключение.
M>finnaly реализуется просто как первоначальный jump на кусок кода обьявленный как finally, а потом уж поиск по стеку подходящего по типу обработчика исключания. finally аналогичен тут дополнительно вставленному в цепочку обработчиков исключения, еще одному обработчику, что выполняется при ЛЮБОМ исключении, и потом ищется уже обработчик по типу выброшенного.

Блок finally выполняется в любом случае, даже если исключения не было.
Так что если не использовать scope guard-ы, отсутствие finally ведет к дублированию кода.

int *i = new int;
try
{
  ...
}
catch(...)
{
  delete i;
  throw;
}
delete i;

против

int *i = new int;
try
{
  ...
}
finally
{
  delete i;
}

Вот и все, видимо, о чем хотел сказать автор.

M>и неча тут дров наламывать.
M>finally можно в любом дельфи нарисовать некорректным.

Можно, конечно.

Для производительности. Чтобы можно было всё инлайнить. Чтобы можно было реализовать статический полиморфизм. За это приходится платить увеличением времени компиляции. Неужели не понятно?

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

Кодт пишет:
>> > Эта беда в первую очередь от хреновой модульности, когда слишком много
>> > всего приходится класть в хедеры. Те же шаблоны, например.
>> > Опять-таки, это связано с единым форматом объектных файлов, в которых
>> > всё должно быть уже скомпилировано. Без этого не получится дешёвая
>> > интеграция с другими языками.
>
> S>Это надуманная причина — никто не запрещает ввести еще один формат
> S>объектников, подразумевающий наличие центрального репозитария.
> S>Поддерживает же в конце концов VC одновременно и COFF и OMF.
>
> Ближе всего к решению проблемы прекомпилированные заголовки. Но, увы,
> они находятся не в том слое: между разбором и трансляцией отдельных
> файлов, а не между компилятором и линкером (который должен был бы
> осуществлять окончательную компиляцию, а не просто линковку).

Вот именно что pch — это вообще не о том.

> А хреновая модульность, кстати, вылезает ещё и в том, что хедеры можно
> писать как попало и включать как попало, получая всю мощь и всю головную
> боль условной компиляции.
> И это тоже сдерживает. Даже если компилятор каждому хедеру сопоставил
> pch в надежде, что линкер потом сам соберёт — то эта надежда может быть
> жестоко разбита: один и тот же хедер можно дважды включить с разным
> смыслом. А тащить в pch все варианты (со всеми возможными подстановками
> и ветвлениями) — это комбинаторный взрыв, как минимум.

Поэтому надо работать не (или не только) с хедерами/pch, а с уже
откомпилированными функциями. Только пихать их, грубо говоря, в один на
программу большой объектник. Заодно получаем в качестве бонуса
диагностику нарушений ODR.
Неплохо бы также иметь какой-нибудь p-code для промежуточного
представления шаблонов — из этого дополнительный выигрыш во времени
трансляции бы получился, и почти автоматом — export templates.

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

Здравствуйте, <Аноним>, Вы писали:

А>Язык С изначально вообще никак не привязан к какому либо формату получившихся исполняемых файлов. Это может быть и виндовая длл и образ flash ROM безо всякой файловой системы.
А>Забота о бинарных файлах и их форматах — это уж дело абстракций более высокого уровня — target платформы и компилятора под нее. То что существующие реализации компонентов под юниксы говенные — язык С совершенно не колышет, точно так же как проблемы индейцев шерифа.
Пойми одну простую вещь: Наличие или отсутствие модульности в языке никак не зависит от формата таргет платформы. Те вобще никак.