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

K>Это как понимать? Вся спецификация языка — один сплошной недостаток?

Именно

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

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

K>>ну или киньте в меня готовым списком, если такой уже есть

Л>В C авторы, видимо, основное внимание уделили тому, чтобы писать можно было как можно короче, кучу операций в одну строчку, операторы в 1-2 символа. Классический пример — копирование строки с помощью while(*p2++ = *p1++). Ну это ладно, все знают (хотя далеко не все понимают). Другие закрученные конструкции писать считается дурным тоном. А я считаю, что язык не должен содержать таких возможностей, использование которых порицаемо.

Л>В С++ синтаксис шаблонов просто ужасен. Понятно, что это следствие их добавления к уже готовому языку. Но это очень сдерживает их применение.

К несчастью только далеко не все, кто знает что строку можно скопировать через while(*p2++ = *p1++), знают почему так делать не нужно

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

Самые серъезные недостатки C и C++ ? Они лежат с обратной стороны их главных достоинств.
Эти языки настолько низкоуровневы и близки к "железу", что делают возможным написание
эффективного кода, который (с учетом достижений современных компиляторов) иногда обгоняет
написанные на ассемблере аналоги. Но именно из-за этого фактора очень часто невозможно
"просто" заниматься бизнес-логикой — приходится заботиться об атомарности доступа, писать
volatile и полагаться только на интегральные типы. Код при этом несколько теряет в
привлекательности, а хорошие библиотечные инструменты вообще сплошь состоят из макросов,
встроенных функций, ассертов и asm-вставок, не редкость также всякие language extensions,
рассчитанные на специфику платформы. Парадокс — чтобы писать эффективные программы на
C/C++, нужно отлично разбираться в нюансах работы процессоров, кэша, памяти, уметь
представлять генерируемый машинный код и затраты на его выполнение.

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

В чисто практической повседневной работе возникает масса небольших, но в совокупности
очень обременяющих вопросов — как экспортировать класс из dll-ки, не прибегая к разделению
стандартного аллокатора (чтобы не зависеть от библиотек рантайма, которые не у всех установлены),
как интегрировать в старый проект новый строковой класс с несовместимыми интерфейсами,
как гарантировать, что исключение модуля, компилированного GCC, будет корректно перехвачено в
коде, написанном на Intel C++, как реализовать паттерн Bridge и при этом не "спалиться" на
некорректном выравнивании данных или особенностях оптимизации. И еще много других.

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

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

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

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

WH>Ну так изложи эти идеи.
WH>Пока не ясно даже что за язык ты хочешь получить в итоге.

Мне самому пока неясно Буду развивать поэтапно.

WH>Практика показывает что в язык нужно сразу закладывать все что собираешься делать.
WH>Иначе получается куча уродливых нашлепок.
WH>Так что ты уж определись что ты хочешь в язык засунуть.

Я не сторонник водопадной модели разработки.

WH>Отсутствие сборки мусора.
WH>Ручное управление памятью.
WH>Прямой доступ к памяти.

WH>Я тебя правильно понял?

Верно. Но это касается только нижнего уровня, который я разрабатываю сейчас.

WH>Они всегда получаются весьма погаными.

Возможно. Значит, сделаю только интероп.

WH>Ну так раскажи как твое МП будет работать.

По схеме term rewriting.

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

O>В чисто практической повседневной работе возникает масса небольших, но в совокупности
O>очень обременяющих вопросов — как экспортировать класс из dll-ки, не прибегая к разделению
O>стандартного аллокатора (чтобы не зависеть от библиотек рантайма, которые не у всех установлены),
O>как интегрировать в старый проект новый строковой класс с несовместимыми интерфейсами,
O>как гарантировать, что исключение модуля, компилированного GCC, будет корректно перехвачено в
O>коде, написанном на Intel C++, как реализовать паттерн Bridge и при этом не "спалиться" на
O>некорректном выравнивании данных или особенностях оптимизации. И еще много других.

Я имел в виду только те недостатки, которые являются недостатками в чистом виде. Как отсутствие модульности и стандарта на бинарный формат, например.

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

V>По сути согласен с сообщением, а про паттерн "бридж" притянуто за уши. Про что угодно можно сказать, что проблемы с выравниванием данных или, что-то там с оптимизацией. И наоборот, что нет таких проблем. "Мост" ничем особенным не выделяется.

Да, в C/C++ масса ловушек, в любую из них можно угодить.
"Мост" просто подвернулся в качестве наглядного примера того, как невинный на первый взгляд код
может стать причиной труднообнаруживаемых ошибок и непредсказуемого поведения программы.
В этом — весь C/C++, что делает его таким коварным.

Взгляните:

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

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

Но если прогнать код под отладчиком, можно заметить, что m_Impl не выравнивается по границе машинного слова.
Это поведение — часть стандарта, насколько я знаю (знаю теперь, увы, не из стандарта).
MSVC размещает m_Impl по адресу, заканчивающимся 1, т.е. 0x0478C701, GCC по адресу, заканчивающимся 2 — чуть
лучше, но все равно недостаточно. Помимо того, что при таком размещении процессор вынужден обращаться к
объекту Socket_Impl по "дробному" адресу, что с машинной точки зрения расточительно, здесь есть еще одна,
намного более серъезная проблема — доступ к данным в Socket_Impl (int или DWORD, например) тоже не будет
атомарным, и функции синхронизации, такие как InterlockedExchange, не будет выполнять свою работу.

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

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

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

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

Конечно! Вот так надо память "выделять":

struct Socket
    {
    private:
        bool m_bInitialized;
        int m_Impl[(SIZEOF_SOCKET_IMPL_CLASS + sizeof(int) - 1) / sizeof(int)];
    };

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

O>Здравствуйте, voxel3d.
O>Вы писали:

V>>По сути согласен с сообщением, а про паттерн "бридж" притянуто за уши. Про что угодно можно сказать, что проблемы с выравниванием данных или, что-то там с оптимизацией. И наоборот, что нет таких проблем. "Мост" ничем особенным не выделяется.

O>Да, в C/C++ масса ловушек, в любую из них можно угодить.
O>"Мост" просто подвернулся в качестве наглядного примера того, как невинный на первый взгляд код
O>может стать причиной труднообнаруживаемых ошибок и непредсказуемого поведения программы.
O>В этом — весь C/C++, что делает его таким коварным.

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. Ничего не замечаете ? Как будто все в порядке.

Массив m_Impl не выровнен. Это грубая ошибка программиста. Язык тут не при чем, не умеешь такие вещи делать правильно -- не делай.

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

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

K>ну или киньте в меня готовым списком, если такой уже есть

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

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

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

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

А Qt?

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

Ш>Массив m_Impl не выровнен. Это грубая ошибка программиста. Язык тут не при чем, не умеешь такие вещи делать правильно -- не делай.

Согласен на все 100% !
А сколько лично Вы кода написали до того, как узнали об этой особенности компиляции ?
Лично я тысяч так 20, не меньше...

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

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

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

K>А Qt?

Qt это gui. К тому же, использующая свой препроцессор, что не есть гуд.

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

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

Ш>Qt это gui. К тому же, использующая свой препроцессор, что не есть гуд.

Вообще-то это далеко не только гуй, но нормальным я бы его не назвал

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

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

Ш>>Массив m_Impl не выровнен. Это грубая ошибка программиста. Язык тут не при чем, не умеешь такие вещи делать правильно -- не делай.

O>Согласен на все 100% !
O>А сколько лично Вы кода написали до того, как узнали об этой особенности компиляции ?

Это не особенность компиляции, а языка. Память под объект должна быть выровнена. Вобщем то это самоочевидно. Особенно для людей, знающих, что кроме x86 есть и другие процессоры.
Ещё в PDP 11/70 был trap on odd address.

O>Лично я тысяч так 20, не меньше...

Ну я едва ли вспомню сейчас. Это было так давно.

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

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


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

K>>А Qt?

Ш>Qt это gui. К тому же, использующая свой препроцессор, что не есть гуд.

А почему, кстати? Чем свой препроцессор не гуд? (если что, на КуТэ никогда не программил, но код на нем мне нравится радикально лучше, чем на плюсах).

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

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


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

K>>>А Qt?

Ш>>Qt это gui. К тому же, использующая свой препроцессор, что не есть гуд.

E__>А почему, кстати? Чем свой препроцессор не гуд? (если что, на КуТэ никогда не программил, но код на нем мне нравится радикально лучше, чем на плюсах).

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

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

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

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

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

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

E__>А почему, кстати? Чем свой препроцессор не гуд? (если что, на КуТэ никогда не программил, но код на нем мне нравится радикально лучше, чем на плюсах).

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

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

NBN> E__>А почему, кстати? Чем свой препроцессор не гуд? (если что, на КуТэ никогда не программил, но код на нем мне нравится радикально лучше, чем на плюсах).

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

Это расширение позволяет очень сильно упростить/облагородить код. Плюс еще богатая родная библиотека QT.