Здравствуйте, Сергей Губанов, Вы писали:

СГ>А зачем вводить в язык оператор switch (или CASE) если его можно эмулировать с помощью цепочки if-else?
А в самом деле зачем? Если раз в год понадобится и на том спасибо. В прочем switch как и goto могут понадобиться при машинной кодогенерации. Например при генерации парсеров.

СГ>А зачем вводить в язык несколько циклов WHILE, REPEAT, FOR, LOOP если достаточно одного?
Вот я тоже не понимаю зачем? Мне for'а в С++ хватает за глаза. Ну иногда еще while использую. Но если бы его не было то я бы не растроился.

СГ>Это нужно для написания более оптимальных программ.
Чего чего??? Блин скажи это оптимизатору или в оберонах он отсутствует как класс? Ну если так тогда понятно.

СГ>В обероне WITH — это тот же самый CASE но только CASE — работает с перечислимыми типами, а WITH работает со внутренним тегом в котором зашифрована RTTI информация о динамическом типе полиморфной переменной. Теоретически (я не проверял) WITH должен работать быстрее чем цепочка dynamic_cast-ов, равно как swith теоретически должен работать быстрее цепочки if-else. Плюс к этому — большая структуризация текста программы.
Ты не кружи. Ты скажи на кой черт оно надо? У меня вобще ни разу жилания не возниколо воспользоваться подобной штукой.
В чем практический смысл этой конструкции? Я конечно понимаю что если конструкция есть то ее можно задействовать. Но водить в язык конструкции которые практически не востребованы...

Кстати объясни пожалуйста почему

  FOR i := 0 TO Self.p DO
    h.x := h.x + N[i] * Self.Pw[span - Self.p + 1].x;
    h.y := h.y + N[i] * Self.Pw[span - Self.p + 1].y; //тут точка с запятой нужна
    h.z := h.z + N[i] * Self.Pw[span - Self.p + 1].z  //А тут нет
  END;

В чем тайный смысл?

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

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

K_O>>>О, как вы неправы, создает и еще как! Для больших С++ проектов после появления IncrediBuilda это — самый больной вопрос. Линковка в течении 40 минут на современном компе — это далеко не фантастика. Более того, это один из главных тормозов в разработке сложных систем. Проверено на собственной шкуре.

K>>Да, механизм компиляции в С++ устарел до безобразия. С этим никто не спорит.
K>>Кстати а что мешает в таком крупном проекте заюзать dll?

K_O>Две вещи — требование, чтобы продукт работал одновременно на Windows и на Unix платформе и, как ни странно, сам С++.

не мешает.

K_O>Из DLL можно экспортировать только функции, но не объекты (расширения Microsoft здесь не годятся), а стало быть, для того, чтобы выделить некоторую общую часть, реализованную на С++ с использованием ООП в отдельную DLL, надо либо оборачивать все в С-шные функции wrapper'ы, либо реализовывать свой COM, потому как нету его на Иксах.

Я не понял причем тут расширения ms? Тот же gcc тоже спокойно позволяет экспортировать классы в динамических библиотеках (если это не так то stlport'овая dll собраная мной на mingw наверно мне приснилась ). И вообще кто мешает сделать не dll а обычную статическую библиотеку?

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

WH>В чем тайный смысл?

Тайный смысл в том, что ";" нужна для разделения инструкций, но END — это тоже разделитель, так сказать. Поэтому после последней команды, т.е. перед END точку с запятой ставить необязательно, но если сильно хочеться, то ставить разрешается, это не является ошибкой, а считается как пустой оператор, который ничего не делает.

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

WH>Здравствуйте, Сергей Губанов, Вы писали:

СГ>>А зачем вводить в язык оператор switch (или CASE) если его можно эмулировать с помощью цепочки if-else?

WH>А в самом деле зачем?


Про оптимизацию оператора switch по сравнению с обычной цепочкой if-else можно почитать, например. там:

http://www.wasm.ru/print.php?article=1009002

.... последовательная обработка всех операторов case крайне непроизводительная. Хорошо, если их всего четыре-пять штук, а если программист натолкает в switch сотню — другую case? Процессор совсем запарится, пока их все проверит (а по закону бутерброда нужный case будет в самом конце). Вот компилятор и "утрамбовывает" дерево, уменьшая его высоту. Вместо одной ветви, изображенной на рис. 30, транслятор в нашем случае построил две, поместив в левую только числа не большие двух, а в правую – все остальные. Благодаря этому, ветвь "666h" из конца дерева была перенесена в его начало. Данный метод оптимизации поиска значений называют "методом вилки", но не будет сейчас на нем останавливаться, а лучше разберем его в главе "Обрезка длинных деревьев"....

Ни что не мешает делать аналогичную оптимизацию для WITH по сравнению с цепочкой dynamic_cast-ов.

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

K_O>>Из DLL можно экспортировать только функции, но не объекты (расширения Microsoft здесь не годятся), а стало быть, для того, чтобы выделить некоторую общую часть, реализованную на С++ с использованием ООП в отдельную DLL, надо либо оборачивать все в С-шные функции wrapper'ы, либо реализовывать свой COM, потому как нету его на Иксах.

FR>Я не понял причем тут расширения ms? Тот же gcc тоже спокойно позволяет экспортировать классы в динамических библиотеках (если это не так то stlport'овая dll собраная мной на mingw наверно мне приснилась ).

Какая версия компилятора, платформа и, если можно, пример экспорта класса? Да, попутно, наследование поддерживается? Exceptions нормально снизу-вверх летают?

FR>И вообще кто мешает сделать не dll а обычную статическую библиотеку?
Ну дык статические библиотеки и линкуются в экзешник 40 минут.

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

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

K_O>Так что твой пример неудачный, с языками программирования общего назначения имеет мало общего.
Ну, если об этом говорить, то грех не вспомнить Джоэля с его дырявыми абстракциями. Это вообще всегда так: как только ты делаешь так, чтобы А выглядело как Б, то есть риск, что на самом деле кому-то несущественное отличие А от Б было как раз очень важным.

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

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Ну, знаете...., [...] Во время исполнения программы никаких шаблонов нет.

1. Во время исполнения программы есть только процессор и объектный код в памяти. Ну, ещё — внешние устройства.

СГ>Шаблоны позволяют меньше ручками по клавиатуре долбить.

2. Процедуры, функции, и прочее подобное предназначены для того же. И что из этого следует?

Здравствуйте, Сергей Губанов, Вы писали:

СГ>S1 — последовательность действий при которых x имеет тип T1
СГ>S2 — последовательность действий при которых x имеет тип T2
СГ>S3 — последовательность действий при которых динамический тип x не установлен.

СГ>Смысл: Если динамический тип полиморфной переменной x оказался T1, то выполняется S1 внутри которой x рассматривается как переменная типа T1; в противном случае если динамический тип полиморфной переменной x оказался T2, то выполняется S2 внутри которой x рассматривается как переменная типа T2; в противном случае выполняется S3.

Перестаньте позорить чистое имя Вирта наглым пренебрежением к LSP!!! За подобные последовательности в нормальном промышленном коде нужно обрывать руки и предавать анафеме до конца семестра.

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

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

K_O>>>Из DLL можно экспортировать только функции, но не объекты (расширения Microsoft здесь не годятся), а стало быть, для того, чтобы выделить некоторую общую часть, реализованную на С++ с использованием ООП в отдельную DLL, надо либо оборачивать все в С-шные функции wrapper'ы, либо реализовывать свой COM, потому как нету его на Иксах.

FR>>Я не понял причем тут расширения ms? Тот же gcc тоже спокойно позволяет экспортировать классы в динамических библиотеках (если это не так то stlport'овая dll собраная мной на mingw наверно мне приснилась ).

K_O>Какая версия компилятора, платформа и, если можно, пример экспорта класса? Да, попутно, наследование поддерживается? Exceptions нормально снизу-вверх летают?

Платформа win32 gcc version 3.2.3 (mingw special 20030504-1)
Exceptions летают нормально, наследование подерживается но не проверял и не вижу причин почему оно не должно работать. Классы экспортируются через #define _STLP_CLASS_EXPORT_DECLSPEC __attribute__((dllexport))

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

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

Так, каша... приплыли...
давай разгребать.

Ты — это кто? Разработчик библиотеки или ее пользователь?

Если первое, то все в твоих руках. И ты отдаешь себе отчет, что суть ТВОИХ алгоритмов не поменяется, назови ты их operator*() или MyltiplyByAnotherMatrix().

Если ты пользователь библиотеки (наверняка шаблонной), то прекрасно знаешь, какие типы ты подставляешь в аргументы шаблона. Что не так?

K_O>Пример, о котором я говорю, большинство требуемой информации от меня скрывает.
Можно подумать, что смена имени метода с operator*() на MyltiplyByAnotherMatrix() тебе что-то откроет.
Любишь ковыряться в исходниках — наздоровье! Насколько я знаю, любители ковыряться в исходниках меньше всего обращают свое внимание на название методов, ибо это тонкости.

K_O>Так что твой пример неудачный, с языками программирования общего назначения имеет мало общего.

Опять, ты с позиции разработчика библиотеки или с позиции пользователя? Если второе, то ты должен быть заинтересован в том, чтобы синтаксис прикладной части программы был МАКСИМАЛЬНО приближен к твоей предметной области.
Приведенный пример был из этой области.

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

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

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

V>Так, каша... приплыли...
V>давай разгребать.

V>Ты — это кто? Разработчик библиотеки или ее пользователь?
Я — программист, изучающий чужой код, коротый достался мне, скажем, по наследству. И вот я встречаю конструкцию:

f*=(a/x+5)*b-(y*c-d/5)/e-z;

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

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

FR>>>Я не понял причем тут расширения ms? Тот же gcc тоже спокойно позволяет экспортировать классы в динамических библиотеках (если это не так то stlport'овая dll собраная мной на mingw наверно мне приснилась ).

K_O>>Какая версия компилятора, платформа и, если можно, пример экспорта класса? Да, попутно, наследование поддерживается? Exceptions нормально снизу-вверх летают?

FR>Платформа win32 gcc version 3.2.3 (mingw special 20030504-1)
FR>Exceptions летают нормально, наследование подерживается но не проверял и не вижу причин почему оно не должно работать. Классы экспортируются через #define _STLP_CLASS_EXPORT_DECLSPEC __attribute__((dllexport))

Не совсем понял, этот подход portable? Gcc на Windows, Gcc на Solaris, Gcc на Linux и MSVC++ его одинаково нормально скушают?

К тому же я просил о другом: как в Dll объявить свой класс, как его экспортировать, с какими опциями компиляться и как использовать такую dll в екзешнике?

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, LaptevVV, Вы писали:

LVV>> уверяю, вирт не написал ни строчки — сам такой руководитель, знаю

СГ>Вот за себя и отвечайте.

СГ>Кстати, мог ли человек не написавший ни строчки написать вот это:
СГ>http://www.uni-vologda.ac.ru/oberon/infoart/proj0.htm
Внимательно прочитайте! Я говорю, что как руководитель при написании ПЕРВОГО ТРАНСЛЯТОРА с ПАСКАЛЯ он не написал ни строчки! А то, что он вообще не писал программ — я не утверждаю. Он много чего написал. Я Вирта, в отличие от некоторых товарищей на этом сайте, уважаю. Хотя бы за собственное мнение в программировании, и за вклад в наше дело.

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

D>А оно вам нужно, писать эти строчки? У вас, как я понимаю, другая задача. И (моё личное имхо), таких хороших преподавателей как вы, вообще ещё поискать нужно. Сам факт вашего постоянного участия в RSDN вызывает уважение.
Ну спаибо на добром слове!

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

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

D>>Кроме того, вопрос Дарнея касался немного другого. Если я его правильно понял, он засомневался, что в отсутствие Паскаля мы работали на Алголе-68 и предположил, что мы все работали бы на С (С++).

Д>Я говорил именно об этом. Роль паскаля в современной индустрии близка к нулю, так что его отстутствие не повлияло бы практически ни на что. Может быть только, еще больше склонило бы чашу весов в сторону C/C++
Ага! Значит роль Вирта — тож ноль! Он же ничего не создал толкового! Но уже один только факт, что мы спорим о нем — говорит о противоположном!
И Дейкстра тож нифига, кроме семафоров не оставил. А уж о грисе вообще можно не говорить, так же как о Хоаре. Или о Шелле — подуманешь, сортировку придумал, блин! Да фигня полная!
Так что ли?

А если дальше пойти, то вообще Ньютона можно с дерьмом смешать — у него сплошые ошибки, блин! Все неправильно!
Вот и подумайте. О себе, в первую очередь, а не о Вирте.

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

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

FR>>>>Я не понял причем тут расширения ms? Тот же gcc тоже спокойно позволяет экспортировать классы в динамических библиотеках (если это не так то stlport'овая dll собраная мной на mingw наверно мне приснилась ).

K_O>>>Какая версия компилятора, платформа и, если можно, пример экспорта класса? Да, попутно, наследование поддерживается? Exceptions нормально снизу-вверх летают?

FR>>Платформа win32 gcc version 3.2.3 (mingw special 20030504-1)
FR>>Exceptions летают нормально, наследование подерживается но не проверял и не вижу причин почему оно не должно работать. Классы экспортируются через #define _STLP_CLASS_EXPORT_DECLSPEC __attribute__((dllexport))

K_O>Не совсем понял, этот подход portable? Gcc на Windows, Gcc на Solaris, Gcc на Linux и MSVC++ его одинаково нормально скушают?

K_O>К тому же я просил о другом: как в Dll объявить свой класс, как его экспортировать, с какими опциями компиляться и как использовать такую dll в екзешнике?

Я в Unix'ах не разбираюсь, но под windows все распрастраненные компиляторы (vc, bcc, gcc) нормально подерживают экспорт — импорт классов(и даже конкретных специализаций шаблонов) из dll (конечно скомпилированную на vc dll нельзя использовать например в gcc, но собранные одним и тем же компилятором без проблем). Я не вижу причин почему в unix'ах это не должно работать, зачем тогда воообще искаженние имен придумали.

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

FR>Я в Unix'ах не разбираюсь,
В принципе, дальше можно не продолжать...
Но как же ж, блин, мы пофлеймить любим!

FR>но под windows все распрастраненные компиляторы (vc, bcc, gcc) нормально подерживают экспорт — импорт классов(и даже конкретных специализаций шаблонов) из dll (конечно скомпилированную на vc dll нельзя использовать например в gcc, но собранные одним и тем же компилятором без проблем).

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

FR>Я не вижу причин почему в unix'ах это не должно работать, зачем тогда воообще искаженние имен придумали.
К твоему сведению, нормальная поддержка компилятором gcc exceptions в многопоточных программах появилась относительно недавно, кажется, с версии 3.0. Это к вопросу: "Ну раз на винде работает, то почему на Иксах не должно."

А ты в курсе, что gcc не допускает forward declarations для enum'ов?

Список таких невинных "особенностей" можно продолжать еще долго.

Ну так как насчет простенького примера экспорта собственного класса? Мне просто любопытно на это взглянуть...

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

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

FR>>Я в Unix'ах не разбираюсь,
K_O>В принципе, дальше можно не продолжать...
K_O>Но как же ж, блин, мы пофлеймить любим!

ну не я же заявлял что C++ этого не позволяет в принципе

FR>>но под windows все распрастраненные компиляторы (vc, bcc, gcc) нормально подерживают экспорт — импорт классов(и даже конкретных специализаций шаблонов) из dll (конечно скомпилированную на vc dll нельзя использовать например в gcc, но собранные одним и тем же компилятором без проблем).

K_O>То есть, если часть группы использует другой компилятор, то ей все равно придется все перекомпилять? Да я все равно сомневаюсь, что такой эскпорт работает без глюков и side-эффектов.

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

FR>>Я не вижу причин почему в unix'ах это не должно работать, зачем тогда воообще искаженние имен придумали.
K_O>К твоему сведению, нормальная поддержка компилятором gcc exceptions в многопоточных программах появилась относительно недавно, кажется, с версии 3.0. Это к вопросу: "Ну раз на винде работает, то почему на Иксах не должно."

K_O>А ты в курсе, что gcc не допускает forward declarations для enum'ов?

нет, только какое это отношение имеет к экспорту классов?

K_O>Список таких невинных "особенностей" можно продолжать еще долго.

я сам могу такие списки составить, и не уверен что они будут подмножествами твоих
(перевод: в общем не стоит зря гнуть пальцы )

K_O>Ну так как насчет простенького примера экспорта собственного класса? Мне просто любопытно на это взглянуть...

Я же тебе привел уже пример STLPort, глюков не наблюдал.

Простеший пример:

#ifndef _DLL_H_
#define _DLL_H_

#if BUILDING_DLL
# define DLLIMPORT __attribute__((dllexport))
#else /* Not BUILDING_DLL */
# define DLLIMPORT __attribute__((dllimport))
#endif /* Not BUILDING_DLL */


class DLLIMPORT DllClass
{
  public:
    DllClass();
    virtual ~DllClass(void);

    int Method();
    virtual int VirtualMethod();

  private:

};


#endif /* _DLL_H_ */

def файл:

LIBRARY     LIB.DLL

EXPORTS
    _ZN8DllClass13VirtualMethodEv  @8   
    _ZN8DllClass6MethodEv          @1   
    _ZN8DllClassC1Ev               @2   
    _ZN8DllClassC2Ev               @3   
    _ZN8DllClassD0Ev               @4   
    _ZN8DllClassD1Ev               @5   
    _ZN8DllClassD2Ev               @6   
    _ZTV8DllClass                  @7

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

K_O>Я — программист, изучающий чужой код, коротый достался мне, скажем, по наследству. И вот я встречаю конструкцию:

K_O>

K_O>f*=(a/x+5)*b-(y*c-d/5)/e-z;
K_O>

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

Достаточно глянуть на типы.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Ни что не мешает делать аналогичную оптимизацию для WITH по сравнению с цепочкой dynamic_cast-ов.
Уф... Ты мне объясни на кой черт нужна эта цепочка if'ов вобще? Не надо мне объяснять как это работает. Поверь мне я это не хуже тебя знаю. Ты мне скажи зачем в язык введена конструкция которая не нужна.