Мне интересны ваши мысли. Я прокомментирую по ходу

Читабельностью...

> Чем вам лично не нравится CPP?
> Мне интересны ваши мысли.


"Откуда дровишки?" ©

В смысле, а почему оно нам не нравится?

> Чем вам лично не нравится CPP?

Знаю не в совершенстве. Отсюда некоторый комплекс, что я не настоящий программист.

тьфу блин... я рассчитывал увидеть конкретные вещи, а не начинать новую священную войну.
----------
var i, j, k : Integer;
или
int i, j, k;
и
function MyFunc (): Integer;
или
int MyFunc();

мне лично не нравится синтаксис. т.к. код я чаще читаю чем пишу, а читаю я чаще всего целеноправленно, то лёгкость чтения для меня имеет преимущественное значение, а именно : при целеноправленном чтении кода я ищу имя, а не тип
---------------
это был один из примеров...

> XentaAbsenta ©   (28.08.08 17:55) [4]
> тьфу блин...
> мне лично не нравится синтаксис


твои проблемы

кто-нибудь мне может объяснить, почему в cpp нет слова abstract?

там еще много каких слов нет

> XentaAbsenta ©   (28.08.08 17:57) [6]
> кто-нибудь мне может объяснить, почему в cpp нет слова abstract?
>


а в foxpro нет слова uses...
и что?

> кто-нибудь мне может объяснить, почему в cpp нет слова abstract?


А в Delphi 7 шаблонов для списков нет...

Удалено модератором

Удалено модератором

Удалено модератором

Ega23 ©   (28.08.08 18:01) [9]

>
> А в Delphi 7 шаблонов для списков нет.


Меня это тоже раздражает, но к CPP имеет очень косвенное отношение.
--------

oldman ©   (28.08.08 18:00) [8]

>
> а в foxpro нет слова uses...
> и что?
>


Я не знаю foxpro.

> TUser ©   (28.08.08 17:59) [7]
>
> там еще много каких слов нет
>


и некоторые очень бы пригодились..

> кто-нибудь мне может объяснить, почему в cpp нет слова abstract?

Там абстрактные функции называются чистыми виртуальными функциями (pure virtual)

> Чем вам лично не нравится CPP?

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

А мне нравится С++.
Помойму вполне адекватный язык...
Позволяет сделать действительно красивые вещи...

Например с помощью шаблонов очень легко делаются потокобезопасные переменные...
Причем использование этих переменных ничем не отличается от использования переменных обычных.

> @!!ex ©   (28.08.08 18:54) [16]

Что, прям всё-всё нравится?

> [17] XentaAbsenta ©   (28.08.08 18:56)

MFC не нравится. Но это не часть С++, да и не пользуюсь я им.
Вобщем то язык отличается только синтаксисос и это дело привычки...
Пожалуй единственное что не нравится по сравнению с Delphi - это отсутствие override и inherited.

> Пожалуй единственное что не нравится по сравнению с Delphi


Система инклудов дурная, имхо. В Delphi любую костанту, переменную, тип, функцию ты найдёшь либо в текущем юните, либом в одном из перечисленных в uses.
В сях хуже.

Тут как-то пример приводили...


Чему будет равно f ?

> [20] Юрий Зотов ©   (28.08.08 19:05)

0 ?

> [20] Юрий Зотов ©   (28.08.08 19:05)

0 по идее?

А вообще это пример дурного кода. ИМХО.


> [19] Ega23 ©   (28.08.08 19:04)

в принципе это не такая уж и проблема, скорее дело привычки(ИМХО), да и инклюды имеет несколько преимуществ перед uses.

> в принципе это не такая уж и проблема, скорее дело привычки(ИМХО)


Про grep я в курсе. Но - неудобно.

> Юрий ©   (28.08.08 19:07) [21]

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

> @!!ex ©   (28.08.08 19:10) [22]

Конечно, это пример дурного кода. Даже ОЧЕНЬ дурного кода. Но если язык позволяет писать такой код, то это тоже очень плохо.

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

Хм... Почему?
Вроде бы ++ после переменной говорит о том, что она будет инкрементирована ПОСЛЕ того, как будет использовани ее значение. Нет?

> @!!ex ©   (28.08.08 19:22) [25]

Предположим, сначала вычисляется второй параметр. Тогда чему будет равен первый?

> [26] Юрий Зотов ©   (28.08.08 19:24)

Так он в этот момент еще не использован, значит не вычисляется.. разве нет?

Хотя ++i дает уже не предсказуемый вариант... согласен...

> @!!ex ©   (28.08.08 19:32) [27]

1. Вычисляется значение ВТОРОГО аргумента. Оно будет равно 1.
2. Переменная i УЖЕ использована (для вычисления значения второго аргумента) и поэтому будет инкрементирована СРАЗУ после вычисления выражения.
3. Первый аргумент получится равным 2.
4. Результат будет равен 1.

Если же сначала вычисляется ПЕРВЫЙ аргумент, то результат будет равен нулю.

> Мне интересны ваши мысли. Я прокомментирую по ходу


А мне неинтересны "походные" комментарии моих мыслей)
Явился тут, "панимаишь", какой-то ЗентаАбсента с откровенным запахом дилетанта, но при этом "профипонтами") ..

>  Чем вам лично не нравится CPP?
Отсутствием аналога "function of object", замороченностью с header-ами, отсутствием дельфийски-удобного редактора кода =)

> Отсутствием аналога "function of object"

А разве статический метод не аналог ?

>[16] @!!ex © (2008-08-28 18:54:00)
>Помойму вполне адекватный язык…
угу. с недосборщиком недомусора, да.

>[21] Юрий © (2008-08-28 19:07:00)
>0 ?
it depends. порядок вычисления операндов не специфицирован, постэффекты тоже. может быть func(1, 1), может func(2, 1).

>[25] @!!ex © (2008-08-28 19:22:00)
>Вроде бы ++ после переменной говорит о том, что она будет инкрементирована ПОСЛЕ
>того, как будет использовани ее значение.
угу. только компилер может решить, что второй операнд вычислить стоит первым. а ++ увеличивает значение сразу, а не после того, как всё выражение вычислено.

>[31] Asteroid © (2008-08-28 20:54:00)
>отсутствием дельфийски-удобного редактора кода =)
дада, это особенно! почему в g++ IDE не встроили?! %-)

зыж а мне вот нравится ровно одним: наличием Qt. за Qt я даже согласен простить цпп врождённый идиотизм.

---
All Your Base Are Belong to Us

> Чем вам лично не нравится CPP?

тем, что не компилируется в Delphi 7

> А разве статический метод не аналог ?
Не аналог, доступ к не-статическим полям мне никто не обеспечит; если же объявлять каждую требуемую переменную как volatile....уж лучше обойтись без function of object =)
В принципе это реализуемо, но....хотелось бы нативную поддержку.

> Сергей М. ©   (28.08.08 19:50) [30]
>
>
> > Мне интересны ваши мысли. Я прокомментирую по ходу
>
>
> А мне неинтересны "походные" комментарии моих мыслей)
> Явился тут, "панимаишь", какой-то ЗентаАбсента с откровенным
> запахом дилетанта, но при этом "профипонтами") ..


Присоединяюсь.
Добавлю, что если кому-то интересны чьи-то мысли и он хочет их узнать, то просьба должна быть более вежлива. Иначе это похоже на просьбу получить в челюсть.

> Asteroid ©   (28.08.08 21:19) [35]

Есть похожий аналог:

А теперь что мне не нравится в С++:

1. Система include`ов, отсутствие нормальной модульности.
2. Наличие нескольких темных моментов (типа приведенного примера с неустановленным порядком вычисления), которые дают возможность прострелить себе ногу. Но, вцелом, эти все страшилки больше  для примеров годятся. В реальных проектах на такое ни разу не напарывался.
3. Тяжкое наследие С.
4. Нет reflection.
5. Нет лямбд с замыканиями.
6. Нет *нормального* метапрограммирования. Всякие шаблонные извраты не в счёт.

Это так, навскидку. О том, что мне в С++ не нравится я могу говорить часами :)

А мне нравится С++.
Мне даже ABAP нравится.
И IL и С# нравится также.
И другие языки с которыми имел дело.

Обилием костылей, отсутствием базового класса, разношерстными строками, хидерами.
(а Дельфийский принцып объявления объектов в interface и initialization даже удобнее, чем объявление не отходя от кассы типа C#, т.к. все автоматизировано горячими клавишами)

Asteroid ©   (28.08.08 20:54) [31]
Отсутствием аналога "function of object",
В Managed c++, вроде, есть такое.

> GrayFace ©   (28.08.08 23:39) [40]


см. СBuilder.

> Чем вам лично не нравится CPP?


> XentaAbsenta ©   (28.08.08 17:55) [4]
>
> тьфу блин... я рассчитывал увидеть конкретные вещи, а не
> начинать новую священную войну.
>

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

> Германн  (29.08.2008 1:26:42)  [42]

> есть понятие "кривой". Но уж С++ сделан точно не на коленке.

Но кривой.

> oxffff ©   (28.08.08 23:32) [39]

:)
Фишка вот в чём - я, собственно, С++ программист. С++ сейчас - этой мой основной инструмент (в загашнике у меня ещё есть Дельфя и Шарп). Так что я могу долго распространяться о свойстах этого языка, его недостатках и достоинствах. Мастер должен знать свой инструмент :)

XentaAbsenta ©   (28.08.08 18:43) [14]
#define abstract
#define TVariant
Так можно весь VCL переписать ))

subj
Непривычность, а так язык как язык.

Чем вам не нравится delphi ?

Букв в название мало.

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

- это как это? Во первых соглашение о вызовах указывается в опциях командной строке(настройках проектах) - которые являются неотделимой частью проекта, во вторых явный квалификатор (Ms - __declspec())...
> 1. Вычисляется значение ВТОРОГО аргумента. Оно будет равно 1.
> 2. Переменная i УЖЕ использована (для вычисления значения второго аргумента) и поэтому будет инкрементирована СРАЗУ после вычисления выражения.
> 3. Первый аргумент получится равным 2.
> 4. Результат будет равен 1.
>

- а вот тут начинается бардак, потому как в Ms VC(как минимум с VC6) все пост..кременты - выносятся за выражение наглухо...


- выродится в



долго я глюк ловил с подобной конструкцией:


только что проверил(MsVC 2008 Express):


c оптимизацией, вырождается в

> Чем вам не нравится delphi ?


Говорю про семёрку, ибо более поздние не щупал:

1. Нет множественного наследования и шаблонов.
2. Нет статических и автоматических объектов. Идиома RAII не применима.
(Тончее применима, но через извраты с интервейсами).
3. Нет reflection.
4. Нет лямбд.
5. Нет метапрограммирования.

Синтаксис и прочее - фигня, дело привычки.

> han_malign ©   (29.08.08 10:39) [48]

Приводимые тобой выражения не корректны с точки зрения стандарта С++.
Легально только ОДНО изменение состояния объекта между двумя точками следования. А в простом выражении таких точки две - до и после.
Если же ты нарушаешь это правило, то можешь ловить UB и ругать злые компиляторы. Стандарт надо знать :)

> 1. Нет множественного наследования и шаблонов.
> 2. Нет статических и автоматических объектов. Идиома RAII
> не применима.
> (Тончее применима, но через извраты с интервейсами).
> 3. Нет reflection.
> 4. Нет лямбд.
> 5. Нет метапрограммирования.


И нахрен это все простому народу надо ?

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

А то развели creeping featurism и пальцы гнут, панимаешь

> Приводимые тобой выражения не корректны с точки зрения стандарта С++.
> ... и ругать злые компиляторы.

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

По начальному сабжу - до сих пор не могу понять какого хрена приоритет побитовых операции ниже логических - оно ж в таком порядке никуда, никак и никаким боком...
классика - (2 & dw == 2)
- хорошо хоть ругается...

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

Если на кону стоит производительность, то я предпочту либо delphi с inline-ами, либо чистый C, (точнее ограниченное подмножество, которое я называю C++ с классами). Тут сказывается тот факт, что C++ является наследником C. Почему я не использую высокоуровневые средства вроде перегрузки операций? Потому что потом приходится все равно выполнять работу компилятора и смотреть, а в состоянии ли компилятор раскрутить это выражение так, как я хочу. Получается что писать меньше, но проще написать лишние пару строчек чтобы ясно выразить свои намерения.

Если на кону стоит ООП архитектура, я выберу какой-нить скриптовый язык вроде Python. При этом если надо будет добавить новый атрибут, я не буду ломать себе голову над тем, в какое место в иерархии его надо воткнуть. Ну и вообще утиный полиморфизм гибче. Получение метаинформации про тип проще.

Если у меня будут математические вычисления, я возьму MATLAB. Никакая перегрузка операторов C++ не обеспечит мне настолько удобный синтаксис для операций с матрицами.

В случае, когда выполнить, проверить и протестировать большую части кода проблематично, я выберу что-нить вроде Delphi или Ada.

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

Вот, например, XML. Универсальное средство представления. Но текстовый DFM выглядит намного читабельнее. А если представить, как в XML будет представлена математическая формула, то волосы встают дыбом: TeX (LaTeX) намного приятнее в этом плане.

> han_malign ©   (29.08.08 11:44) [52]

Спорить не буду. Чем больше компилятор выдаёт варнингов - тем лучше.

> Чем больше компилятор выдаёт варнингов - тем лучше.

О! Тогда параноидальный режим выдачи предупреждений в gcc для тебя :)

> Игорь Шевченко ©   (29.08.08 11:19) [51]
> И нахрен это все простому народу надо ?

Простому народу это нужно.
Особенно учитывая, что я не занимаюсь чистым ООП, а больше склоняюсь к функциональному стилю с элементами ООП (или ООП с большой долей ФП).

> > 1. Нет множественного наследования и шаблонов.
Множественное наследование и шаблоны позволяют делать очень красивые с лаконичные решения.
Пример: недавно рефакторил большую бибилотеку в которой было дохрена функций вида "ConvertXIdToYId". Например, строковый идентификатор файловой системы в численный, да ещё в численный по двум разным системам идентификации. Плюс к этому ещё "GetReadableNameFor", а потом "GetMaxLabelLengthFor" и т.п.
Родилась идея - организовать справочные таблицы по этим данным. Таблицы на основе статических массивов. Фукнция выборки - 8 строк шаблонного кода.
Без шаблонов пришлось бы на КАЖДУЮ таблицу писать свои функции и смысла не было бы. А так - сократил код почти в 3 раза, да ещё убрал кучу несоответсвий между разнонаправленными функциями конверсии.
Это за шаблоны.

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

> > 2. Нет статических и автоматических объектов. Идиома RAII
> > не применима.
В языках без GC подобная идиома РЕЗКО сокращает количество утечек памяти.
Очень удобно для управления примитивами синхронизации. Настолько распространено в реальной жизни, что конкретные примеры приводить не буду.
В C#, языке с GC, кстати, идиома RAII тоже никуда не делась, только она там реализуется через специальную конструкцию языка. Использование внешних ресурсов, которые требуют явного закрытия, не может быть привязано к времени жизни объектов, ибо сборщик мусора ничего не гарантирует. Для таких объектов ввели спец. интерфейс IDisposable с методом Dispose. Т.е. сборщик мусора - это хорошо, но ЭТОТ мусор уберите за собой сами. Уборка "самим" показалась неудобной и ввели конструкцию using() {} - частный случай RAII.

> > (Тончее применима, но через извраты с интервейсами).
> > 3. Нет reflection.
> > 5. Нет метапрограммирования.
Пример из реального проекта - пишут наши хлопцы сериализатор. Что бы данные между процессами кидать. А как сериализовать структуру, если нет доступа к её метаинформации? Ответ - писать код сериализации/десериализации ручками. Муторно, громоздко, подвержено ошибкам. Наши пошли по другому пути - забабахали свой вариант IDL с кодогенератором. Т.е. реализовали свой вариант метаданных и метапрограммирования. Тока вариант не очень хороший и завязанный на использование в сборке нестандартных тулзов. А это минус. И мучаемся мы сейчас с их решениями, поскольку вынуждены сами синхронизировать описания в IDL и объявления в заголовках.  Было бы реализовано в самом языке - было бы гораздо лучше.

> > 4. Нет лямбд.
Лямбы + замыкания в С++ были бы ОЧЕНЬ ХОРОШИМ синтаксическим сахаром для написания классов-функторов, которые уже используются очень широко. Собственно, начиная с STL. Т.е. лямбы по сути уже используются, но как смоделированное программистом свойство, а не поддерживаемое языком напрямую.

Вот примеры из реальной жизни.

> О! Тогда параноидальный режим выдачи предупреждений в gcc
> для тебя :)

Типа того :)

Alkid ©   (29.08.08 12:14) [56]

Как я пишу на Delphi без всех этих синтаксических сахаров - ума не приложу. И вроде оно без ошибок получается.

> > > (Тончее применима, но через извраты с интервейсами).
>
> > > 3. Нет reflection.
> > > 5. Нет метапрограммирования.
> Пример из реального проекта - пишут наши хлопцы сериализатор.
>  Что бы данные между процессами кидать. А как сериализовать
> структуру, если нет доступа к её метаинформации? ...


А зачем структуру? Наследуем класс от TPersistent и сериализуем. Есть RTTI. Сериализация уже есть в VCL.

> Mystic ©   (29.08.08 12:35) [59]

Я туту немного смешал рассуждения по С++ и Дельфи :)
Прошу прощения.


> Игорь Шевченко ©   (29.08.08 12:31) [58]
> Как я пишу на Delphi без всех этих синтаксических сахаров
> - ума не приложу. И вроде оно без ошибок получается.

Да кто же спорит :)
Я не утверждал, что без этих свойств язык обязательно превратится в непользуемое убожище. Я и сам на дельфи программировал без этих "излишеств". Я тут лишь излагаю свои взгляды на то, каким должен быть тот или иной язык, что бы я смог на нём работать более продуктивно.
А вообще прекрасная иллюстрация к этой дискуссии - парадокс Блаба.

> Alkid ©   (29.08.08 13:01) [60]

Все ходы записаны:


> Alkid   (29.08.08 10:40) [49]



> 1. Нет множественного наследования и шаблонов.
> 2. Нет статических и автоматических объектов. Идиома RAII
> не применима.
> (Тончее применима, но через извраты с интервейсами).
> 3. Нет reflection.
> 4. Нет лямбд.
> 5. Нет метапрограммирования.


Пункт 3 тогда можно вычеркнуть?

> Пункт 3 тогда можно вычеркнуть?

Да.

> Чем вам не нравится delphi ?

Плюсов нет.

> Alkid ©   (29.08.08 12:14) [56]


> Mystic ©   (29.08.08 12:35) [59]


Да, RTTI в CPP слабенький, весьма, могли бы и расширить. Но меня более всего бесит синтаксис.
Asteroid ©   (28.08.08 20:54) [31]


Asteroid ©   (28.08.08 20:54) [31]
> Отсутствием аналога "function of object"

согласен на все сто


Asteroid ©   (28.08.08 20:54) [31]
> , замороченностью с header-ами, отсутствием дельфийски-удобного
> редактора кода =)
>

хз..., а насчёт редактора кода - посмотри на VCPP + VisualAssist
------------------------------

я уже год не притрагивался ни к Delphi ни к CPP (до этого 6 лет с D. и 1.5 года с C++), пишу на C# (2.0). Меня не покидает мысль о другом языке, я его за пивом как-то даже начал проектировать :) даже "Hello world" написал

мне не нравится двумя вещами

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

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

Странное дело, но например PHP (созданный по оброазу и подобию) мне нравится, а вот сам C++ как то не очень....  

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

> Мне кажется С++ ни там, ни там не блещет.

Программировать на C++ не прочитав предварительно Страуструпа или что-нить такое нельзя. А паскаль и PHP легко изучаются на ходу по мере необходимости.

а мне нравится

> Программировать на C++ не прочитав предварительно Страуструпа
> или что-нить такое нельзя


ох уж эти сказки...ох уж эти сказоцники...

а что вернет функция new при создании объекта "пустого" класса? то есть, класса без аттрибутов :)

> а что вернет функция new при создании объекта "пустого"
> класса? то есть, класса без аттрибутов :)

Указатель на новый объект этого пустого класса. :)

ну вроде бы как инстанцируемый размер - ноль. и по идее в результате Nil. или я ошибаюсь? мне просто интересно...

В такие объекты автоматом включается фиктивная переменная, поэтому размер не нуль.

> ну вроде бы как инстанцируемый размер - ноль. и по идее
> в результате Nil. или я ошибаюсь? мне просто интересно..

По стандарту sizeof пустой структуры/класса == 1.

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

Не знаю как вы... А в моих работах последних двух лет нет ни одного проекта, где использование перегруженных операторов не давало бы ощутимых примуществ. Как я уже здесь говорил, шаблоны+перегрузка операторов позволяет сделать потоко независимые переменные.
Вот как вы без перегрузки будете организовывать работу с безопасными переменными?




и т.д. каждое обращение к i - городои огород. Либо делаем класс, для каждого типа отдельный... Тоже проблему не решает...

На С++, с помощью шаблонов все сводится вот к такому виду:




Никаких огородов из критических секций. Никакий классов с функциями SetValue() GetValue().
Все чисто и красиво.

> На С++, с помощью шаблонов все сводится вот к такому виду:

Правильно, а потом

1) Количество таких переменных плодится и размножается, в результате вся выгода от многопоточности теряется: потоки последовательно ждут когда прочитается эта переменная.
2) Затруднен доступ к interlocked операциям.
3) Кроме того, код
i = i + 1;
не является потокобезопасным, как хотелось бы и интуитивно чувствуется. Что приводит к багам.

> 1) Количество таких переменных плодится и размножается,
> в результате вся выгода от многопоточности теряется: потоки
> последовательно ждут когда прочитается эта переменная.

А как это связано с реализацией?
Типа: "Давайте сделаем через жопу, тогда прогер будет избегать использования"?


> 2) Затруднен доступ к interlocked операциям.

В чем затруднение?


> 3) Кроме того, код
> i = i + 1;
> не является потокобезопасным, как хотелось бы и интуитивно
> чувствуется. Что приводит к багам.

Ну это уж звиняйте. Для этого ++ есть.

СPP люблю, наверное т.к. больше всего с ним работал и работаю на данные момент.

Меня очень напрягает CaseSensetive (ну не по человечески это, - по машинному) и знаки { и }  вместо begin . Каждый раз приходится напрягать зрение, и  искать их.  Система инклудов в минусе.

По сравнению с Delphi - сильно проигрывает в синтаксисе, если Delphi читаешь без напряга - как текст, то здесь иногда приходится приостанавливаться и делать микро паузы (сам синтаксис не логика работы).

> Ну это уж звиняйте. Для этого ++ есть.

Ты не чувствуешь проблему? Поставь замени +1 на +2 :)

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




или рассмотрим такой:




И что мы получим? temp вернет ссылку на наш класс/структуру. В другом потоке произойдет аналогичная ситуация. И после этого оба класса вызовут функцию do_something. Но имеено сам этот вызов (а не обращение к переменной temp) и хочется сделать потокобезопасным.

Если пользоваться только ++ и --, то вообще непонятно, зачем нужна ненужная критическая секция при чтении. Использовать interlocked операции и делу с концом.

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

В данном случае мне проще вручную вызывать Lock и Unkock (кстати, Unlock обычно идет в секции finally), чем пользоваться такой реализацией и постоянно вспоминать: ага, будет ли в этом конкретном случае это работать?

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

> Mystic ©   (29.08.08 14:58) [75]


> 1) Количество таких переменных плодится и размножается,
> в результате вся выгода от многопоточности теряется: потоки
> последовательно ждут когда прочитается эта переменная.

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

> По сравнению с Delphi - сильно проигрывает в синтаксисе,
>  если Delphi читаешь без напряга - как текст, то здесь иногда
> приходится приостанавливаться и делать микро паузы (сам
> синтаксис не логика работы).


А вобще наверное возьму пример с Владимира Кладова, и переквалифицируюсь на Delphi - удобнее он просто. :)

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

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


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


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

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

Насколько я помню - точку нельзя перегружать.
За то, что разжевали - спасибо! Есть над чем подумать.

Вообще у нас этот шаблон применяется в точках, где главное, чтобы переменная не ломалась.
Тоесть два потока:
ОДин только на чтение, второй - работа с переменной полная.
Соответственно надо дать гарантию, что первый прочитает не поломанную переменную. Что приведенный шаблон вполне себе сносно реализует... А вот что-то сложнее... Хорошо что здесь привел код... НЕ напорюсь, когда усложнять будем. :)

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

> [74] @!!ex ©   (29.08.08 14:52)

в данном случае Interlocked* функции рулят, например InterlockedExchange, InterlockedIncrement и т.д.

> в данном случае Interlocked* функции рулят, например InterlockedExchange,
>  InterlockedIncrement и т.д.


Ну хочется же через шаблоны. И чтобы любой тип...

> [87] Mystic ©   (29.08.08 16:52)

Ну так ничего не мешает приделать эти функции к шаблонам.

Удалено модератором
Примечание: Не ругайся

> >[82] Mystic © (2008-08-29 15:37:00)
> >можно ли нужным образом перегрузить операцию точка.
> нет. только ->


Значит скоро выйдет новый стандарт и будет всем счастье

>[90] Mystic © (2008-08-29 18:24:00)
угу. счастье ловить баги в реализациях стандарта разными компиляторами.

вообще, давно пора писать в резюме не «знаю C++», а «знаю m$ C++», «знаю borland C++», «знаю gnu C++», etc.

---
Do what thou wilt shall be the whole of the Law.

> [91] ketmar ©   (29.08.08 18:28)

Почему? Если писать нормально, то результат будет одинаковым на любом компиляторе.

> ketmar ©   (29.08.08 18:28) [91]

Ты преувеличиваешь.
Я на работе пишу код который должен собираться 5-6 разными компиляторами.
Так что о состоянии дел с совместимостью компиляторов я знаю. Совместимость между production quality решениями хорошая.

>[92] @!!ex © (2008-08-29 19:47:00)
>[93] Alkid (2008-08-29 20:10:00)
угу. пока не выходишь за subset, реализованый везде.

я уж молчу о том кайфе, который добавляют разные оптимизаторы — это занятная игра «что, где, когда» получается.

---
Understanding is not required. Only obedience.

А мне C# нравится :-)

А мне - девушки :)

> Alkid   (28.08.08 22:42) [37]
> typedef  void (A::*ClassAFuncPtr)() ; // тип указатель на функцию-член класса A
И имеем мы жесткую привязку к классу. Сойдет, но не всегда.

> XentaAbsenta ©   (29.08.08 13:20) [64]
> хз..., а насчёт редактора кода - посмотри на VCPP + VisualAssist
Глянем, спасибо.

> ketmar ©   (30.08.08 04:06) [94]
> угу. пока не выходишь за subset, реализованый везде.
Часто приходится? :)

> KilkennyCat ©   (30.08.08 14:02) [96]
>
> А мне - девушки :)


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

> ketmar ©   (30.08.08 04:06) [94]

Опять преувеличиваешь.
Мы на работе весьма полно используем С++ с его шаблонными наворотами и проч. Проблем не было. Самая большая проблема - разные варнинги на разных компиляторах.


> Asteroid ©   (30.08.08 14:02) [97]



> И имеем мы жесткую привязку к классу. Сойдет, но не всегда.

Это не большая проблема. А вообще - шаблоны, мой друг :)