Всю мою недолгою жизнь прогроммировал на Delphi, и вот в силу того что C++ Builder очень на дельфю смахивает , хотел спросить : как по вашему. что лучше?

На Delphi (то есть Object Pascal) я писал логический (семантический) язык программирования для обработки текстов на естественном языке. Бесило отсутствие полноценного множественного наследования. Поэтому если буду писать обновлённую версию, то только в стандартном С++

 

Голосовал соответственно за С++

На Delphi (то есть Object Pascal) я писал логический (семантический) язык программирования для обработки текстов на естественном языке. Бесило отсутствие полноценного множественного наследования. Поэтому если буду писать обновлённую версию, то только в стандартном  С++

 

Голосовал соответственно за С++

Там есть множественное наследование на уровне интерфейсов. Как в Java и .NET. Отсутствие истинного множественного наследования связано с принципиальным отличием объектной модели от C++: гомоморфной иерархией классов. На самом деле, необходимость в чем то другом, кроме множественного наследования на уровне интерфейсов - случай весьма исключительный. Может ты в ООП просто слаб, а вместо этого на язык пеняешь?

хммм

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

хммм

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

public поля - зло. Надо делать их private, а в интерфейсе объявлять методы/свойства для доступа к этим полям. Отсутствие множественного наследования куда больше не хватает для методов (приходится держать одинаковый код в разных классах), но и это уже далеко не проблема. AOP рулит, да и без него есть паттерны для решения этой проблемы.

Попытаюсь объяснить.

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

хммм 

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

public поля - зло. Надо делать их private, а в интерфейсе объявлять методы/свойства для доступа к этим полям. Отсутствие множественного наследования куда больше не хватает для методов (приходится держать одинаковый код в разных классах), но и это уже далеко не проблема. AOP рулит, да и без него есть паттерны для решения этой проблемы.

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

Насчет стабильности вы погорячились. У msvc куча проблем с шаблонами, приводящих к internal compiler error. ICC гораздо стабильнее.

 

И не забывайте, что gcc практически повсюду. Этим он и берет (помимо бесплатности).

иммется ввиду, естественно, стабильность кода.

внутренняя ошибка у msvc - в большинстве случаев означает нереализованную возможность и ни к какой стабильности отношения не имеет. кстати, проблемы с шаблонами можно пересчитать по пальцам.

 

ICC стабильнее? :lol: :lol: нуну

 

и ни про что я не забываю. я факты, которые почему-то редко озвучивают.

ICC стабильнее? :lol: :lol: нуну

У тебя есть сомнения в стабильности ICC?

Может объяснишь, что конкретно тебе не нравится в ICC?

Ошибетесь, msc++ не блещет ни скоростью icc ни вседоступностью gcc.

Насчет скоростей: http://rsdn.ru/article/devtools/perftest3.xml

Насчет вседоступности ничего утверждать не буду ;)

там не указаны ключи компиляции, что делает ценность статьи равной нулю.

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

neg eax

sbb eax, eax

and eax, 0FFFFFFFDh

add eax, 5

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

не исключено, правда, что в данном конкретном случае лучше нельзя сделать...

Сам то понял что сказать хотел? Я так, например, нет. Словесной окрошкой можно что угодно залажать.

 

Либо поясни.

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

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

Само поле (и метод для доступа к нему) придется объявлять несколько раз, естественно. Но разве это сложно?

Опрос не корректен. C++ или C++ Builder. Просто C++ рулит, Builder == гавно.

 

К тому же знаете почему Delphi так быстро компилит? Потому что он компилит не все! Если вы Resource Hacker'ом откроете ехешники Дельфи, то увидите все свойства формы, картинки в хексе и т.д. просто с текстовом формате. в RCData помойму

Редкостный бред.

Почему же это бред? Это правда жизни. Все, что надизайнишь на форме в Редакторе потом хранится вот так :

иммется ввиду, естественно, стабильность кода.

внутренняя ошибка у msvc - в большинстве случаев означает нереализованную возможность и ни к какой стабильности отношения не имеет. кстати, проблемы с шаблонами можно пересчитать по пальцам.

 

ICC стабильнее? :lol: :lol: нуну

 

и ни про что я не забываю. я факты, которые почему-то редко озвучивают.

Боюсь если пересчитывать пальцев не хватит -)

 

Но дело не в этом. В моем случае мы компилировали большую мультиплатформенную библиотеку. MSVC 6.0 с этой задачей справился. ICC 7/8 также. MSVC 7.1 нет. Разбираться и править чужой код сомнительное удовольствие. Поэтому учитываю более качественный оптимизатор ICC остановились на нем.

 

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

Ага. Щаз... Покажи мне компилятор, который старается перемежать команды :).

в отношении компиляторов я теоретик, т.е. интересуюсь только сферическими конями в вакууме ;)

Ага. Щаз... Покажи мне компилятор, который старается перемежать команды :).

практически любой оптимизирующий компилятор.

 

Боюсь если пересчитывать пальцев не хватит -)

список в студию.

 

В моем случае мы компилировали большую мультиплатформенную библиотеку. MSVC 6.0 с этой задачей справился. ICC 7/8 также. MSVC 7.1 нет.

а что именно произошло?

 

учитываю более качественный оптимизатор ICC

утверждение явно сомнительное

 

Если имеются в виду ошибки оптимизатора, то MSVC 6 они присутствуют.

присутствуют. но не в тех количествах как в ицц.

хм.. оказывается задачка решается более чем одним способом ;)

вот что как ее решил gcc:

        xorl    %edx, %edx
       testl   %eax, %eax
       sete    %dl
       leal    2(%edx,%edx,2), %edx

не возьмусь утвердать, что лучше, прокомментирует кто-нибудь?

 

PS. кстати, сразу видно, что xorl и testl могут выполняться одновременно

Изменено 3 сентября, 200421 г. пользователем Гость