> 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... И т. д. и т. п. Но это уже другие языки :)