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

← →
XentaAbsenta © (2008-08-28 17:40) [0]

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

← →
Dennis I. Komarov © (2008-08-28 17:41) [1]

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

← →
oldman © (2008-08-28 17:45) [2]

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

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

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

← →
palva © (2008-08-28 17:46) [3]

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

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

← →
XentaAbsenta © (2008-08-28 17:55) [4]

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

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

← →
oldman © (2008-08-28 17:57) [5]

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

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

← →
XentaAbsenta © (2008-08-28 17:57) [6]

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

← →
TUser © (2008-08-28 17:59) [7]

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

← →
oldman © (2008-08-28 18:00) [8]

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

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

← →
Ega23 © (2008-08-28 18:01) [9]

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

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

← →
ketmar © (2008-08-28 18:12) [10]

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

← →
oldman © (2008-08-28 18:14) [11]

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

← →
ketmar © (2008-08-28 18:16) [12]

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

← →
XentaAbsenta © (2008-08-28 18:41) [13]

Ega23 © (28.08.08 18:01) [9]

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

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

oldman © (28.08.08 18:00) [8]

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

Я не знаю foxpro.

← →
XentaAbsenta © (2008-08-28 18:43) [14]

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

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

← →
Mystic © (2008-08-28 18:49) [15]

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

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

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

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

← →
@!!ex © (2008-08-28 18:54) [16]

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

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

← →
XentaAbsenta © (2008-08-28 18:56) [17]

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

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

← →
@!!ex © (2008-08-28 19:00) [18]

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

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

← →
Ega23 © (2008-08-28 19:04) [19]

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

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

← →
Юрий Зотов © (2008-08-28 19:05) [20]

Тут как-то пример приводили...
int func(int x, int y) { return x - y; } int i = 1; int f = func(i, i++);
Чему будет равно f ?

← →
Юрий © (2008-08-28 19:07) [21]

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

0 ?

← →
@!!ex © (2008-08-28 19:10) [22]

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

0 по идее?

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

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

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

← →
Ega23 © (2008-08-28 19:12) [23]

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

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

← →
Юрий Зотов © (2008-08-28 19:18) [24]

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

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

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

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

← →
@!!ex © (2008-08-28 19:22) [25]

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

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

← →
Юрий Зотов © (2008-08-28 19:24) [26]

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

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

← →
@!!ex © (2008-08-28 19:32) [27]

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

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

← →
@!!ex © (2008-08-28 19:32) [28]

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

← →
Юрий Зотов © (2008-08-28 19:40) [29]

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

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

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

← →
Сергей М. © (2008-08-28 19:50) [30]

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

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

← →
Asteroid © (2008-08-28 20:54) [31]

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

← →
palva © (2008-08-28 21:03) [32]

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

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

← →
ketmar © (2008-08-28 21:10) [33]

>[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

← →
VirEx © (2008-08-28 21:15) [34]

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

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

← →
Asteroid © (2008-08-28 21:19) [35]

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

← →
KilkennyCat © (2008-08-28 22:39) [36]

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

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

← →
Alkid (2008-08-28 22:42) [37]

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

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

class A { public: void f1(); void f2(); }; typedef void (A::*ClassAFuncPtr)() ; // тип указатель на функцию-член класса A void main() { A a; ClassAFuncPtr ptr = &A::f1; (a.*ptr)(); // вызываем f1 для a ptr = &A::f2; (a.*ptr)(); // вызываем f2 для a }

← →
Alkid (2008-08-28 22:50) [38]

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

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

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

← →
oxffff © (2008-08-28 23:32) [39]

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

← →
GrayFace © (2008-08-28 23:39) [40]

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

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

← →
oxffff © (2008-08-29 00:19) [41]

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

см. СBuilder.

← →
Германн © (2008-08-29 01:26) [42]

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

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

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

← →
Anatoly Podgoretsky © (2008-08-29 08:42) [43]

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

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

Но кривой.

← →
Alkid (2008-08-29 10:18) [44]

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

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

← →
Simpson © (2008-08-29 10:22) [45]

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

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

← →
Игорь Шевченко © (2008-08-29 10:29) [46]

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

← →
Anatoly Podgoretsky © (2008-08-29 10:30) [47]

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

← →
han_malign © (2008-08-29 10:39) [48]

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

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

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

долго я глюк ловил с подобной конструкцией:
if((*str++=="a") && (*str++== "b")) switch(*str){...}
только что проверил(MsVC 2008 Express):
int f = func(i, i++);
c оптимизацией, вырождается в
f = 0; i++;

← →
Alkid (2008-08-29 10:40) [49]

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

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

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

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

← →
Alkid © (2008-08-29 10:55) [50]

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

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

← →
Игорь Шевченко © (2008-08-29 11:19) [51]

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

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

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

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

← →
han_malign © (2008-08-29 11:44) [52]

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

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

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

← →
Mystic © (2008-08-29 11:55) [53]

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

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

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

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

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

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

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

← →
Alkid (2008-08-29 11:56) [54]

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

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

← →
Mystic © (2008-08-29 12:03) [55]

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

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

← →
Alkid © (2008-08-29 12:14) [56]

> Игорь Шевченко © (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. Т.е. лямбы по сути уже используются, но как смоделированное программистом свойство, а не поддерживаемое языком напрямую.

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

← →
Alkid © (2008-08-29 12:16) [57]

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

Типа того :)

← →
Игорь Шевченко © (2008-08-29 12:31) [58]

Alkid © (29.08.08 12:14) [56]

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

← →
Mystic © (2008-08-29 12:35) [59]

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

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

← →
Alkid © (2008-08-29 13:01) [60]

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

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

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

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

← →
Mystic © (2008-08-29 13:12) [61]

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

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

> Alkid (29.08.08 10:40) [49]

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

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

← →
Alkid © (2008-08-29 13:16) [62]

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

Да.

← →
palva © (2008-08-29 13:19) [63]

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

Плюсов нет.

← →
XentaAbsenta © (2008-08-29 13:20) [64]

> 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" написал

← →
Deep (2008-08-29 13:32) [65]

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

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

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

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

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

← →
Mystic © (2008-08-29 13:40) [66]

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

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

← →
clickmaker © (2008-08-29 13:41) [67]

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

← →
Игорь Шевченко © (2008-08-29 13:47) [68]

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

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

← →
Palladin © (2008-08-29 14:09) [69]

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

← →
Alkid © (2008-08-29 14:19) [70]

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

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

← →
Palladin © (2008-08-29 14:27) [71]

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

← →
PPC (2008-08-29 14:39) [72]

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

← →
Alkid © (2008-08-29 14:41) [73]

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

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

← →
@!!ex © (2008-08-29 14:52) [74]

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

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

var i_criticalSection:TCriticalSection; i:integer; begin i_criticalSection.Enter(); i:=1; i_criticalSection.Leave(); end; begin i_criticalSection.Enter(); Result:=i; i_criticalSection.Leave(); end;

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

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

syncproperty<int> i; { i = 1; } { return i; }

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

← →
Mystic © (2008-08-29 14:58) [75]

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

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

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

← →
@!!ex © (2008-08-29 15:04) [76]

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

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

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

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

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

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

← →
Tricky (2008-08-29 15:18) [77]

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

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

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

← →
Mystic © (2008-08-29 15:20) [78]

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

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

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

static syncproperty<int> i; i = some_func(i);

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

static syncproperty<class_xxx> i; temp.do_something();

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

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

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

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

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

← →
Mystic © (2008-08-29 15:22) [79]

static syncproperty<class_xxx> gopa; gopa.do_something();

← →
Alkid © (2008-08-29 15:22) [80]

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

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

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

← →
Tricky (2008-08-29 15:25) [81]

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

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

← →
Mystic © (2008-08-29 15:37) [82]

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

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

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

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

← →
@!!ex © (2008-08-29 15:43) [83]

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

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

← →
@!!ex © (2008-08-29 15:47) [84]

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

← →
Mystic © (2008-08-29 16:37) [85]

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

static syncproperty<int> i; ++i;

← →
Eraser © (2008-08-29 16:45) [86]

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

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

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

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

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

> >[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.

← →
Alkid (2008-08-29 20:10) [93]

> 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, реализованый везде.
Часто приходится? :)

← →
Tricky (2008-08-30 14:57) [98]

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

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

← →
Alkid (2008-08-30 15:04) [99]

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

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

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

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

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

ЧУВАКИ! вы просто жесть забыли сказать... В C++ нет слова with!!!
пример
C++
coolobject.items[i].childrens[j].method1;
coolobject.items[i].childrens[j].method2;
coolobject.items[i].childrens[j].method3;
coolobject.items[i].childrens[j].method4;
coolobject.items[i].childrens[j].val=i*k;
Object Pascal
with coolobject.items[i].childrens[j] do
begin
method1;
method2;
method3;
method4;
val:=i*k
end;

>[99] Alkid (2008-08-30 15:04:00)
>Самая большая проблема - разные варнинги на разных компиляторах.
везёт, значит. или разработчики компиляторов, наконец, сумели кое-как договориться. %-)

>[100] savyhinst © (2008-08-30 19:23:00)
>ЧУВАКИ! вы просто жесть забыли сказать... В C++ нет слова with!!!
а-а-а-а! голактеко опасносте!!!111 мы все умрём!111111

---
All Your Base Are Belong to Us

Но, в общем-то, никто не мешает объявить на месте короткообозванную переменную и присвоить ей coolobject.items[i].childrens[j]

← →
hinst (2008-08-30 20:19) [103]

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

>[103] hinst (2008-08-30 20:19:00)
складывается впечатление, что ты откуда-то из параллельного мира, где какой-то совсем не такой цпп, как тут у нас.

---
All Your Base Are Belong to Us

> А в си много лишнего

"Огласите пожалуйста весь список". Copyright. Все знают от куда.

← →
Alkid (2008-08-31 23:31) [106]

> ketmar © (30.08.08 20:01) [101]
> везёт, значит. или разработчики компиляторов, наконец, сумели
> кое-как договориться. %-)

Видимо сумели :)

> savyhinst © (30.08.08 19:23) [100]

Жжошь напалмом.

>[106] Alkid (2008-08-31 23:31:00)
>Видимо сумели :)
ненадолго. вот выйдет новый стандарт — и опять будет обычный разброд с шатаением. %-)

---
All Your Base Are Belong to Us

← →
MemoryLeak (2008-09-01 03:15) [108]

У Си++ на порядок лучше коммерческая поддержка, это и есть основное преимущество. Поддержка производителей железа и маштабная интеграция.
А у Delphi лучше общественная оценка в России, не факт что это плюс. Я бы не назвал её объективной.
...
Отступление...
Собирается совещание по поводу реализации предстоящего проекта: трудозатраты, бюджетирование, менеджмент.
Вариант выбирается - аутсорсинг, приглашаются представители фирмы и тех. консультанты.
Первое что слышно от Delphi-аутсорсеров:
1."Придётся переписать менеджер памяти. Лицензировать коммерческие версии комопнентов, чтобы не тратить время на разработку. :(( "
2. "Нет. Интеграция CVS это дополнительные расходы. Source Safe надо прикручивать, SVN и FreeVCS бесплатное говно и вообще чтобы было совместимо с MicroSoft надо немного поработать".
3."Что? Вы рассматриваете C# как альтернативу, ни в коем случае это страшный ужас."
4. "На какие задачи ориантирована ваша команда ? Любые системы, не предусматривающие real-time модели. Базы данных и клиент-серверные парадигмы - наш конёк".
5. "Почему не использовать 1C? реализация на освнове этого продукта обойдётся нам дешевле. В ответ обычно: ... ничего."
...
Резюме:
Когда вопрос касается денег, качества и сроков - всегда появляются сложности, которые не поддаются односложной оценке: "С++ лучше Delphi, давайте на нём делать".
А сравнение яызков - это не коммерческий подход, а любительский.

> [108] MemoryLeak (01.09.08 03:15)

> У Си++ на порядок лучше коммерческая поддержка

у C++ лучше вся поддержка. любая технология, старая или новая, в первую очередь описана на C/C++.

> А у Delphi лучше общественная оценка в России

это еще с каких пор? "программистов на делфи" не очень то жалуют, мягко говоря. само словосочетание звучит как ругательство )

НО у Делфи есть ряд приемуществ, помимо того, что я его знаю лучше, библиотеки и компоненты на Делфи намного понятнее сишных.
на C++ огромный соблазн как-либо извратиться, чем все активно и пользуются. каждая конкретная серьезная библиотека, сама по себе, написана отлично, но стиль написания у всех подобных библиотек совершенно разный (парадигма инклудов этому сильно способствует), а это сильно мешает.. голова то не резиновая.
в Делфи как-то все более унифицировано - в любой, грамотно написаной библиотеке можно разобраться довольно быстро и без особого труда, imho.

← →
MemoryLeak (2008-09-01 04:07) [110]

Eraser © (01.09.08 03:40) [109]

> это еще с каких пор? "программистов на делфи" не очень то
> жалуют, мягко говоря. само словосочетание звучит как ругательство
> )

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

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

Говорить Си++ программисту, что его профильный язык сложен, синтаксис неразборчив - это сравни тому, как сказать японцу, что у него очень сложный язык, а русский на порядок понятней.:)
Думаю, что это не очень весомый агрумент. Моё мнение.

← →
Alkid (2008-09-01 10:46) [111]

> ketmar © (31.08.08 23:35) [107]
> ненадолго. вот выйдет новый стандарт — и опять будет обычный
> разброд с шатаением. %-)

Да, сие возможно вполне.

> Eraser © (01.09.08 03:40) [109]

Грамотные библиотки прекрасно совмещаются в рамках одной программы.
И никого извращаться С++ не провоцирует. Просто как инструмент, предоставляющий большой спектр возможностей, он предоставляет так же и большое поле для того, что бы накосячить. Это, безусловно, повышает ответственность программиста и требования к его квалификации.

2 ketmar.

Кстати, почитал я про D.
Проект интересный, но уже кое-чем не нравится. На кой ляд отказываться от невиртуальных методов в классе?

> Проект интересный, но уже кое-чем не нравится. На кой ляд
> отказываться от невиртуальных методов в классе?

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

← →
Alkid (2008-09-01 12:44) [114]

> Mystic © (01.09.08 12:11) [113]
> Насколько я видел реализации, там где очень критичны несколько
> тактов, там обычно не используется никакого ООП. А если
> нет требования к производительности, то проще все унифицировать,
> имхо.

Не, тут дело не в оптимизации. Я сам хочу решать, какие функции должны быть переопределяемы в наследниках, а каике - нет.

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

>[112] Alkid © (2008-09-01 11:17:00)
я тоже не в восторге. но от цпп я ещё менее в восторге. %-)

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

← →
Alkid (2008-09-02 11:01) [116]

> ketmar © (01.09.08 23:40) [115]

Фиг его знает.
Цели у D хорошие, только, ИМХО, они куда-то не туда пошли. (см. 114).
И ещё нюанс: пока всё же С++ выигрывает у D как минимум в одном - он уже реально используемый инструмент.

ЗюЫю: А вообще язык моей мечты (какой точно, я не знаю ещё :)) похож на Пролог :)

>[116] Alkid (2008-09-02 11:01:00)
ну, игрушки на D уже пишут. у меня вот куча bullet hell"ов на нём. %-)

а у меня язык мечты ещё проще: русский. %-)

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

← →
Alkid (2008-09-02 12:51) [119]

> ketmar © (02.09.08 11:43) [117]

> Virgo_Style © (02.09.08 12:00) [118]

+1
Ещё лучше, что бы компьютер после пары неопределённых артиклей сам догадывался, что от него хотят и бежал за пивом :)

>[119] Alkid (2008-09-02 12:51:00)
ну тогда уже доведём до идеала — чтобы догадывалось ещё до того, как скажешь. даже до того, как чётко мысль оформишь. только собрался о чём-то подумать, а это уже сделано (на всякий случай: гусары, тс-с-с-с! %-)

---
Understanding is not required. Only obedience.

← →
Alkid (2008-09-02 21:14) [121]

> ketmar © (02.09.08 20:37) [120]

Нет. Вот как раз на всякий случай такого не надо. А то только теоретически подумаешь, а потом уже оправдываться придется :) А то мало ли, что я там подумаю :)

>[121] Alkid (2008-09-02 21:14:00)
а вот будет приучать к дисциплине в ментале. а то сегодня ты подумал, что соседа неплохо бы по голове оприходовать, а завтра — что родная Партия неверным курсом идёт!

---
Understanding is not required. Only obedience.

> [121] Alkid (02.09.08 21:14)

Есть такая книжка:
"StarCraft: Крестовый поход Либерти"
Так один из героев - солдат-призрак, способный читать мысли...
Читая книжку понимаешь, что не хочешь уметь читать мысли. :?)

Чем вам лично не нравится CPP? Найти похожие ветки