Здравствуйте, Cyberax, Вы писали:

C>#import — это решение аля-MS. Правильное С++ное решение — это Comet, он тоже генерирует обложки по TLB, причем обходится без свойств и __uuidof.

Без исключений он тоже обходится?

Здравствуйте, kedik, Вы писали:

K>Вот давай практический пример: ты упомянул, что при выполнении своих конрактов, ты говоришь "эта лопата подходит, а эта нет".
K>Но ты никак не упомянул ДЛЯ ЧЕГО подходит.

Для решаемых задач конечно.

K>Вот тебе допустим удобнее под Win и на .NET... а у клиента все под Solaris и на С++...

С легаси кодом как раз всё понятно. Если не стоит задача его переписать, то если он работает, то какой смысл его трогать.

K>И ты хочешь сказать что ты прийдешь и так авторитетно заявишь "мол, выбрасывайте все, будем ставить Win c .NETом" ?

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

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Cyberax, Вы писали:

C>>В С++ с этим просто — плюешь на стандартную строку и используешь вместо нее свою любимую. Какие проблемы?

IT>Почему тебе не приходит в голову переопределять в C++, например, тип double?

Мне приходилось подменять double своим специализированным классом.

IT wrote:
> C>#import — это решение аля-MS. Правильное С++ное решение — это Comet,
> он тоже генерирует обложки по TLB, причем обходится без свойств и __uuidof.
> Без исключений он тоже обходится?
Наоборот, превращает HRы в исключения и автоматически добавляет
поддержку ISupportsErrorInfo к серверным классам.

Здравствуйте, FR, Вы писали:

IT>>Почему тебе не приходит в голову переопределять в C++, например, тип double?

FR>Мне приходилось подменять double своим специализированным классом.

В каждом новом приложении? И long наверное приходилось подменять, и short, и int? И так в каждом новом проекте?

IT wrote:

> C>В С++ с этим просто — плюешь на стандартную строку и используешь
> вместо нее свою любимую. Какие проблемы?
>
> Почему тебе не приходит в голову переопределять в C++, например, тип double?
А какие проблемы?
При желании и это можно сделать — переопределяешь ариф. операторы, при необходимости — оператор приведения к double,
делаешь имплицитный конструктор из double. И получаешь тип, который по поведению полностью соответствует double, но,
например, с очень высокой точностью.
Полиморфность, правда, не получится... но generic programming может помочь обойти и эту проблему.

Однако, у double (как и у int, void* и иже с ними) есть вполне веское оправдание — обычно он непосредственно
поддерживается процессором, оптимизируется компилятором, а значит работает относительно быстро. Что не скажешь о
строках. То бишь в С/С++ все примитивные типы (POD) — типы, с которыми способна работать "имплементация машины Тьюринга"
непосредственно. Вот когда изобретут другие железки, вот тогда тогда и задумаются о других примитивных типах. Какого
чёрта пытаются строку приплести к примитивным типам — мне совершенно не понятно.

IT wrote:
> C>В С++ с этим просто — плюешь на стандартную строку и используешь
> вместо нее свою любимую. Какие проблемы?
> Почему тебе не приходит в голову переопределять в C++, например, тип double?
Я это делал — добавлял класс для long double (который MSом не
поддерживается).

>> > Зачем тебе ссылка на свойство?
> C>Для передачи в качестве out-параметра, например.
> out-параметр — это серьёзный звоночек, говоряший о кривизне архитектуры.
Ага, кончено.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, kedik, Вы писали:

K>>Вот давай практический пример: ты упомянул, что при выполнении своих конрактов, ты говоришь "эта лопата подходит, а эта нет".
K>>Но ты никак не упомянул ДЛЯ ЧЕГО подходит.

IT>Для решаемых задач конечно.

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

K>>И ты хочешь сказать что ты прийдешь и так авторитетно заявишь "мол, выбрасывайте все, будем ставить Win c .NETом" ?

IT>Я как раз и пытался тебе объяснить, что я, во-первых, не скажу выбрасывайте всё, а, во-вторых, будем ставить то, что лучше подходит для текущей задачи. А дальше с комом в горле и скупой слезой отметил, что плюсы для моих задач, что-то пока применять не получается и по их текущему состояния вряд-ли когда-либо получится.

Ну значит, пардон, видимо я недопонял

Здравствуйте, IT, Вы писали:

IT>out-параметр — это серьёзный звоночек, говоряший о кривизне архитектуры.

С чего это вдруг?

bool
    get_current(Face *&f);

bool
    get_current(Edge *&e);

bool
    get_current(Shell *&e);

void test()
{
    Face *f;
    if ( get_current(f) )
    {
        // понеслась
    }
}

или я должен сделать функцию которая возвращает Object* а дальше dynamic_cast-om развлекатся? Или целое семейство наплодить get_curr_face, get_curr_edge, ...

Kluev wrote:

> или я должен сделать функцию которая возвращает Object* а дальше
> dynamic_cast-om развлекатся? Или целое семейство наплодить
> get_curr_face, get_curr_edge, ...
Я бы так и написал:

Face *f = get_current_face()
if(f)
{
  // понеслась
}

чем плохо?

kan_izh wrote:

> чем плохо?
Плюс позволяет писать:

mud_on_your(get_current_face());

Здравствуйте, kan_izh, Вы писали:

_>Я бы так и написал:
_>

_>Face *f = get_current_face()
_>if(f)
_>{
_>  // понеслась
_>}
_>

_>чем плохо?

Такой код сложнее с шаблонами подружить. Если название get_current перегружено для разных типов, то шаблоны можно использовать для уменьшения copy-paste:

template< class T >
void do_something_usefull() {
  T * value;
  if( get_current( value ) ) {
    ... /* Обобщенный код обработки Face, Edge и пр. */...
  }
}
...
do_something_usefull< Face >();
...
do_something_usefull< Edge >();

Здравствуйте, Cyberax, Вы писали:

>> C>Свойства — это не более чем простенький синтаксический сахар.
>> Да, тысячу раз да! Почти все конструкции современных ЯП — это
>> синтаксический сахар.
C>Далеко не все.

Почти все! Для реализации любой логики достаточно одного оператора сравнения и goto.

C>На Лиспе как раз сахаром при желании можно обожраться по полной.

В Лиспе его вообще практически нет. Другое дело, что там есть макросы с помощью которых он делается. Вот это путь и видится мне перспективным.

>> C> Причем сахар с солью (как взять ссылку на свойство?).
>> Ты еще ссылку на конструктор возьми или на пространство имен.
C>Понимаешь, свойство выглядит и ведет себя как член класса. На член
C>класса я могу взять ссылку (в С++).

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

Собственно как-то раз я делал класс эмулирующий ссылку на свойство. Знаешь чем это закончилось? Он на фиг никому не упал. Ты можешь воспользоваться поиском и найти его код.

Здравствуйте, FR, Вы писали:

FR>Нет не задвинул. У меня VC (с правильными ключиками) быстрее.

Ключи в студию.

ЗЫ

Того что GCC по полной обосрался — это как бы ничего не говорит? Тут ведь много трепачей ходит рассказывающих о мифической медленности дотнета. Может им на основании этого С++ хот разок по критиковать?

Здравствуйте, FR, Вы писали:

FR>Работает, но по нему только выходит только то что С++ уступает N только в compile time, а в run time наоборот
FR>N уступает C++, так что слово слили здесь неуместно.

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

Re: [Benchmark] Еще раз про Аккерман на разных языках

Автор: VladD2
Дата: 05.06.06

Здравствуйте, FR, Вы писали:

FR>Работает, но по нему только выходит только то что С++ уступает N только в compile time, а в run time наоборот
FR>N уступает C++, так что слово слили здесь неуместно.

Это банальная подтасовка результатов. При этом VC вычислит промежуточные результаты во время компиляции. Эдак Немерел всегда будет победителем, так как любое статическое вычисление на нем можно частично или полностью предвычислить.

Здравствуйте, Left2, Вы писали:



L>Отвечу в твоём же духе — а как я тебе буду приводить эти мэппинги для языка которого я не знаю и вжисть на нём двух строчек не написал?

Тогда советую изучить хоть один язык на котором можно сделать не кривые маниги.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Складывается впечатление, что кому-то крепко стукнуло в башку сделать Java из C++. А из этого мало что хорошего выходит, как правило...

ГВ>Впрочем, это моя неверифицируемая имха.

Так к сведению... КОРБА разрабатывалась приемущественно на С++ (как и КОМ в прочем), а биндинг для Явы был сделан значительно позже.

Ну, и сделать бейсбольную биту из гнилово дерева не получится не смотря на прямолинейность перво.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Вопрос: какие именно строки? В турбо-паскале, вон, были строки: до 255 символов. Это такие, как надо, или не такие? А сейчас какие они должны быть? CORBA-like, Java-like, C#-like? 16- или 32-битовые символы? Что делать с тем софтом, который уже написан на C и использует const char* ?

Мне тебе рассказать о принципах проектирования?


VD>>Это такие же вопросы как "Почему не добавить свойства? Они же никому не помешали бы." или "кому помешали бы функциональные типы?". На эти вопросы есть только отбрехи фанатов С++ и комитета. Отбрехи эти пахнут маргинальностью и старперством.

ГВ>А требования дать свойства любой ценой пахнут непониманием неоднозначности ответа на это вопрос.

Про цену, плиз, по подробнее. А то ваши слова сами пахнут не очень приятно.

Здравствуйте, kan_izh, Вы писали:

_>Kluev wrote:

>> или я должен сделать функцию которая возвращает Object* а дальше
>> dynamic_cast-om развлекатся? Или целое семейство наплодить
>> get_curr_face, get_curr_edge, ...
_>Я бы так и написал:
_>

_>Face *f = get_current_face()
_>if(f)
_>{
_>  // понеслась
_>}
_>

_>чем плохо?

Тем что в программе используются несколько классов Face (с разной функциональностью): CFace, QS_Face, QF_Face, это как тогда функции называть? А так get_current и никаких лишних сущностей и мозговых напрягов. Перегрузка лучше чем новый символ.

Вообще С++ хороший язык, но логика разработчкиов stl слегка напрягает. Добавляют разные ненужные фичи, а до сих пор не могли сделать перегруженные функции для функций strlen, wcslen. т.е.
str_len(const char*) и str_len(const wchar_t*);

Имхо, уже давно созрела необходимость в низкоуровневевом языке типа С++ разрабатываемом сообществом, а не комитетами. Вот в линукс кернеле юзают нестандартные расширения gcc и никто не напрягается. Давно бы уже сделали бы форк g++ и послали бы комитет лесом. Все равно компилеры м-ду собой несовместимы. нафига тогда приддерживатся иллюзорных бесполезных стандартов