Функция

[Пепел Феникса]

Вы путаете разные вещи. Код, не соответствующий стандарту, является некорректным.

код не соответствующий стандарту, является некорректным относительно стандарта, не надо подменять понятия.
но код намеренно не соответсвующий стандарту(исключения коды для компиляторов не соответствующих стандарту, наподобие Билдера) не являеться хорошим это точно.

[Сыроежка]

Сообщение от Пепел Феникса

код не соответствующий стандарту, является некорректным относительно стандарта, не надо подменять понятия.
но код намеренно не соответсвующий стандарту(исключения коды для компиляторов не соответствующих стандарту, наподобие Билдера) не являеться хорошим это точно.

Я ничего не путаю. Это вы не понимаете. Там, где намеренно Builder не соответсвует стандарту, там в Buildere указываются соответсвуующий режим компилятора и свои настройки в IDE. То есть в Buuildere есть два (а иногда и более режимов компиляции): стандартный, который они обозначают ANSII, свой собственный режим, который они обозначают Borland, а на старых пакетах есть еще режим для Unix 5 и режим, соответсвующий описанию K&R. Причем все эти режимы описаны в документации.
Если вы выбрали режим ANSII и используете не соответсвующие стандарту конструкции, или компиляттор Borland ведет себя не в соответсвии стандарту, тот этот код имеет неопредленное поведение, то есть является некорректным.
Если же вы выбрали собвственный режим компиляции Borland, то естественно он компилирует в соответсвии с описанным в документации к этому режиму особенностями. Но это ужже к стандартну языка С++ не имеет отношения.
То же самое и Microsoft. У них есть расширенный режим, который вы можете выбрать, но тем самым вы на свой страх и риск отклоняетесь от сттандарта. Такой код является не переносимым.
Так что не путайте неопределенное поведение програмы и собственные расширения к языка разработчиков компиляторов. Например, есть такой С++, который называется управляемым. Но какое отношение оон имеет к стандартному языку С++? Это уже сама Microsoft решает, что в этот язык будет входить, а что нет. Здесь сттандарт для нее не закон.

Вообще-то, я все ясно написал в предыдущем соообщении. Странно, что с первого раза вы не поняли, что там написано.

[_Bers]

Сыроежка, Я не ошибко то разбираюсь в настройках компилятора. Но думаю, коли студия сама генерит код void main, стало быть она за базар отвечает. И под самой студией проблем не возникнет.

Другое дело, что допустим, уже неоднократно сталкивался с ситуациями, когда template код отказывался компилироваться на других компиляторах. Причем, кода было написано уже много. И вот поди разбери, что gcc не нравится.

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

[Пепел Феникса]

я вам говорю что все относительно.

Если вы выбрали режим ANSII и используете не соответсвующие стандарту конструкции, или компиляттор Borland ведет себя не в соответсвии стандарту, тот этот код имеет неопредленное поведение, то есть является некорректным.

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

вот что именно я хотел уточнить.

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

В действительности, студия в отношении стандартна дамочка вполне себе фривольная. Можно запросто по ничайности сделать непортируемый код.

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

[_Bers]

Сообщение от Пепел Феникса

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

Ну вот навскидку: это один из таких известных и просто вопиющих фактов студийного беспредела.

Что характерно - я гуглил, из любопытства. Оказывается сий баг корпорации Зла известен, но они сознательно не стали его исправлять, потому что их "попросили". Вот так с лёгкой руки корпорации, баг превратился в фичу. В более поздних компиляторах (ну на 2010 точно знаю) он так же не был исправлен.

template<class Foo>
class Bee
{
private:
    template<class Foo2>  
    Bee& operator =(const Bee<Foo2>&)   { return *this;  }
};

int main (void)
{
    Bee<int> bee1; 
    Bee<float> bee2; 
    bee1 = bee2;  
    return 0;
}

http://liveworkspace.org/code/cb1431...cdd6c997217f52

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


А вот кстати, ещё пример (вот это уже реальные попандосы, я не однократно на такой канители горел):

код в 2008 студии прекрасно компилируется:

#include <iostream>

using namespace std;

template <class T>
struct List
{
    friend ostream& operator<< <T>(ostream& os,List<T>& obj);
    T elem;
};

template <class T> ostream& operator<< (ostream& os,List<T>& obj) {  os << obj.elem;  return os; }

int main (void) { List<int> test;    cout<<test;    return 0; }

http://liveworkspace.org/code/69d1f6...4ab699c3348b0c

А вот правильные решение:
http://liveworkspace.org/code/035a91...f7d4e4410f59c7

Оно показывает причину, по которой православный gcc не хотел компилить первый вариант: он не понимает что за фред-прототип ему такой кормят.

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

Вот конечно ещё более простое и православное решение:
http://liveworkspace.org/code/9f9dfb...f27b1ef78a53df

В общем, нет-нет а переодически надобно студийный код под другими компиляторами пускать, что бы не попасть в просак студийного задолбайства))

[rmv240899]

Сообщение от Blade

main() должна возвращать int

В этой программе - тип main() - void, так что возвращать ничего не нужно