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

NBN>> Так это и есть плюсы Только с небольшим расширением.

O>Это расширение позволяет очень сильно упростить/облагородить код.
Вот этого если честно не очень заметно.

O>Плюс еще богатая родная библиотека QT.

Вот это — да

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

NBN> NBN>> Так это и есть плюсы Только с небольшим расширением.

NBN> O>Это расширение позволяет очень сильно упростить/облагородить код.

NBN> Вот этого если честно не очень заметно.

А с чем сравнивать? Могу предложить плюсы с MFC против плюсов с QT Вариант "С++ и чистый WinAPI" не рассматриваю — написался на нем до изжоги.

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

NBN>> O>Это расширение позволяет очень сильно упростить/облагородить код.

NBN>> Вот этого если честно не очень заметно.

O> А с чем сравнивать? Могу предложить плюсы с MFC против плюсов с QT Вариант "С++ и чистый WinAPI" не рассматриваю — написался на нем до изжоги.

Так надо сравнивать с хорошей С++ библиотекой. MFC — однозначно очень плохая система, WinAPI — никак не С++

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


NBN> O> А с чем сравнивать? Могу предложить плюсы с MFC против плюсов с QT Вариант "С++ и чистый WinAPI" не рассматриваю — написался на нем до изжоги.

NBN> Так надо сравнивать с хорошей С++ библиотекой. MFC — однозначно очень плохая система

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

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

Ш>На сегодняшний день самым большим недостатком С++ является отсутствие хорошей публичной библиотеки классов для решения типичных общих задач.

boost

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

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

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

Это конракт. В Java и .NET тоже есть условие, (О, ужас!) что эквивалентные объекты имеют один и тот же хэш. А-а-а! Как можно писать на них!?

Просто в современных языках это отдано на откуп фреймворку (Например маршаллинг managed/unmanaged в .NET), а в самом языке нет механизмов для нарушения этих правил. C++ более низкоуровневый. Там легче "выстрелить себе в ногу", но и возможности программиста выше.

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

T>Это конракт. В Java и .NET тоже есть условие, (О, ужас!) что эквивалентные объекты имеют один и тот же хэш. А-а-а! Как можно писать на них!?

Не надо сравнивать жопу с пальцем. Никакой это не контракт. Стандарт вообще никак не гарантирует, что такой код у тебя будет работать, даже если ты соблюдешь все мыслимые условия. То, на что полагаешься — это особенности реализации, это undefined behavior.

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

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

T>>Это конракт. В Java и .NET тоже есть условие, (О, ужас!) что эквивалентные объекты имеют один и тот же хэш. А-а-а! Как можно писать на них!?

K>Не надо сравнивать жопу с пальцем. Никакой это не контракт.
Ещё какой: http://download.oracle.com/javase/6/docs/api/java/lang/Object.html#hashCode%28%29

The general contract of hashCode is:
...
If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.

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

Это вообще к чему было сказано? Про equals? Или про бинарник, собранный разными способами? И какой именно код имелся ввиду? Я — полагаюсь на стандарты. И согласно стандарту два разных модуля могут работать вместе, если нет отклонений от стандарта. Именно поэтому можно exe-шник, собранный в Visual Studio, может прекрасно работать с DLL, собранной в Delphi. И даже память течь не будет.

А про особенности реализации, так это про всё что угодно сказать можно.

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


NBN>> Так надо сравнивать с хорошей С++ библиотекой. MFC — однозначно очень плохая система

O>Ну так я про то и спрашиваю. С чем сравнить? Сравниваем не библиотеки, а код на С++ с использованием той или иной библиотеки. Неужто найдется что-то лучшее QT?

Ну из кусочков можно собрать, например boost + wxWidgets

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

T>Это вообще к чему было сказано?

Подзаряди мозги.

T>Я — полагаюсь на стандарты. И согласно стандарту два разных модуля могут работать вместе

Покажи мне место в стандарте, где это гарантируется.

Здравствуйте, Klatu, Вы писали:
1. сформулируй цель создания языка. Возможно — несколько. Никлаус Вирт при создании Паскаля формулировал, Страуструп при создании С++ формулировал... От цели — сильно большая разница получается.
2. Очерти область применения. От области применения — сильно разные языки получаются.
3. Сформулируй основной принцип языка. Пример С++: все, что не запрещено явно — то разрешено. Пример Оберон: все, что не разрешено явно — запрещено. Разница — колоссальная!
Например, в Яве наследование запрещается специальным ключевым словом, а в Компонентном паскале — разрешается специальным ключевым словом.
4. Четко раздели свойства языка и библиотеку. Свойства языка — это гранит, который потом сложно поправить. А библиотеку можно расширять, изменять и переписывать. В этом смысле язык должен быть минимален, а библиотека обширна.

ИМХО, пока судя по твоим постам получается, что ты собираешься создавать очередного монстра...

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

T>Это конракт. В Java и .NET тоже есть условие, (О, ужас!) что эквивалентные объекты имеют один и тот же хэш.

Нет такого условия в .NET и Java. Такое условие есть только у конкретной реализации словаря, да и то внешний компаратор подсунуть элементарно.

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

K>Здравствуйте, Шахтер, Вы писали:

Ш>>Вообще-то Qt -- это С++. При использовании внешних средств, не встроенных в язык, обычно возникают неприятные вещи. Начиная с проблемами с раскраской кода.

K>Пропущено "не"?

Ничего не пропущено.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

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


O>Взгляните:
O>

O>struct Socket
O>    {
O>    private:
O>        bool m_bInitialized;
O>        char m_Impl[SIZEOF_SOCKET_IMPL_CLASS];
O>    };
O>

O>Вроде бы ничего подозрительного — при создании объекта Socket он инициализирует массив m_Impl объектом
O>Socket_Impl (реализация) с помощью placement new. Оставим пока в стороне вопросы обеспечения
O>корректного значения SIZEOF_SOCKET_IMPL_CLASS. Ничего не замечаете ? Как будто все в порядке.

Замечаю. Например, у вас будет reinterpret_cast, а это как бы намекает на возможные проблемы.

Если вы нарушаете систему типов, то вы берете на себя ответственность за последствия. С++ позволяет вам это сделать, но подразумевается что у вас есть основания так делать и вы осознаете результаты.

Что мешает сделать так:

struct Socket
{
private:
  struct Impl;
  scoped_ptr<Impl> impl;
};

И только если вы сделали так, увидели что все тормозит, запустили профайлер, поняли что дело именно в конструировании объектов Socket, то можно заняться экспериментами со статическим массивом (предварительно погуглив насчет размещения объектов в памяти, struct max_aligned и т.д.)

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

LVV>4. Четко раздели свойства языка и библиотеку. Свойства языка — это гранит, который потом сложно поправить.

Не согласен.

LVV>ИМХО, пока судя по твоим постам получается, что ты собираешься создавать очередного монстра...

Ну и пусть монстр. Главное — чтобы зубастый

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


Ш>Это не особенность компиляции, а языка. Память под объект должна быть выровнена. Вобщем то это самоочевидно. Особенно для людей, знающих, что кроме x86 есть и другие процессоры.

Похоже это не было самоочевидно для авторов языка и компилятора.

LVV>>4. Четко раздели свойства языка и библиотеку. Свойства языка — это гранит, который потом сложно поправить.

K>Не согласен.

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

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

LVV>>ИМХО, пока судя по твоим постам получается, что ты собираешься создавать очередного монстра...

K>Ну и пусть монстр. Главное — чтобы зубастый

То есть, ты тоже не знаешь, где взять PL/I.

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

M>Как только больше одного человека заложится на свойство языка, хрен ты его потом безгеморрно поправишь.

Это пока прототип. Кто на него будет закладываться?

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

Т>То есть, ты тоже не знаешь, где взять PL/I.

Знаю. Кстати, не сказал бы, что этот язык так уж плох. Просто был слишком сложен для своего времени.