from VC to GCC

вот захотел скомпилить свои старые проги, написанные на VC, на GCC. понятное дело, столкнулся с проблемами:
1. с шаблонными классами всё довольно муторно. вызов родиеля в шаблонном классе:

Код (Text):

1. template <typename t> class CChildT : public CBaseT<t>
2. {
3.  CChildT(int x) : CBaseT(x) {} // vc компилит, gcc требует так: CChildT(int x) : CBaseT<t>(x) {}
4. }

или обращение к переменной родителя:

Код (Text):

1. CBase<t>::m_x = 3;

вместо

Код (Text):

1. m_x = 3;

2. нет ключевого слова __super - довольно неудобно.

я всё это к чему - хотелось бы писать универсальный код - не привязываться к конкретному компилятору.

 

gcc 3.4.5
vc 2008

может можно gcc как-то научить понимать хотябы __super. я уже не говорю о __intn и прочих приблудах.

 

Ну тройка тоже кхе кхе. У студии много расширений, но что мешает более строго придёрживаться стандарта?

 

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

 

вот ещё столкнулся с проблемой компиляции x64 прог под винду. под линь есть куча версий - и для x32 и для x64. под вынь же бинарники x64 найти не могу вообще (

 

cupuyc

Бинарники кого???

 

Нелогично. А если так?

Код (Text):

1. template <class T>
2. class Z
3.   : public B<T>, public B<int>
4. {
5. public:
6.     Z(int i) : B<T>(i), B<int>(i) {}
7. };

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

Вообще, имхо ужос из бездны... ты еще о __property пожалей

 

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

Во-первых, я не объявлял множественное наследование, следовательно, компилятор может сообразить и просмотреть мемберы родителя. Во-вторых, при множественном наследовании, если есть одинаковые функции, то наследуются в первую очередь от того класса, который в списке идёт первым. для полей можно было-бы сделать также. так что, не вижу здесь большой проблемы. но каждый раз в дочернем классе писать CBase<t>::m_a = CBase<t>::m_b - CBase<t>::m_c - как-то коряво.

ну, извините, привычка. а вообще удобно. да и что в нём такого? безобидная директива. зато код, типа:

Код (Text):

1. void CChild::func(int a)
2. {
3.  return __super::func(a);
4. }

сразу понятен, а вот код

Код (Text):

1. void CChild::func(int a)
2. {
3.  return CBase::func(a);
4. }

тут ещё нужно сообразить - наследуется ли CChild от CBase или там идёт вызов статического метода...

 

Я наивный всегда полагал, что будет неоднозначность.

 

а почему тогда важен порядок наследования?

 

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

 

Это чревато багами, намного правильнее явно ввести в простанство имён производного класса именованные члены базового, с помощью using объявления.

Код (Text):

1. class Derived : public Base1, public Base2
2. {
3. public:
4.   using Base2::foo;
5. };

 

Код (Text):

1. Бинарники кого???

бинарники компилятора gcc, умеющего собирать код под win х64. с сорцами возиться я не имею особого желания.

 

cupuyc

Пользователей gcc не так-то легко обидеть они закаленный народ особенно типа меня, которых судьба до сих пор вынуждает юзать 3-ю версию

Это не так, как уже указал Booster.

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

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

Код (Text):

1. class D : public B
2. {
3.     typedef B super;
4.     void f();
5. };
6.  
7. vod D::f()
8. {
9.     super::f();
10. }

Другое дело, что я не вижу в этом смысла.

А какая разница? Что есть, то и вызывается.
Кстати, с __super тоже может быть вызвана статическая функция, что имхо еще менее наглядно.