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

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

Borland 6.0 (среда, номера его компилера не помню) — тоже, т.к. плохо работает с шаблонами и странно наследует статические члены.

Может в Линух податься? Там есть хорошие среды разработки?

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

P>Посоветуйте компилятор, не только наиболее близкий к стандарту, но и без ошибок.
Comeau C++

P>VC6 — не подходит. Не разрешает переопределение виртуальной функции, если меняется тип возвращаемого значения (со ссылки на базовый класс -> на ссылку на дочерний).

Это ошибка? Интересно. С каких пор?

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

P>Посоветуйте компилятор, не только наиболее близкий к стандарту, но и без ошибок.

P>VC6 — не подходит. Не разрешает переопределение виртуальной функции, если меняется тип возвращаемого значения (со ссылки на базовый класс -> на ссылку на дочерний).

P>Borland 6.0 (среда, номера его компилера не помню) — тоже, т.к. плохо работает с шаблонами и странно наследует статические члены.

P>Может в Линух податься? Там есть хорошие среды разработки?

Попробуй Intel Compiler 6.0, он поближе.
+ на некоторых задачах выигрыш по производительности до 100%
+ лучше работает с шаблонами
+ его понимет MS линкер
+ встаивется в Visual Studio

-/+ понимает большинство MS specific и MS несоответсвий стандарту
// типа for( int i =0 ; i < 100 ; i++ ){ }
// int i — ошибка

— из-за предыдущего о полном соотв. станд не может быть и речи
— есть свои глюки
— компилит раза в два дольше

P.S Можно скачать с сайта Intel-a, в где-то Inet-e есть кряка

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

P>Посоветуйте компилятор, не только наиболее близкий к стандарту, но и без ошибок.

P>VC6 — не подходит. Не разрешает переопределение виртуальной функции, если меняется тип возвращаемого значения (со ссылки на базовый класс -> на ссылку на дочерний).
Этого тебе ни один компилятор не позволит (по крайней мере стандартом это запрещено).

P>Borland 6.0 (среда, номера его компилера не помню) — тоже, т.к. плохо работает с шаблонами и странно наследует статические члены.
А можно подробнее про статические члены?

P>Может в Линух податься? Там есть хорошие среды разработки?
Там хорошо, где нас нет...

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

P>>Посоветуйте компилятор, не только наиболее близкий к стандарту, но и без ошибок.

Софта без ошибок не бывает

Kaa>Comeau C++

P>>VC6 — не подходит. Не разрешает переопределение виртуальной функции, если меняется тип возвращаемого значения (со ссылки на базовый класс -> на ссылку на дочерний).

Kaa>Это ошибка? Интересно. С каких пор?

С сентября 1998 года, если не ошибаюсь. Пункт стандарта 10.3.5

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

P>>VC6 — не подходит. Не разрешает переопределение виртуальной функции, если меняется тип возвращаемого значения (со ссылки на базовый класс -> на ссылку на дочерний).
B>Этого тебе ни один компилятор не позволит (по крайней мере стандартом это запрещено).

Неправда, это называется ковариантные возвращаемые типы, стандарт описывает это в пункте 10.3.5:

The return type of an overriding function shall be either identical 
to the return type of the overridden function or covariant with the 
classes of the functions. If a function D::f overrides a function B::f, 
the return types of the functions are covariant if they satisfy the 
following criteria:
— both are pointers to classes or references to classes
— the class in the return type of B::f is the same class 
  as the class in the return type of D::f or, is an unambiguous 
  direct or indirect base class of the class in the return type 
  of D::f and is accessible in D
— both pointers or references have the same cv-qualification and the 
  class type in the return type of D::f has the same cv-qualification 
  as or less cv-qualification than the class type in the return type of B::f.

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

P>Посоветуйте компилятор, не только наиболее близкий к стандарту, но и без ошибок.

Ну, как известно, совсем без ошибок нетривиальных программ не бывает...

P>VC6 — не подходит. Не разрешает переопределение виртуальной функции, если меняется тип возвращаемого значения (со ссылки на базовый класс -> на ссылку на дочерний).

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

Можешь также попробовать Intel C++ Compiler. В некоторых отношениях поближе к стандарту, чем MSVC++. Кроме того, очень неплохо оптимизирует, прозрачно встраивается в Visual Studio, бинарно совместим с MSVC++.

P>Может в Линух податься? Там есть хорошие среды разработки?

(Почти) все, что есть в Linux, есть и в Windows (www.cygwin.org (?), www.mingw.org), но меня gcc особо не впечатлил: слабая по сравнению с VC++ 7.0 или Intel C++ оптимизация, медленная по сравнению с VC++ 7.0 скорость компиляции, имеющиеся среды — imho — сильно уступают Visual Studio.

Попробуй Comeau C++ (www.comeaucomputing.com) — основан на самом близком на сегодня к стандарту EDG front-end версии 3.0, стоит всего $43.

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

P>VC6 — не подходит. Не разрешает переопределение виртуальной функции, если меняется тип возвращаемого значения (со ссылки на базовый класс -> на ссылку на дочерний).

Этот компилер действует в данном случае строго в соответсвии со стандартом С++. Да и вообще из тех каккие видел VC самый продвинутый и имеет самую лучшую среду разработчика. (Убью, кто не согласен).

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

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

P>>VC6 — не подходит. Не разрешает переопределение виртуальной функции, если меняется тип возвращаемого значения (со ссылки на базовый класс -> на ссылку на дочерний).

R>Этот компилер действует в данном случае строго в соответсвии со стандартом С++. Да и вообще из тех каккие видел VC самый продвинутый и имеет самую лучшую среду разработчика. (Убью, кто не согласен).

Товарищ, Вы комментарии читаете (См. выше комментарий Orangy), или у Вас свой стандарт (Судя по заявлениям, написанный фирмой Микрософт )?

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

P>>VC6 — не подходит. Не разрешает переопределение виртуальной функции, если меняется тип возвращаемого значения (со ссылки на базовый класс -> на ссылку на дочерний).

R>Этот компилер действует в данном случае строго в соответсвии со стандартом С++. Да и вообще из тех каккие видел VC самый продвинутый и имеет самую лучшую среду разработчика. (Убью, кто не согласен).

Не согласен, убивай
Однако точку зрения стандарта на это дело я уже изложил, так что спорить просто бессмысленно до тех пор, пока ты не приведёшь что-либо более конкретное. У VC достаточно много проблем во взаимопонимании со стандартном. Разводить тут флейм по этому поводу не намерен, прочитай официальные заявления Microsoft, потом возмущайся
http://support.microsoft.com/default.aspx?scid=KB;EN-US;q243451&amp;

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

P>Посоветуйте компилятор, не только наиболее близкий к стандарту, но и без ошибок.

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

GCC (халява), лучше бери последную версию, сейчас, помоему это 3.2.

GCC можеш под виндой использовать (см. CygWin).

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

O>Неправда, это называется ковариантные возвращаемые типы, стандарт описывает это в пункте 10.3.5:

Посыпаю голову пеплом...

Здравствуйте Vsevolod V.Burkutsky, Вы писали:

VVB>Попробуй Intel Compiler 6.0, он поближе.

Уже пробовал. Intel не подходит по той же причине, что и VC6. А пока у меня нет Itanium'а , от Intel нет большой выгоды, т.к. ускорение достигается почти только на "сплошных", без ветвлений, участках кода. Он циклы разворачивает, только жаль, что опция эта ставится для всего файла — в десять раз все циклы, например.

P>>VC6 — не подходит. Не разрешает переопределение виртуальной функции, если меняется тип возвращаемого значения (со ссылки на базовый класс -> на ссылку на дочерний).

Kaa>Это ошибка? Интересно. С каких пор?

уже тогда это было в драфте стандарта, насколько я помню.

You will always get what you always got
  If you always do  what you always did

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

Я, видимо, что-то пропустил. Не помню, чтоб я это где-то слышал ранее А может и слышал, но уж очень плотно забыл. Такие вот пироги. Истинно, век живи, век учись.

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

Замена возвращающего значения при перегрузке виртуальных функций нужна при реализации расширяемой библиотеки потоков и контейнеров. Если абстрактный поток-ридитель (Parent) умеет работать с объектами вида А, причем его операторы << >> возвращают Parent&, а дочерний поток (Child) реализует также работу с объектами вида Б или просто объединяет двух шаблонных абстрактных Parent для А и Б, то станут невозможными записи вида:
Child << A << Б, т.к. Child << A вернет Parent&, а тот не умеет работать с Б.

Кроме того, VC часто путается при определении размеров объектов для классов, переданных как аргументы шаблона. И это, видимо, не связано с выравниванием (или связано косвенно, но выравнивание byte все равно не помогает).
Просто, например, в модуле Picture.cpp объект Picture p весит 20 байт, а в модуле Template.cpp в инстанцированном шаблоне TTemplate<class T> : TTemplate<Picture> этот самый Т будет весить, например, 17.

Со статическими членами коряво работает Borland. Статические члены-классы в шаблонном классе определить не получается. Точнее не получается вызвать конструктор в модуле .cpp при повторном определении. Работать можно только со ссылками, тогда в .cpp приходится определять глобальный объект и устанавливать на него статическую ссылку в шаблоне. Или еще вот: при дебаггинге все статические члены с одинаковым именем в родственных классах выглядят как один (один и тот же) объект. К счастью, в самом коде это не так.

А вот насчет $43 за ComeauС. Я о нем раньше не слышал. Обязательно схожу по ссылке. И тогда такой вопрос: есть ли для него IDE и нельзя ли достать сам компилятор бесплатно? Все стремятся к бесплатному. За хорошую работу я с удовольствием заплачу, а вот если все окажется рекламой, то будет обидно.

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

P>VC — отвратительный компилятор.
P>Я больше чем уверен, что для подавляющего числа задач и при правильном проектировании он подходит идеально, только от этого не легче.

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

P>Замена возвращающего значения при перегрузке виртуальных функций нужна при реализации расширяемой библиотеки потоков и контейнеров. Если абстрактный поток-ридитель (Parent) умеет работать с объектами вида А, причем его операторы << >> возвращают Parent&, а дочерний поток (Child) реализует также работу с объектами вида Б или просто объединяет двух шаблонных абстрактных Parent для А и Б, то станут невозможными записи вида:
P>Child << A << Б, т.к. Child << A вернет Parent&, а тот не умеет работать с Б.

В данном случае можно обойтись и без ковариантных возвращаемых значений: сделай operator << невиртуальным и пусть он вызывает соответствующие виртуальные методы при необходимости.

P>Кроме того, VC часто путается при определении размеров объектов для классов, переданных как аргументы шаблона. И это, видимо, не связано с выравниванием (или связано косвенно, но выравнивание byte все равно не помогает). Просто, например, в модуле Picture.cpp объект Picture p весит 20 байт, а в модуле Template.cpp в инстанцированном шаблоне TTemplate<class T> : TTemplate<Picture> этот самый Т будет весить, например, 17.

(Не)работающий пример, please. Никогда не наблюдал в "нормальных" ситуациях. Обычно было связано с #pragma pack, макросами или подобной ерундой.

P>А вот насчет $43 за ComeauС. Я о нем раньше не слышал. Обязательно схожу по ссылке. И тогда такой вопрос: есть ли для него IDE и нельзя ли достать сам компилятор бесплатно? Все стремятся к бесплатному. За хорошую работу я с удовольствием заплачу, а вот если все окажется рекламой, то будет обидно.

В отношении соответствия стандарту и качества реализации работа хорошая, если не сказать больше — будь спок. В отношении среды, все просто: его можно встроить прямо в Visual Studio. В качестве back end он может использовать MSVC++, что, на мой взгляд, является еще одним плюсом, учитывая способности к оптимизации последнего.

Здравствуйте Павел Кузнецов, Вы писали:

ПК>В отношении соответствия стандарту и качества реализации работа хорошая, если не сказать больше — будь спок. В отношении среды, все просто: его можно встроить прямо в Visual Studio. В качестве back end он может использовать MSVC++, что, на мой взгляд, является еще одним плюсом, учитывая способности к оптимизации последнего.

Заманчиво.
А в среду от какой девстудии встраивается? Или в обе (6 и 7)?
И как его добывают на постсоветском пространстве? На сайте я что то ни слова бай ни слова скачай не нашел.

Уважаемый Павел Кузнецов.

ПК>Помимо соответствия стандарту надо еще учитывать другие факторы. У VC++ один из лучших на сегодня оптимизаторов, один из лучших показателей скорости компиляции, прекрасная среда, масса кода доступна для использования с VC++ и т.д.

Я и не спорю. Все прекрасно. Но не для тех целей.

ПК>В данном случае можно обойтись и без ковариантных возвращаемых значений: сделай operator << невиртуальным и пусть он вызывает соответствующие виртуальные методы при необходимости.

т.е. вы предлагаете сделать так?:

template <class T>
class Stream
{
 public:
 ...
 virtual void Put(T&);
 virtual void Get(T&);

 Stream& operator >> (T& t) { Get(t); return *this; }
 Stream& operator << (T& t) { Put(t); return *this; }
};

если так, то непонятно, зачем делать Put, Get виртуальными? И зачем вообще виртуальные функции... Собственно так я и делаю, только выглядит это странновато, поскольку приходится каждый раз заново описывать все операторы "туда-сюда".

А как в VC со ссылками на стандартные типы? У меня сейчас он не стоит. В Borland не работают операции Stream >> i, если i, к примеру, int, поскольку вместо ссылки оператору передается копия.

ПК>(Не)работающий пример, please. Никогда не наблюдал в "нормальных" ситуациях. Обычно было связано с #pragma pack, макросами или подобной ерундой.

К сожалению, код потерян. Могу только под честное слово сказать, что никаких макросов и pragma не было (кроме полученных от stdio).

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

ЮБ>Здравствуйте Павел Кузнецов, Вы писали:

ПК>>В отношении соответствия стандарту и качества реализации работа хорошая, если не сказать больше — будь спок. В отношении среды, все просто: его можно встроить прямо в Visual Studio. В качестве back end он может использовать MSVC++, что, на мой взгляд, является еще одним плюсом, учитывая способности к оптимизации последнего.

ЮБ>Заманчиво. А в среду от какой девстудии встраивается? Или в обе (6 и 7)?

Насчет встраивания: в MSVC++, как в 6, так и в 7 можно встроить любой компилятор. Достаточно сделать программу-драйвер, которая будет перекодировать входные опции, предназначенные для MSVC++ в опции для компилятора. В свое время я делал подобную программу для запуска из Visual Studio компиляторов bcc32 и gcc. Делали ли Comeau Computing подобную программу, я не знаю, думаю, что что-нибудь в этом духе где-нибудь должно быть. Главное же совместимость форматов для отладки. В этом отношении bcc32 и gcc не лучшие варианты. Т.к. Comeau в качестве back end использует MSVC++, это значительно улучшает ситуацию.

ЮБ>И как его добывают на постсоветском пространстве? На сайте я что то ни слова бай ни слова скачай не нашел.

Отож. Надо покупать.

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

ПК>>В данном случае можно обойтись и без ковариантных возвращаемых значений: сделай operator << невиртуальным и пусть он вызывает соответствующие виртуальные методы при необходимости.

P>т.е. вы предлагаете сделать так?:

P>template <class T> class Stream { <...>
P> Stream& operator >> (T& t) { Get(t); return *this; }
P> Stream& operator << (T& t) { Put(t); return *this; }
P>};
P>

P>если так, то непонятно, зачем делать Put, Get виртуальными?

Если нет необходимости в виртуальности Put, Get как таковой, проблема отпадает сама собой :-)

P>И зачем вообще виртуальные функции... Собственно так я и делаю, только выглядит это странновато, поскольку приходится каждый раз заново описывать все операторы "туда-сюда".

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

P>А как в VC со ссылками на стандартные типы? У меня сейчас он не стоит.

В порядке.

P>В Borland не работают операции Stream >> i, если i, к примеру, int, поскольку вместо ссылки оператору передается копия.

Works for me, sample, please.

P>К сожалению, код потерян. Могу только под честное слово сказать, что никаких макросов и pragma не было (кроме полученных от stdio).

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

Уважаемый Павел Кузнецов.

ПК>Works for me, sample, please.

Кода уж очень много, поэтому кое-что все-таки поскипано.
Вот:

class clStream
{
 protected:
 unsigned int Offset;

 public:
 clStream(): Offset(0) {};

 virtual unsigned int  getSize() = 0;

 int  getOffset() { return Offset; }
 void Back()      { if(Offset > 0) Offset--; }
 void Flush()     { Offset = 0; }
 bool isEndOf()   { return (Offset < getSize()); }
};

template <class Unit>
class clIn: virtual public clStream
{
 public:
 clIn<Unit>& operator >> (Unit& unit)    { unit = Get(); return *this; }
 virtual Unit& Get ()= 0;
};


template <class Unit>
class clOut: virtual public clStream
{
 public:
 clOut<Unit>& operator << (Unit unit) { Put(unit); return *this; };
 virtual void Put(Unit& unit)= 0;
};

template <class Unit>
class clInOut: virtual public clIn<Unit>,
               virtual public clOut<Unit>
{
 virtual Unit& Get ()= 0;
 virtual void Put(Unit& unit)= 0;
};


template <class Unit>
class clArray: virtual public clInOut<Unit>
{
 ...
 public:
 ...
 Unit& operator[](int i);

 // <Определения виртуальных функций, реализующих класс clInOut>
 unsigned int  getSize(void);
 Unit&     Get();
 void      Put(Unit& unit);
 // </Определ...nOut>
};

Собственно Put & Get определялись не для ковариантных типов, а чтобы получать данные встроенных типов не через Array >> i, а через i = Array.Get();
Иначе происходит передача копии и i сохраняет свое значение.

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

P>Посоветуйте компилятор, не только наиболее близкий к стандарту, но и без ошибок.

P>VC6 — не подходит. Не разрешает переопределение виртуальной функции, если меняется тип возвращаемого значения (со ссылки на базовый класс -> на ссылку на дочерний).

P>Borland 6.0 (среда, номера его компилера не помню) — тоже, т.к. плохо работает с шаблонами и странно наследует статические члены.

P>Может в Линух податься? Там есть хорошие среды разработки?

Покопайся на www.cuj.com, например: здесь ссылки на компиляторы

или здесь тоже много интересного.

Интересно и здесь.

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

P>Здравствуйте Vsevolod V.Burkutsky, Вы писали:

VVB>>Попробуй Intel Compiler 6.0, он поближе.

P>Уже пробовал. Intel не подходит по той же причине, что и VC6. А пока у меня нет Itanium'а , от Intel нет большой выгоды, т.к. ускорение достигается почти только на "сплошных", без ветвлений, участках кода. Он циклы разворачивает, только жаль, что опция эта ставится для всего файла — в десять раз все циклы, например.

Странно... У меня как раз была именно эта проблема в VC6. Тогда я ее решил

использованием компилятора Intel (тогда еще 5й версии). VC7 также поддерживает

ковариантное возвращаемое значение.

Код был примерно такой:

class Record
{
public:
    // ...
    virtual Record* Clone() const = 0;
    // ...
};

class CashRecord : public Record
{
public:
    // ...
    virtual CashRecord* Clone() const
    {
        return new CashRecord( *this );
    };
    // ...
};

Теперь моя очередь говорить "Странно..."

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

P>Здравствуйте Vsevolod V.Burkutsky, Вы писали:

VVB>>Попробуй Intel Compiler 6.0, он поближе.

P>Уже пробовал. Intel не подходит по той же причине, что и VC6. А пока у меня нет Itanium'а , от Intel нет большой выгоды, т.к. ускорение достигается почти только на "сплошных", без ветвлений, участках кода. Он циклы разворачивает, только жаль, что опция эта ставится для всего файла — в десять раз все циклы, например.

Сравнение компиляторов:
http://www.ixbt.com/cpu/insidespeccpu2000-compilers.shtml

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

ПК>>Works for me, sample, please.

P>Кода уж очень много, поэтому кое-что все-таки поскипано.

<... code skipped ...>

P>Собственно Put & Get определялись не для ковариантных типов, а чтобы получать данные встроенных типов не через Array >> i, а через i = Array.Get();
P>Иначе происходит передача копии и i сохраняет свое значение.

Подозреваю, что что-то ты все-таки перепутал. Вот такая, аналогичная, программа:

#include <iostream>

class clStream { };

template <class Unit>
class clIn: virtual public clStream
{
public:
  clIn<Unit>& operator >> (Unit& unit) { unit *= 10; return *this; }
};

template <class Unit>
class clOut: virtual public clStream
{
public:
  clOut<Unit>& operator << (Unit unit) { return *this; };
};

template <class Unit>
class clInOut: virtual public clIn<Unit>,
               virtual public clOut<Unit>
{
};

template <class Unit>
class clArray: virtual public clInOut<Unit>
{
};

int main()
{
  clArray<int> array;

  int i = 1, j = 2;
  std::cout << i << ", " << j << std::endl;

  array >> i >> j;
  std::cout << i << ", " << j << std::endl;

  return i + j;
}

как и ожидается, выдает:

1, 2
10, 20

Borland C++ 5.6 for Win32 Copyright (c) 1993, 2002 Borland

Здравствуйте Павел Кузнецов, Вы писали:

ПК>Подозреваю, что что-то ты все-таки перепутал.

Я попробую еще раз, но могу заранее сказать, что загвоздка была только с виртуальными функциями, а так тот же Array со своим оператором [] работает как надо.

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

Здравствуйте Павел Кузнецов, Вы писали:

ПК>>>В отношении соответствия стандарту и качества реализации работа хорошая, если не сказать больше — будь спок. В отношении среды, все просто: его можно встроить прямо в Visual Studio. В качестве back end он может использовать MSVC++, что, на мой взгляд, является еще одним плюсом, учитывая способности к оптимизации последнего.

ЮБ>>Заманчиво. А в среду от какой девстудии встраивается? Или в обе (6 и 7)?

ПК>Насчет встраивания: в MSVC++, как в 6, так и в 7 можно встроить любой компилятор. Достаточно сделать программу-драйвер, которая будет перекодировать входные опции, предназначенные для MSVC++ в опции для компилятора. В свое время я делал подобную программу для запуска из Visual Studio компиляторов bcc32 и gcc. Делали ли Comeau Computing подобную программу, я не знаю, думаю, что что-нибудь в этом духе где-нибудь должно быть. Главное же совместимость форматов для отладки. В этом отношении bcc32 и gcc не лучшие варианты. Т.к. Comeau в качестве back end использует MSVC++, это значительно улучшает ситуацию.

Это мысли вслух или реальный опыт использования? Если первое, то лично мне почему-то кажется, что с отладкой при использовании Comeau будут баальшие проблемы. Раз оно фронт-енд, то нагенерит малопонятный сишный код, для которого MSVC честно сделает дебаговскую информацию. Соответственно, при отладке получим доступ к этому промежуточному коду, а не к исходникам. Оно, конечно, лучше, чем ничего, но, IMHO, хуже, чем GDB aka Insight для gcc.

PS: Это только предположение, если кто-то юзал этот Камю, проясните ситуацию.

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

S>Это мысли вслух или реальный опыт использования?

"Мой дядя видал, как барин едал" :-) В свое время довелось немного попользовать в целях тестирования, но без связи с MSVC++.

S>Если первое, то лично мне почему-то кажется, что с отладкой при использовании Comeau будут баальшие проблемы. Раз оно фронт-енд, то нагенерит малопонятный сишный код, для которого MSVC честно сделает дебаговскую информацию. Соответственно, при отладке получим доступ к этому промежуточному коду, а не к исходникам.

По этому поводу говорят, что он генерит промежуточный код с директивами #line, поэтому MSVC++ честно делает отладочную информацию со ссылками на оригинальный код :-).

Вчера ComeauC удачно (без линковки) скомпилил следующее:

class A
{
 unsigned int i;
 public:
 A(int i)
 {
  this->i = i;
 }
};

template <class T> class Array;

template <class T>
class Memory
{
 Array<T>& innerArray;

 public:
 Memory(Array<T>& a): innerArray(a) {};
};


template <class T>
class Array
{
 static A a;
 Memory<T> Mem;

 public:
 Array(): Mem(*this) {};
};

template <class T>
A Array<T>::a(10);

Array<int> iArray;


template class Memory<int>;
template class Array<int>;

То есть, очень нужные вещи скомпилил. Маладца!

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

P>Здравствуйте Vsevolod V.Burkutsky, Вы писали:

VVB>>Попробуй Intel Compiler 6.0, он поближе.

P>Уже пробовал. Intel не подходит по той же причине, что и VC6. А пока у меня нет Itanium'а , от Intel нет большой выгоды, т.к. ускорение достигается почти только на "сплошных", без ветвлений, участках кода. Он циклы разворачивает, только жаль, что опция эта ставится для всего файла — в десять раз все циклы, например.

Если эта причина:

"VC6 — не подходит. Не разрешает переопределение виртуальной функции, если меняется тип возвращаемого значения (со ссылки на базовый класс -> на ссылку на дочерний)."

То это не так, IC 6.0 компилит:

class A
{
protected:
    int i;
public:
    A():i(0){}
    virtual A& Get(){ return *this; }
};

class B: public A
{
    B(){ i = 1; }
    virtual B& Get(){ return *this; }
};

Кстати, пример от 06.09.02 00:58 тоже

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

P>Посоветуйте компилятор, не только наиболее близкий к стандарту, но и без ошибок.

Если нужно обеспечить совместимость, то лучше всего gcc (www.mingw.org). Конечно, за нее придется платить понятно чем -- здесь уже писали об этом. Вполне работает такой вариант: отладочная версия пишется в gcc, а потом переносится на компилятор, заточеный под конкретную машину. Особых проблем на этом пути не возникает.

Хмм.. Круто. Стало быть, я плохо его к студии прикрутил.

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

P>Вчера ComeauC удачно (без линковки) скомпилил следующее:

P>
P>

P> ...пропущено...
P>

P>То есть, очень нужные вещи скомпилил. Маладца!

ну дык и Borland Builder6 и gcc 2.95.3-5 (cygwin special) это компилит ...

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

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

P>>VC6 — не подходит. Не разрешает переопределение виртуальной функции, если меняется тип возвращаемого значения (со ссылки на базовый класс -> на ссылку на дочерний).

R>Этот компилер действует в данном случае строго в соответсвии со стандартом С++. Да и вообще из тех каккие видел VC самый продвинутый и имеет самую лучшую среду разработчика. (Убью, кто не согласен).

Достиля, мля Где ты это в стандарте аидел