Ох сейчас холивар начну.
Отсутствие "ступеней" в стиле кода, многие пишут на плюсах, но все по разному, кто-то тупо влоб, кто-то используя темплейты и прочее, кто-то вообще "хитрости" использует, в итоге тот кто гуру видит рабочий код и говорит написано индусами, чайник видит код гуру и идет в курилку обсуждать "чо за нафик" (с) недавно было.
Сильно много свободы, а кому-то потом работать с этим.
Самая большая в мире ложь — "Я прочел и согласен с условиями пользовательского соглашения".
Re: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, Klatu, Вы писали:
K>ну или киньте в меня готовым списком, если такой уже есть
в проекте на С++, с которым приходится иметь дело, в изобилии встречаются ВСЕ имеющиеся проблемы С++, из самых популярных, конечно, это утечки памяти, повреждение памяти, работа с невалидными указателями. код изуверски перекрученный и сложный, реализует принцип: "сделаем простое сложным, сложное — невозможным". глядя на это месиво омерзительное вспоминаешь слова Plauger: "если С++ — ответ, то каким же был вопрос?". смешно, но люди, не зная толком ни С++, ни С, пишут на С++ в стиле кошмарнейшего С — т.е. даже то, что дал С++ по сравнению с С они НЕ ИСПОЛЬЗУЮТ, они неумело, коряво, на грани — пишут на С.
единственное, что успокаивает, на Java или C# у них бы тоже не взлетело
Of course, the code must be complete enough to compile and link.
Re[2]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, Klatu, Вы писали:
F>>отсутствие грамотных программистов.. K>Надо работать с теми, что есть. Другой глобус вам персонально никто не подгонит
я, конечно, не настаиваю, но очевидным выглядит вопрос:
зачем бороться с самым большим недостатком, если можно сбежать на технологии, которые от него избавлены?.
...coding for chaos...
Re[2]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, Lorenzo_LAMAS, Вы писали:
L_L>из самых популярных, конечно, это утечки памяти, повреждение памяти, работа с невалидными указателями.
Ну это типично для любого языка с ручным управлением памятью. Лечится только ампутацией
Когда я недавно опять писал на С++, после большого перерыва, больше всех проблем меня раздражало немного другое.
— деление на include-файлы и cpp-файлы и связанный с этим гемор, костыли вроде pimpl. И необходимость постоянно писать forward declarations, или в случае с классами — declaration и definition для каждой функции. и при каждом изменении сигнатуры — бегать в два разных места. Фак мой мозг. Здравствуй, каменный век, прощайте, умные компиляторы
— полное отсутствие модульности на уровне бинарников. Экспортировать из DLL класс, чтобы использовать в другом модуле — лучше сразу забыть. Или повеситься.
Re[3]: самые серьезные недостатки C и C++, на ваш взгляд?
K>- деление на include-файлы и cpp-файлы и связанный с этим гемор, костыли вроде pimpl. И необходимость постоянно писать forward declarations, или в случае с классами — declaration и definition для каждой функции. и при каждом изменении сигнатуры — бегать в два разных места. Фак мой мозг. Здравствуй, каменный век, прощайте, умные компиляторы K>- полное отсутствие модульности на уровне бинарников. Экспортировать из DLL класс, чтобы использовать в другом модуле — лучше сразу забыть. Или повеситься.
это все так, но мы как-то привыкшие это не самое поганое
Of course, the code must be complete enough to compile and link.
Re: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, Klatu, Вы писали:
K>ну или киньте в меня готовым списком, если такой уже есть
В C авторы, видимо, основное внимание уделили тому, чтобы писать можно было как можно короче, кучу операций в одну строчку, операторы в 1-2 символа. Классический пример — копирование строки с помощью while(*p2++ = *p1++). Ну это ладно, все знают (хотя далеко не все понимают). Другие закрученные конструкции писать считается дурным тоном. А я считаю, что язык не должен содержать таких возможностей, использование которых порицаемо.
В С++ синтаксис шаблонов просто ужасен. Понятно, что это следствие их добавления к уже готовому языку. Но это очень сдерживает их применение.
художников никогда не обижал
Re: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, Klatu, Вы писали:
K>ну или киньте в меня готовым списком, если такой уже есть
1. Ужасный синтаксический оверхед при использовании шаблонов (необходимость писать typename и template для вложенных классов).
2. Разделение на h и cpp
3. Необходимость предварительного объявления имен с сигнатурами (классов, функций, шаблонов).
4. Неединообразный синтаксис (typedef, using, определение постфиксных и префиксных операторов, определение чисто виртуальных методов).
Здравствуйте, Aleх, Вы писали:
A>1. Ужасный синтаксический оверхед при использовании шаблонов (необходимость писать typename и template для вложенных классов). A>4. Неединообразный синтаксис (typedef, using, определение постфиксных и префиксных операторов, определение чисто виртуальных методов).
Можно про эти пункты подробнее?
Re[3]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, Klatu, Вы писали:
K> — полное отсутствие модульности на уровне бинарников. Экспортировать из DLL класс, чтобы использовать в другом модуле — лучше сразу забыть. Или повеситься.
С этим-то какие проблемы? Почему у меня это получается и я не повесился?
Здравствуйте, ocaml, Вы писали:
O>Здравствуйте, Klatu, Вы писали:
K>> — полное отсутствие модульности на уровне бинарников. Экспортировать из DLL класс, чтобы использовать в другом модуле — лучше сразу забыть. Или повеситься.
O>С этим-то какие проблемы? Почему у меня это получается и я не повесился?
Скорее всего, тут имеется ввиду, что один и тот же код может компилироваться по разному на разных компиляторах (в том числе каждый со своей реализацией рантайма), что приведёт к бинарной несовместимости. Как следствие, тут возникают разные правила, что нельзя выделять и освобождать память в разных модулях. Нельзя модифицировать STL-контейнеры не своего модуля и пр.
Re[3]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, Klatu, Вы писали:
K>- полное отсутствие модульности на уровне бинарников. Экспортировать из DLL класс, чтобы использовать в другом модуле — лучше сразу забыть. Или повеситься.
Что сложного то?! Бери (h-ник и lib-ку соответствующие) и используй.
Re[5]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, telek1024, Вы писали:
t> O>С этим-то какие проблемы? Почему у меня это получается и я не повесился?
t> Скорее всего, тут имеется ввиду, что один и тот же код может компилироваться по разному на разных компиляторах (в том числе каждый со своей реализацией рантайма), что приведёт к бинарной несовместимости. Как следствие, тут возникают разные правила, что нельзя выделять и освобождать память в разных модулях. Нельзя модифицировать STL-контейнеры не своего модуля и пр.
Ну, топикстартер не смог ясно сказать, что он имеет в виду
Просто я не вижу проблемы писать модульную программу, используя один компилятор. Хотя даже на разных языках был проект. На С++ использовался класс из dll на Delphi. Как ни странно, все работало и работает.
Здравствуйте, Klatu, Вы писали:
K> O>С этим-то какие проблемы? Почему у меня это получается и я не повесился?
K> Фокусник наверно, не иначе. Мастер фигурного хождения по граблям
Здравствуйте, Aleх, Вы писали:
A>1. Ужасный синтаксический оверхед при использовании шаблонов (необходимость писать typename и template для вложенных классов).
typename в С++0х вроде как уже вообще не надо. А нормальные компиляторы вообще давно его не требуют.
A>2. Разделение на h и cpp
Честно говоря вообще никогда не парило. Понимаю зачем это надо и пользуюсь соответственно.
A>3. Необходимость предварительного объявления имен с сигнатурами (классов, функций, шаблонов).
А в чём проблема то?
A>4. Неединообразный синтаксис (typedef, using, определение постфиксных и префиксных операторов, определение чисто виртуальных методов).
немного невнятно только с постфикс/префикс операторами ну и может pure virtual было бы лучше ключевым словом, хотя и так не напрягает. Всё остальное вменяемо
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[5]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, telek1024, Вы писали:
T>Скорее всего, тут имеется ввиду, что один и тот же код может компилироваться по разному на разных компиляторах (в том числе каждый со своей реализацией рантайма), что приведёт к бинарной несовместимости.
Не может, а обязательно будет.
И на разных версиях одного компилятора тоже. И на разных версиях CRT одного компилятора. И еще бывают всякие веселости, если кто-нибудь заэмбеддит CRT в модуль. Или модули откомпилированы с разными настройками.. для исключений, например.
Так что, такая идея — это шикарный шанс обрести массу совершенно неочевидных граблей.
T>Как следствие, тут возникают разные правила, что нельзя выделять и освобождать память в разных модулях. Нельзя модифицировать STL-контейнеры не своего модуля и пр.
Ну и что же это за модульность, если нужна куча правил, что можно и чего нельзя использовать через границу модулей?
Здравствуйте, Klatu, Вы писали:
K>Размышляю на тему создания своего велосипеда с ядерным реактором и нестираемыми шинами.
Те хочешь сделать свой язык программирования?
Тогда тебе нужно подходить с другой стороны.
1)Сформулировать требования к языку.
2)Проанализировать кучу совершенно разных языков даже тех которые казалось бы и близко не то что тебе надо. Никогда не знаешь где найдешь подсказку.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, WolfHound, Вы писали:
WH>Тогда тебе нужно подходить с другой стороны. WH>1)Сформулировать требования к языку. WH>2)Проанализировать кучу совершенно разных языков даже тех которые казалось бы и близко не то что тебе надо. Никогда не знаешь где найдешь подсказку.
У меня написан уже целый талмуд с фичами, которые я потырил из других языков или придумал сам. Но это всё потом.
Пока что я хочу пойти по пути минимализма. То есть сделать очень простой язык на основе C, очищенный от его недостатков, и приделать к нему возможность расширения синтаксиса. Т.е. метапрограммирование.
Такой проект уже будет представлять собой некоторую практическую ценность, потому что все еще дофига проектов, где пишут на чистом Си и мигрировать на С++ не собираются (и их во многом можно понять).
Ну а потом при помощи МП можно будет нарастить любой функционал, который потребуется.
Здравствуйте, Klatu, Вы писали:
K>У меня написан уже целый талмуд с фичами, которые я потырил из других языков или придумал сам. Но это всё потом.
Если фичей толмуд значит они противоречивы.
Вот тут я не понял: K>Пока что я хочу пойти по пути минимализма. То есть сделать очень простой язык на основе C, очищенный от его недостатков, и приделать к нему возможность расширения синтаксиса. Т.е. метапрограммирование.
Или ты забиваешь на обратную совместимость с С
K>Такой проект уже будет представлять собой некоторую практическую ценность, потому что все еще дофига проектов, где пишут на чистом Си и мигрировать на С++ не собираются (и их во многом можно понять).
Или язык должен быть обратно совместимым с С.
Ты уж определись.
K>Ну а потом при помощи МП можно будет нарастить любой функционал, который потребуется.
Сделать хорошое МП очень не просто.
Чтобы МП получилось его нужно закладывать в язык с самого начала и все строить с учетом МП и при помощи МП.
Те абсолютно все должно проходить через механику МП. Иначе ничего работать не будет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Если фичей толмуд значит они противоречивы.
Нет. Просто у меня много идей Со временем решу, какие из них по настоящему ценны.
А пока что — разумно необходимый минимум.
WH>Или ты забиваешь на обратную совместимость с С
Забиваю. По другому недостатки не выправишь.
Но ничто не мешает сделать конвертор из C в мой язык, равно как и бинарный интероп.
WH>Чтобы МП получилось его нужно закладывать в язык с самого начала и все строить с учетом МП и при помощи МП. WH>Те абсолютно все должно проходить через механику МП. Иначе ничего работать не будет.
Здравствуйте, любой, Вы писали:
Л>Здравствуйте, Klatu, Вы писали:
Л>...
Л>Сделай так, что если тип параметра функции или переменной не указан — это темплейтный аргумент.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, опечатки
Какие опечатки? Я считаю, что типы переменных вообще у программиста редко потребность должна возникать указывать. В основном, только у входных и выходных данных. А остальные должны выводиться автоматически.
Здравствуйте, Klatu, Вы писали:
L_L>>из самых популярных, конечно, это утечки памяти, повреждение памяти, работа с невалидными указателями.
K>Ну это типично для любого языка с ручным управлением памятью. Лечится только ампутацией
С++ допускает и ручное и автоматическое управление памятью, по желанию.
K>Когда я недавно опять писал на С++, после большого перерыва, больше всех проблем меня раздражало немного другое.
Меня больше всего раздражает отсутствие чёткого владельца и внятной единой полноценной стандартной современной библиотеки.
Нужно разобрать угил.
Re[3]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, CreatorCray, Вы писали:
A>>3. Необходимость предварительного объявления имен с сигнатурами (классов, функций, шаблонов). CC>А в чём проблема то?
То что компилер мог бы и сам это найти.
Нужно разобрать угил.
Re: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, NikeByNike, Вы писали:
A>>>3. Необходимость предварительного объявления имен с сигнатурами (классов, функций, шаблонов). CC>>А в чём проблема то?
NBN>То что компилер мог бы и сам это найти.
Нет уж спасибо.
А если мне надо наружу выставить только 1 класс а остальное спрятать от того, кто мою lib будет использовать
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[5]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, CreatorCray, Вы писали:
A>>>>3. Необходимость предварительного объявления имен с сигнатурами (классов, функций, шаблонов). CC>>>А в чём проблема то?
NBN>>То что компилер мог бы и сам это найти. CC>Нет уж спасибо. CC>А если мне надо наружу выставить только 1 класс а остальное спрятать от того, кто мою lib будет использовать
Это решается документацией
Нужно разобрать угил.
Re[5]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, CreatorCray, Вы писали:
CC>А если мне надо наружу выставить только 1 класс а остальное спрятать от того, кто мою lib будет использовать
Ты на C# посмотри да... Никакого предварительного объявления и что выставлять прекрасно контролируется.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Klatu, Вы писали:
K>Нет. Просто у меня много идей Со временем решу, какие из них по настоящему ценны.
Ну так изложи эти идеи.
Пока не ясно даже что за язык ты хочешь получить в итоге.
K>А пока что — разумно необходимый минимум.
Практика показывает что в язык нужно сразу закладывать все что собираешься делать.
Иначе получается куча уродливых нашлепок.
Так что ты уж определись что ты хочешь в язык засунуть.
K>Забиваю. По другому недостатки не выправишь.
Значит это новый язык.
Раз ты упомянул С то это сразу означает:
Отсутствие сборки мусора.
Ручное управление памятью.
Прямой доступ к памяти.
Я тебя правильно понял?
K>Но ничто не мешает сделать конвертор из C в мой язык, равно как и бинарный интероп.
На конвертор сразу забей.
Они всегда получаются весьма погаными.
WH>>Чтобы МП получилось его нужно закладывать в язык с самого начала и все строить с учетом МП и при помощи МП. WH>>Те абсолютно все должно проходить через механику МП. Иначе ничего работать не будет. K>Само собой.
Ну так раскажи как твое МП будет работать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, любой, Вы писали:
Л>Здравствуйте, Klatu, Вы писали:
K>>ну или киньте в меня готовым списком, если такой уже есть
Л>В C авторы, видимо, основное внимание уделили тому, чтобы писать можно было как можно короче, кучу операций в одну строчку, операторы в 1-2 символа. Классический пример — копирование строки с помощью while(*p2++ = *p1++). Ну это ладно, все знают (хотя далеко не все понимают). Другие закрученные конструкции писать считается дурным тоном. А я считаю, что язык не должен содержать таких возможностей, использование которых порицаемо.
Л>В С++ синтаксис шаблонов просто ужасен. Понятно, что это следствие их добавления к уже готовому языку. Но это очень сдерживает их применение.
К несчастью только далеко не все, кто знает что строку можно скопировать через while(*p2++ = *p1++), знают почему так делать не нужно
Re: самые серьезные недостатки C и C++, на ваш взгляд?
Самые серъезные недостатки C и C++ ? Они лежат с обратной стороны их главных достоинств.
Эти языки настолько низкоуровневы и близки к "железу", что делают возможным написание
эффективного кода, который (с учетом достижений современных компиляторов) иногда обгоняет
написанные на ассемблере аналоги. Но именно из-за этого фактора очень часто невозможно
"просто" заниматься бизнес-логикой — приходится заботиться об атомарности доступа, писать
volatile и полагаться только на интегральные типы. Код при этом несколько теряет в
привлекательности, а хорошие библиотечные инструменты вообще сплошь состоят из макросов,
встроенных функций, ассертов и asm-вставок, не редкость также всякие language extensions,
рассчитанные на специфику платформы. Парадокс — чтобы писать эффективные программы на
C/C++, нужно отлично разбираться в нюансах работы процессоров, кэша, памяти, уметь
представлять генерируемый машинный код и затраты на его выполнение.
За нами намеренно оставили право не делать деструктор виртуальным, не переопределять явно
некоторые методы, не выводить один тип от другого и самим прибирать за собой использованные
ресурсы. И именно на этой почве возникают всяческие ошибки, когда этими средствами пытается
пользоваться неподготовленный человек. Но есть ситуации, где даже хорошо подкованные могут
разве что заглянуть в стандарт и развести руками. И это тоже не делает чести языкам.
В чисто практической повседневной работе возникает масса небольших, но в совокупности
очень обременяющих вопросов — как экспортировать класс из dll-ки, не прибегая к разделению
стандартного аллокатора (чтобы не зависеть от библиотек рантайма, которые не у всех установлены),
как интегрировать в старый проект новый строковой класс с несовместимыми интерфейсами,
как гарантировать, что исключение модуля, компилированного GCC, будет корректно перехвачено в
коде, написанном на Intel C++, как реализовать паттерн Bridge и при этом не "спалиться" на
некорректном выравнивании данных или особенностях оптимизации. И еще много других.
Короче, языки "технарей", существующие будто для того, чтобы набить шишек, настрочить говнокода,
наплодить велосипедов, а затем пересесть на Java или .NET со словами "все мужики сволочи".
Re[2]: самые серьезные недостатки C и C++, на ваш взгляд?
По сути согласен с сообщением, а про паттерн "бридж" притянуто за уши. Про что угодно можно сказать, что проблемы с выравниванием данных или, что-то там с оптимизацией. И наоборот, что нет таких проблем. "Мост" ничем особенным не выделяется.
Здравствуйте, WolfHound, Вы писали:
WH>Ну так изложи эти идеи. WH>Пока не ясно даже что за язык ты хочешь получить в итоге.
Мне самому пока неясно Буду развивать поэтапно.
WH>Практика показывает что в язык нужно сразу закладывать все что собираешься делать. WH>Иначе получается куча уродливых нашлепок. WH>Так что ты уж определись что ты хочешь в язык засунуть.
Я не сторонник водопадной модели разработки.
WH>Отсутствие сборки мусора. WH>Ручное управление памятью. WH>Прямой доступ к памяти.
WH>Я тебя правильно понял?
Верно. Но это касается только нижнего уровня, который я разрабатываю сейчас.
WH>Они всегда получаются весьма погаными.
Возможно. Значит, сделаю только интероп.
WH>Ну так раскажи как твое МП будет работать.
По схеме term rewriting.
Re[2]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, okman, Вы писали:
O>В чисто практической повседневной работе возникает масса небольших, но в совокупности O>очень обременяющих вопросов — как экспортировать класс из dll-ки, не прибегая к разделению O>стандартного аллокатора (чтобы не зависеть от библиотек рантайма, которые не у всех установлены), O>как интегрировать в старый проект новый строковой класс с несовместимыми интерфейсами, O>как гарантировать, что исключение модуля, компилированного GCC, будет корректно перехвачено в O>коде, написанном на Intel C++, как реализовать паттерн Bridge и при этом не "спалиться" на O>некорректном выравнивании данных или особенностях оптимизации. И еще много других.
Я имел в виду только те недостатки, которые являются недостатками в чистом виде. Как отсутствие модульности и стандарта на бинарный формат, например.
Re[3]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, voxel3d.
Вы писали:
V>По сути согласен с сообщением, а про паттерн "бридж" притянуто за уши. Про что угодно можно сказать, что проблемы с выравниванием данных или, что-то там с оптимизацией. И наоборот, что нет таких проблем. "Мост" ничем особенным не выделяется.
Да, в C/C++ масса ловушек, в любую из них можно угодить.
"Мост" просто подвернулся в качестве наглядного примера того, как невинный на первый взгляд код
может стать причиной труднообнаруживаемых ошибок и непредсказуемого поведения программы.
В этом — весь C/C++, что делает его таким коварным.
Вроде бы ничего подозрительного — при создании объекта 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, не будет выполнять свою работу.
Компиляторы и статические анализаторы блаженно молчат, приложение с таким кодом будет
годами работать и не падать. До определенного времени.
Re[4]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, okman, Вы писали:
O>Здравствуйте, voxel3d. O>Вы писали:
V>>По сути согласен с сообщением, а про паттерн "бридж" притянуто за уши. Про что угодно можно сказать, что проблемы с выравниванием данных или, что-то там с оптимизацией. И наоборот, что нет таких проблем. "Мост" ничем особенным не выделяется.
O>Да, в C/C++ масса ловушек, в любую из них можно угодить. O>"Мост" просто подвернулся в качестве наглядного примера того, как невинный на первый взгляд код O>может стать причиной труднообнаруживаемых ошибок и непредсказуемого поведения программы. O>В этом — весь C/C++, что делает его таким коварным.
O>Взгляните: O>
O>Вроде бы ничего подозрительного — при создании объекта Socket он инициализирует массив m_Impl объектом O>Socket_Impl (реализация) с помощью placement new. Оставим пока в стороне вопросы обеспечения O>корректного значения SIZEOF_SOCKET_IMPL_CLASS. Ничего не замечаете ? Как будто все в порядке.
Массив m_Impl не выровнен. Это грубая ошибка программиста. Язык тут не при чем, не умеешь такие вещи делать правильно -- не делай.
Здравствуйте, Шахтер, Вы писали:
Ш>На сегодняшний день самым большим недостатком С++ является отсутствие хорошей публичной библиотеки классов для решения типичных общих задач.
А Qt?
Re[5]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, Шахтер, Вы писали:
Ш>Массив m_Impl не выровнен. Это грубая ошибка программиста. Язык тут не при чем, не умеешь такие вещи делать правильно -- не делай.
Согласен на все 100% !
А сколько лично Вы кода написали до того, как узнали об этой особенности компиляции ?
Лично я тысяч так 20, не меньше...
Re[3]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, Klatu, Вы писали:
K>Здравствуйте, Шахтер, Вы писали:
Ш>>На сегодняшний день самым большим недостатком С++ является отсутствие хорошей публичной библиотеки классов для решения типичных общих задач.
K>А Qt?
Qt это gui. К тому же, использующая свой препроцессор, что не есть гуд.
Здравствуйте, okman, Вы писали:
O>Здравствуйте, Шахтер, Вы писали:
Ш>>Массив m_Impl не выровнен. Это грубая ошибка программиста. Язык тут не при чем, не умеешь такие вещи делать правильно -- не делай.
O>Согласен на все 100% ! O>А сколько лично Вы кода написали до того, как узнали об этой особенности компиляции ?
Это не особенность компиляции, а языка. Память под объект должна быть выровнена. Вобщем то это самоочевидно. Особенно для людей, знающих, что кроме x86 есть и другие процессоры.
Ещё в PDP 11/70 был trap on odd address.
O>Лично я тысяч так 20, не меньше...
Ш>>>На сегодняшний день самым большим недостатком С++ является отсутствие хорошей публичной библиотеки классов для решения типичных общих задач.
K>>А Qt?
Ш>Qt это gui. К тому же, использующая свой препроцессор, что не есть гуд.
А почему, кстати? Чем свой препроцессор не гуд? (если что, на КуТэ никогда не программил, но код на нем мне нравится радикально лучше, чем на плюсах).
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[5]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, Eugeny__, Вы писали:
E__>Здравствуйте, Шахтер, Вы писали:
Ш>>>>На сегодняшний день самым большим недостатком С++ является отсутствие хорошей публичной библиотеки классов для решения типичных общих задач.
K>>>А Qt?
Ш>>Qt это gui. К тому же, использующая свой препроцессор, что не есть гуд.
E__>А почему, кстати? Чем свой препроцессор не гуд? (если что, на КуТэ никогда не программил, но код на нем мне нравится радикально лучше, чем на плюсах).
Вообще-то Qt -- это С++. При использовании внешних средств, не встроенных в язык, обычно возникают неприятные вещи. Начиная с проблемами с раскраской кода.
Здравствуйте, Шахтер, Вы писали:
Ш>Вообще-то Qt -- это С++. При использовании внешних средств, не встроенных в язык, обычно возникают неприятные вещи. Начиная с проблемами с раскраской кода.
Пропущено "не"?
Re[5]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, Eugeny__, Вы писали:
E__>А почему, кстати? Чем свой препроцессор не гуд? (если что, на КуТэ никогда не программил, но код на нем мне нравится радикально лучше, чем на плюсах).
Так это и есть плюсы Только с небольшим расширением.
Нужно разобрать угил.
Re[6]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, NikeByNike, Вы писали:
NBN> E__>А почему, кстати? Чем свой препроцессор не гуд? (если что, на КуТэ никогда не программил, но код на нем мне нравится радикально лучше, чем на плюсах).
NBN> Так это и есть плюсы Только с небольшим расширением.
Это расширение позволяет очень сильно упростить/облагородить код. Плюс еще богатая родная библиотека QT.
Здравствуйте, ocaml, Вы писали:
NBN>> Так это и есть плюсы Только с небольшим расширением.
O>Это расширение позволяет очень сильно упростить/облагородить код.
Вот этого если честно не очень заметно.
O>Плюс еще богатая родная библиотека QT.
Вот это — да
Нужно разобрать угил.
Re[8]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, NikeByNike, Вы писали:
NBN> NBN>> Так это и есть плюсы Только с небольшим расширением.
NBN> O>Это расширение позволяет очень сильно упростить/облагородить код.
NBN> Вот этого если честно не очень заметно.
А с чем сравнивать? Могу предложить плюсы с MFC против плюсов с QT Вариант "С++ и чистый WinAPI" не рассматриваю — написался на нем до изжоги.
Здравствуйте, ocaml, Вы писали:
NBN>> O>Это расширение позволяет очень сильно упростить/облагородить код.
NBN>> Вот этого если честно не очень заметно.
O> А с чем сравнивать? Могу предложить плюсы с MFC против плюсов с QT Вариант "С++ и чистый WinAPI" не рассматриваю — написался на нем до изжоги.
Так надо сравнивать с хорошей С++ библиотекой. MFC — однозначно очень плохая система, WinAPI — никак не С++
Нужно разобрать угил.
Re[10]: самые серьезные недостатки C и C++, на ваш взгляд?
NBN> O> А с чем сравнивать? Могу предложить плюсы с MFC против плюсов с QT Вариант "С++ и чистый WinAPI" не рассматриваю — написался на нем до изжоги.
NBN> Так надо сравнивать с хорошей С++ библиотекой. MFC — однозначно очень плохая система
Ну так я про то и спрашиваю. С чем сравнить? Сравниваем не библиотеки, а код на С++ с использованием той или иной библиотеки. Неужто найдется что-то лучшее QT?
Здравствуйте, Шахтер, Вы писали:
Ш>На сегодняшний день самым большим недостатком С++ является отсутствие хорошей публичной библиотеки классов для решения типичных общих задач.
boost
Re[6]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, Klatu, Вы писали:
K>Здравствуйте, telek1024, Вы писали:
K>Ну и что же это за модульность, если нужна куча правил, что можно и чего нельзя использовать через границу модулей?
Это конракт. В Java и .NET тоже есть условие, (О, ужас!) что эквивалентные объекты имеют один и тот же хэш. А-а-а! Как можно писать на них!?
Просто в современных языках это отдано на откуп фреймворку (Например маршаллинг managed/unmanaged в .NET), а в самом языке нет механизмов для нарушения этих правил. C++ более низкоуровневый. Там легче "выстрелить себе в ногу", но и возможности программиста выше.
Re[7]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, telek1024, Вы писали:
T>Это конракт. В Java и .NET тоже есть условие, (О, ужас!) что эквивалентные объекты имеют один и тот же хэш. А-а-а! Как можно писать на них!?
Не надо сравнивать жопу с пальцем. Никакой это не контракт. Стандарт вообще никак не гарантирует, что такой код у тебя будет работать, даже если ты соблюдешь все мыслимые условия. То, на что полагаешься — это особенности реализации, это undefined behavior.
Re[8]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, 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. И даже память течь не будет.
А про особенности реализации, так это про всё что угодно сказать можно.
Re[11]: самые серьезные недостатки C и C++, на ваш взгляд?
NBN>> Так надо сравнивать с хорошей С++ библиотекой. MFC — однозначно очень плохая система
O>Ну так я про то и спрашиваю. С чем сравнить? Сравниваем не библиотеки, а код на С++ с использованием той или иной библиотеки. Неужто найдется что-то лучшее QT?
Ну из кусочков можно собрать, например boost + wxWidgets
Re[9]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, Klatu, Вы писали:
1. сформулируй цель создания языка. Возможно — несколько. Никлаус Вирт при создании Паскаля формулировал, Страуструп при создании С++ формулировал... От цели — сильно большая разница получается.
2. Очерти область применения. От области применения — сильно разные языки получаются.
3. Сформулируй основной принцип языка. Пример С++: все, что не запрещено явно — то разрешено. Пример Оберон: все, что не разрешено явно — запрещено. Разница — колоссальная!
Например, в Яве наследование запрещается специальным ключевым словом, а в Компонентном паскале — разрешается специальным ключевым словом.
4. Четко раздели свойства языка и библиотеку. Свойства языка — это гранит, который потом сложно поправить. А библиотеку можно расширять, изменять и переписывать. В этом смысле язык должен быть минимален, а библиотека обширна.
ИМХО, пока судя по твоим постам получается, что ты собираешься создавать очередного монстра...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[7]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, Klatu, Вы писали:
K>Здравствуйте, Шахтер, Вы писали:
Ш>>Вообще-то Qt -- это С++. При использовании внешних средств, не встроенных в язык, обычно возникают неприятные вещи. Начиная с проблемами с раскраской кода.
K>Пропущено "не"?
O>Вроде бы ничего подозрительного — при создании объекта Socket он инициализирует массив m_Impl объектом O>Socket_Impl (реализация) с помощью placement new. Оставим пока в стороне вопросы обеспечения O>корректного значения SIZEOF_SOCKET_IMPL_CLASS. Ничего не замечаете ? Как будто все в порядке.
Замечаю. Например, у вас будет reinterpret_cast, а это как бы намекает на возможные проблемы.
Если вы нарушаете систему типов, то вы берете на себя ответственность за последствия. С++ позволяет вам это сделать, но подразумевается что у вас есть основания так делать и вы осознаете результаты.
И только если вы сделали так, увидели что все тормозит, запустили профайлер, поняли что дело именно в конструировании объектов Socket, то можно заняться экспериментами со статическим массивом (предварительно погуглив насчет размещения объектов в памяти, struct max_aligned и т.д.)
Re[2]: самые серьезные недостатки C и C++, на ваш взгляд?
Ш>Это не особенность компиляции, а языка. Память под объект должна быть выровнена. Вобщем то это самоочевидно. Особенно для людей, знающих, что кроме x86 есть и другие процессоры.
Похоже это не было самоочевидно для авторов языка и компилятора.
Re[3]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, Klatu, Вы писали:
LVV>>ИМХО, пока судя по твоим постам получается, что ты собираешься создавать очередного монстра...
K>Ну и пусть монстр. Главное — чтобы зубастый
То есть, ты тоже не знаешь, где взять PL/I.
Re[4]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, Шахтер, Вы писали:
Ш>>Это не особенность компиляции, а языка. Память под объект должна быть выровнена. Вобщем то это самоочевидно. Особенно для людей, знающих, что кроме x86 есть и другие процессоры.
Т>Похоже это не было самоочевидно для авторов языка и компилятора.
Здравствуйте, shrecher, Вы писали:
S>В C++ не хватает автоматического обнуления всех членов класса при создании объекта.
S>
S>class A
S>{
S> int foo;
S>public:
S> A() :
S> foo(0) //<<<< это должно быть автоматически
S> {}
S>};
S>
А если у нас по адресу переменной foo находится порт ввода-вывода и запись в него нуля означает запуск системы самоуничтожения устройства, путём подрыва динамитной шашки?
Если не поможет, будем действовать током... 600 Вольт (C)
Re[2]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, shrecher, Вы писали:
S>Здравствуйте, Klatu, Вы писали:
K>>ну или киньте в меня готовым списком, если такой уже есть
S>В C++ не хватает автоматического обнуления всех членов класса при создании объекта.
Это не всегда нужно.
Если так уж нужно — создавай в заранее обнуленной памяти, либо, если без конструктора, используй = {}
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, shrecher, Вы писали:
S>>Здравствуйте, Klatu, Вы писали:
K>>>ну или киньте в меня готовым списком, если такой уже есть
S>>В C++ не хватает автоматического обнуления всех членов класса при создании объекта.
J>Это не всегда нужно.
В очень многих случаях это нужно и полезно, т.к повышает надежность кода. Где эта фича снижает производительность, можно было бы ввести какую-нибудь "pragama", которая бы отключала обнуление памяти для указанного класса.
J>Если так уж нужно — создавай в заранее обнуленной памяти, либо, если без конструктора, используй = {}
кончено все в ручную сделать возможно, но много лишних действий приходится совешать.
Re[3]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, -MyXa-, Вы писали:
MX>Здравствуйте, shrecher, Вы писали:
MX>А если у нас по адресу переменной foo находится порт ввода-вывода и запись в него нуля означает запуск системы самоуничтожения устройства, путём подрыва динамитной шашки?
Не об этом, просто обнулить память где объект будет создан, еще до вызова конструктора.
Re[4]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, shrecher, Вы писали:
S>Здравствуйте, -MyXa-, Вы писали:
MX>>Здравствуйте, shrecher, Вы писали:
MX>>А если у нас по адресу переменной foo находится порт ввода-вывода и запись в него нуля означает запуск системы самоуничтожения устройства, путём подрыва динамитной шашки?
S>Не об этом, просто обнулить память где объект будет создан, еще до вызова конструктора.
Об этом, об этом. Просто "обнулить память" может быть не так просто. Что в моём примере тебе не понятно?
А "до вызова конструктора", так это можно свой оператор new написать, чтоб обнулял. Такой в Symbian, например, есть.
Если не поможет, будем действовать током... 600 Вольт (C)
Re[5]: самые серьезные недостатки C и C++, на ваш взгляд?
S>>Не об этом, просто обнулить память где объект будет создан, еще до вызова конструктора.
MX>Об этом, об этом. Просто "обнулить память" может быть не так просто. Что в моём примере тебе не понятно?
Чесно говоря, не понятно, почему это сложно обнулить память до создания объекта?
посути дела, нужно чтобы компилятор реализовывал что-то вроде
конструкция вида
A a;
преврашается что
void *a = getmem(sizeof(A)); //получили кусок памяти либо malloc, либо "sub ESP" если на стеке
memset( a, 0, sizeof(A) ); // зануляем
ctor( A, a) // вызываем конструктор
кроме memset это ничем от текущей c++ реализации не отличается. Если объект сверх большой (что редко), то нужно какая-нибудь опция запрещения memset для данного класса.
MX>А "до вызова конструктора", так это можно свой оператор new написать, чтоб обнулял. Такой в Symbian, например, есть.
Во-первых, объект может быть создан на стеке. В томже Symbian это сильно не преветствуется как раз по причне своего new. Во-вторых, написание new/delete требует услий, увеличивает количество кода, повышает шансы сделать ошибки.
Re[2]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, shrecher, Вы писали:
S>Здравствуйте, Klatu, Вы писали:
K>>ну или киньте в меня готовым списком, если такой уже есть
S>В C++ не хватает автоматического обнуления всех членов класса при создании объекта.
Сейчас тебе объяснят, что обнуление — жуть какая дорогущая операция, а потому всегда все надо делать вручную, и только когда нужно.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[6]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, shrecher, Вы писали:
S>Чесно говоря, не понятно, почему это сложно обнулить память до создания объекта?
А зачем?
S>Во-вторых, написание new/delete требует усилий
Для обнуляющего new колво "усилий" просто потрясает.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[3]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, Eugeny__, Вы писали:
E__>Сейчас тебе объяснят, что обнуление — жуть какая дорогущая операция, а потому всегда все надо делать вручную, и только когда нужно.
Скорее что "платишь только за то, что заказал"
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[4]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, shrecher, Вы писали:
S>В очень многих случаях это нужно и полезно, т.к повышает надежность кода. Где эта фича снижает производительность, можно было бы ввести какую-нибудь "pragama", которая бы отключала обнуление памяти для указанного класса.
В D довольно удобно сделано, переменные по умолчанию всегда инициализируются, чтобы этого не происходило нужно явно присваивать им void:
Здравствуйте, CreatorCray, Вы писали:
S>>Чесно говоря, не понятно, почему это сложно обнулить память до создания объекта? CC>А зачем?
Для того, что бы избавиться от проблемы неинициализированых филдов, например указателей.
ASSERT(parameter != NULL);
Вот эта вещь в С++ смысла не имеет, потому что неинициализированые указатели съедают весь профит. Зато в джаве или дотнет это и подобное превращается фактически в контракт и примерно вдвое-втрое сокращает время отладки. Например ассерт на входе, на выходе и в дебаге можно выполнить юнит-тест — продакшн код тестирующий сам себя. В С++ это практически недоступно из за отсутствия очистки памяти и слабой языковой поддержки.
Материал из Википедии — свободной энциклопедии, -_*
Re[8]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, LR, Вы писали:
LR>Для того, что бы избавиться от проблемы неинициализированых филдов, например указателей.
Гм. А что мешает их нормально инициализировать?
LR>Зато в джаве или дотнет это и подобное превращается фактически в контракт и примерно вдвое-втрое сокращает время отладки.
Смешное в этом то, что я не помню когда последний раз у меня был баг с неинициализированной переменной.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[9]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, CreatorCray, Вы писали:
LR>>Для того, что бы избавиться от проблемы неинициализированых филдов, например указателей. CC>Гм. А что мешает их нормально инициализировать?
Не что, а кто. Другие люди, которым лень заниматься такой мелочевкой. Чем больше проект, тем нужнее ассерты и тем больше вероятность, что ктото будет игнорировать подобные правила. Если на проекте около сотни коммитеров, то RAII уже не поможет.
LR>>Зато в джаве или дотнет это и подобное превращается фактически в контракт и примерно вдвое-втрое сокращает время отладки. CC>Смешное в этом то, что я не помню когда последний раз у меня был баг с неинициализированной переменной.
Ты вероятно имеешь дело только со своим кодом
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, x-code, Вы писали:
XC>А можно ознакомиться?
Это по большей части бессистемные обрывки мыслей, которые еще надо привести к удобочитаемому виду.
Например, одна из идей — полностью выбросить из языка глобальные и статические переменные. Вместо этого использовать механизм контекстов, которые хранят разделяемые данные. Контекст можно инициировать в вызове функции, и все вложенные вызовы функций с этого места и глубже по стеку имеют доступ к данным этого контекста. Аналогично можно привязать контекст к объекту, и все принадлежащие к тому же контексту объекты и их методы будут иметь доступ к разделяемым данным.
Здравствуйте, Jolly Roger, Вы писали:
JR> K>А что, переменные разве бывают какие-то другие кроме мутабельных?
JR> В дельфи бывают. Есть там такое футуристическое изобретение — мутабельная константа
Только в том случае, если ты сам эту фичу включишь. По дефолту она выключена. Это послабление сделано было для тех, кому секцию инициализации (явную в дельфях и не явную в турбо-паскале) лень использовать.
Здравствуйте, hattab, Вы писали:
H>Только в том случае, если ты сам эту фичу включишь.
Да я как-бы в курсе, но это, однако, не отменяет её футуристичности И ненужности, ибо банальная глобальная переменная полностью перекрывает её функционал, не выходя при этом за грань логики
Здравствуйте, Jolly Roger, Вы писали:
JR> H>Только в том случае, если ты сам эту фичу включишь.
JR> Да я как-бы в курсе, но это, однако, не отменяет её футуристичности И ненужности, ибо банальная глобальная переменная полностью перекрывает её функционал, не выходя при этом за грань логики
Ну, с футуристичностью согласен, да Но вот разница между глобальными переменными и типизированными константами все же есть. Глобальные переменные (да и переменные вообще) в дельфях не поддерживают инициализации при объявлении, а вот те константы поддерживают
Здравствуйте, hattab, Вы писали:
H>Но вот разница между глобальными переменными и типизированными константами все же есть. Глобальные переменные (да и переменные вообще) в дельфях не поддерживают инициализации при объявлении, а вот те константы поддерживают
Вот те здрасте Это с какой версии?
var A: integer = 25;
7-я отлично принимает Я, правда, с более поздними не знаком, а более ранние не помню Вы, часом, с локальными не спутали?
Здравствуйте, Jolly Roger, Вы писали:
JR> H>Но вот разница между глобальными переменными и типизированными константами все же есть. Глобальные переменные (да и переменные вообще) в дельфях не поддерживают инициализации при объявлении, а вот те константы поддерживают
JR> Вот те здрасте Это с какой версии?
JR>
JR> var A: integer = 25;
JR>
JR> 7-я отлично принимает Я, правда, с более поздними не знаком, а более ранние не помню Вы, часом, с локальными не спутали?
Возможность инициализировать глобальные переменные появилась только во второй версии Delphi. Именно поэтому такие футуристические константы были возможны
Здравствуйте, LR, Вы писали:
LR>>>Для того, что бы избавиться от проблемы неинициализированых филдов, например указателей. CC>>Гм. А что мешает их нормально инициализировать? LR>Не что, а кто. Другие люди, которым лень заниматься такой мелочевкой.
Скипидарные клизмы спасут человечество.
LR>>>Зато в джаве или дотнет это и подобное превращается фактически в контракт и примерно вдвое-втрое сокращает время отладки. CC>>Смешное в этом то, что я не помню когда последний раз у меня был баг с неинициализированной переменной. LR>Ты вероятно имеешь дело только со своим кодом
Есть ещё команда в US, так что нет, не только.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[11]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, -MyXa-, Вы писали:
LR>>Если на проекте около сотни коммитеров, то RAII уже не поможет.
MX>Позвольте осведомиться, после какого точного количества "коммитеров" RAII уже окончательно перестаёт им помогать?
Значение зависит от управления проектом. Например есть ли у руководителя проектом возможность отбирать коммитеров или нет. В некоторых компаниях на проектах работают чуть не одни только родственники топ-менеджеров
Материал из Википедии — свободной энциклопедии, -_*
Re[8]: самые серьезные недостатки C и C++, на ваш взгляд?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, telek1024, Вы писали:
T>>Это конракт. В Java и .NET тоже есть условие, (О, ужас!) что эквивалентные объекты имеют один и тот же хэш.
НС>Нет такого условия в .NET и Java. Такое условие есть только у конкретной реализации словаря, да и то внешний компаратор подсунуть элементарно.
Здравствуйте, Klatu, Вы писали:
K>Здравствуйте, telek1024, Вы писали:
T>>Это вообще к чему было сказано?
K>Подзаряди мозги.
Не вырывай фразу из контекста.
T>>Я — полагаюсь на стандарты. И согласно стандарту два разных модуля могут работать вместе
K>Покажи мне место в стандарте, где это гарантируется.
Бери (h-ник и lib-ку соответствующие) и используй.
"Нормальные герои всегда идут в обход!"
