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

V_R>Госпада, подскажите пожалуйста слудующую вещь.
V_R>

V_R>bool f1()
V_R>{
V_R>  //...
V_R>}

V_R>bool f2()
V_R>{
V_R>  //...
V_R>}

V_R>void main()
V_R>{
V_R>  if( f1() || f2() )
V_R>  //Что-то делаем

V_R>  //...
V_R>}
V_R>

V_R>Так вот вопрос в следующем. Знаю точно, что если функция f1 выполнится, то следующее условие в операторе if даже проверяться не будет, т.е. f2 даже не вызовется. А вот и вопрос: определено ли такое поведение стандартом???

V_R>Спасибо!!!



Тут дело не в стандарте, а в операции ИЛИ ( || )
Эта операция делает ИЛИ то, ИЛИ другое.

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


F>Тут дело не в стандарте, а в операции ИЛИ ( || )
F>Эта операция делает ИЛИ то, ИЛИ другое.

Оператор, значит, такой встаёт, смотрит, что тут у него по сторонам. Потом думает "что бы мне сделать из этого". И делает или то или другое.
А && — это его более трудолюбивый брат — он всегда делает и то и другое.

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

V_R>Только вот еще вопрос возник. Я всегда счител, что если компилятор С++ не соответствует стандарту, то получается он уже не компилятор С++, компилятор языка НУ_ОЧЕНЬ_ПОХОЖЕГО_НА_С++. Ведь, если он не выполняет требования стандарта, то это тоже самое, что и нарушить закон, а знчит этот компилятор уже "преступник" получается. Короче, я прав, что компилятор С++, нарушающий требования стандарта С++, собственно компилятором С++ и не является???

Да, прав.
Компиляторов С++ в природе не существует

V_R>Спасибо!!!!

Госпада, подскажите пожалуйста слудующую вещь.

bool f1()
{
  //...
}

bool f2()
{
  //...
}

void main()
{
  if( f1() || f2() )
  //Что-то делаем

  //...
}

Так вот вопрос в следующем. Знаю точно, что если функция f1 выполнится, то следующее условие в операторе if даже проверяться не будет, т.е. f2 даже не вызовется. А вот и вопрос: определено ли такое поведение стандартом???

Спасибо!!!

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

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

R>>Казус в том, что это не совсем так. Можно поглядеть например здесь.

V_R>Бррррррррррррррррррррр. Стоп. Чего-то я не понял!!!! Ссылку посмотрел. Клево!!! Но не понятно. Можно это прокомментировать. Я понял что для каждого компилятора свой набор дефайнов идет, но как это отражается на мой вопрос. Т.е. Вы хотите сказать, что в строчке
V_R>

V_R>if( f1() || f2() )
V_R>

V_R>если истиной будет первая функция, то вторая тоже может вызваться??? А почему тогда так??? А если не так, то как???? Объясните пожалуйста.

Не волнуйся Науке неизвестны компиляторы, которые бы не выполняли требования о порядке вычисления выражений в operator || (если он не перегружен пользователем, конечно).
Ссылка просто показывает, что, к сожалению, многие компиляторы не в полной мере соответствуют стандарту, и разработчикам кросс-платформенных библиотек приходится прилагать много усилий, чтобы все это несоответствия обойти.
Но к твоей проблеме это не относится

Да определено. В случае использования оператора || проверяются все выражения до первого соответствия (true). В случае && до первого несоответствия (false)

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

IM>>Если какая-то конструкция языка влечет за собой неопределенное поведение, то стоит ли использовать ее, учитывая особенности конкретного компилятора?

V_R>Так в том то и дело. Я тоже не хочу использовать такие контсрукции, и чтоб не вляпаться в такую ситуацию и появился на свет этот вопрос! Тока я пока так и не понял это UB или нет! И почему!

Нет. По стандарту.

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

A_A>Здравствуйте, i-maverick, Вы писали:

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

M>>>>А зачем вам знать стандартизовано ли такое поведение?
V_R>>>Да интересно стало, во всех ли компиляторах применяется такое правило. Я пишу под VC.NET, а если сяду за, например, Borland, то там так же будет или нет. Раз это стандартом описано, значит это везде так будет.

IM>>Если какая-то конструкция языка влечет за собой неопределенное поведение, то стоит ли использовать ее, учитывая особенности конкретного компилятора?

A_A>Нет, не стоит, даже если ты точно знаешь, что сделает компилятор.
A_A>Мало того, что не будет переносимости кода на другие компиляторы,
A_A>так ведь еще и при переходе на новую версию того же компилятора
A_A>могут возникнуть проблемы, причину которых сложно обнаружить.


Не совсем так. Тут надо чётко различать 2 случая:
1. Фича не описана в стандарте языка с++ и не описана в документации к компилятору. Тут всё как ты сказал. Причём может сломаться даже при изменении настроек компиляции или ещё от чего-то неизвестного.
2. Фича не описана в стандарте языка с++ и описана в документации к компилятору. Тут ситуация немного другая. Если нет планов переходить на другие компиляторы, то нет причин не пользоваться этой фичей при необходимости. Производители компилятор поддерживают их не хуже чем "стандартные" фичи. Фактически тут можно плевать на стандарт iso языка c++, т.к. документацию к компилятору имеет приоритет.

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


V_R>Только вот еще вопрос возник. Я всегда счител, что если компилятор С++ не соответствует стандарту, то получается он уже не компилятор С++, компилятор языка НУ_ОЧЕНЬ_ПОХОЖЕГО_НА_С++. Ведь, если он не выполняет требования стандарта, то это тоже самое, что и нарушить закон, а знчит этот компилятор уже "преступник" получается. Короче, я прав, что компилятор С++, нарушающий требования стандарта С++, собственно компилятором С++ и не является???


Я лично не считаю, что такие компиляторы нельзя называть компиляторами с++.
Моё мнение основано на том, что тот стандарт, о котором мы все тут говорим, это не "ВЕЛИКИЙ И ЕДИНСТВЕННЫЙ ВСЕЛЕНСКИЙ СТАНДАРТ ЯЗЫКА С++" и в скобочках приписка "все нарушившие СТАНДАРТ будут немедленно аннигилированы", это всего лишь Стандарт языка с++ iso\iec. Не больше и не меньше, Я честно говоря не видел заявлений производителей компиляторов, в которых они бы постулировали свой отношение к стандарту iso\iec. Но как я понимаю, они всего лишь стараются ему максимально соответствовать. Опять же не больше и не меньше. Где-то они его не поддерживают, где-то отклоняются, где-то доопределяют, где-то добавляют что-то своё и т.д.

В качестве примера можно привести тот же boost.config.

Или вот такую слышай байку про Александреску, что типа лет пять назад он писал программы на с++, которые не мог скомпилировать ни один из существующих компиляторов. Не знаю, насколько это правда, но по-моему смешно. Типа Александреску приходит к друзьям "Зацените, какая у меня программа крутая!". Они "Ну давай, запускай! посмотрим". Он "Не, у меня только на бумажке"

Или вот типа: покупаете вы какой-то third-party компонет за серьёные деньги, в описании написано, что код 100% соответствует стандарту с++ iso\iec. Вы типа думаете "ну значит 100% переносимый. круто!". Пытаетесь откомпилировать на свойм компиляторе — не компилируется, компилируете на другом — не компилируется... Спрашивается, кто прав?

В свете всего вышесказанного, думаю, что в первую очередь надо отталкиваться как раз от существующих реализаций языка с++, а не от СТАНДАРТА. В конце концов это и есть тот язык, на котором мы пишем.
А не наоборот — стандарт превозносить, а реализации опускать.
И если уж давать какое-то определение, что такое язык с++, то все существующие промышленные компиляторы должны под него попадать (ну я имею в виду не компиляторы, а языки, которые они реализуют).

Здравствуйте, Vovka_R, Вы писали:
V_R>Так вот вопрос в следующем. Знаю точно, что если функция f1 выполнится, то следующее условие в операторе if даже проверяться не будет, т.е. f2 даже не вызовется. А вот и вопрос: определено ли такое поведение стандартом???

А зачем вам знать стандартизовано ли такое поведение?
Ясно одно что это так и никак иначе!

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

R>>Не совсем так. Тут надо чётко различать 2 случая:
R>>1. Фича не описана в стандарте языка с++ и не описана в документации к компилятору. Тут всё как ты сказал. Причём может сломаться даже при изменении настроек компиляции или ещё от чего-то неизвестного.
R>>2. Фича не описана в стандарте языка с++ и описана в документации к компилятору. Тут ситуация немного другая. Если нет планов переходить на другие компиляторы, то нет причин не пользоваться этой фичей при необходимости. Производители компилятор поддерживают их не хуже чем "стандартные" фичи. Фактически тут можно плевать на стандарт iso языка c++, т.к. документацию к компилятору имеет приоритет.

R>>

A_A>IMHO, в реальных проектах лучше таких "фич" избегать, если нет особой
A_A>необходимости в их использовании. С течением времени могут появляться
A_A>требования и задачи, которые ранее не были предусмотрены. Например,
A_A>портирование кода на GCC для работы под Linux/UNIX.



Ну не знаю, каждому решать самому в каждой конкретной ситуации.

Я, например, покуда проект под msvc, использую __if_exists — это фича msvc, но она документированная, удобная и читабельная.
Если меня спрашивают "а как же если портировать будем?", я отвечаю "Вы поглядите на остальной код, заточенный под msvc. __if_exists будет наименьшей проблемой при портировании, потому что (1) они не скомпилятся, т.е. будут видны все места, где они используются и (2) их известно как заменить. А вот с другими вещами всё не так просто — мы можем (1) не увидеть проблемных мест и (2) не знать как их исправить".

В общем, я имею в виду, что надо смотреть чо к чему. Если, конечно, известно, что проект будет портироваться — это одно. А если портировать не собираются + уже долго пишут и тестируют только под один компилятор, то уж если портировать собирутся, то тут всё равно проблем не оберёшься, это ж не ява.

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

V_R>Тока я пока так и не понял это UB или нет! И почему!


Было бы занятно, если бы это было UB

bool f1()
{
  //...
}

bool f2()
{
  //...
}

void main()
{
  if( f1() || f2() )
  //Что-то делаем

  //...
}

Я уж тогда не знаю, как код писать-то вообще

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

V_R>Так вот вопрос в следующем. Знаю точно, что если функция f1 выполнится, то следующее условие в операторе if даже проверяться не будет, т.е. f2 даже не вызовется. А вот и вопрос: определено ли такое поведение стандартом???
Да.

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

V_R>Так вот вопрос в следующем. Знаю точно, что если функция f1 выполнится, то следующее условие в операторе if даже проверяться не будет, т.е. f2 даже не вызовется. А вот и вопрос: определено ли такое поведение стандартом???

Безусловно:

5.15/1
The || operator groups left-to-right. The operands are both implicitly converted to bool 
(clause 4). It returns true if either of its operands is true, and false otherwise. 
Unlike |, || guarantees left-toright evaluation; moreover, the second operand is not 
evaluated if the first operand evaluates to true.

Ага. Понял. Спасибо БОЛЬШОЕ всем.

Оценочки, оценочки ставить надо...

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

M>Здравствуйте, Vovka_R, Вы писали:
V_R>>Так вот вопрос в следующем. Знаю точно, что если функция f1 выполнится, то следующее условие в операторе if даже проверяться не будет, т.е. f2 даже не вызовется. А вот и вопрос: определено ли такое поведение стандартом???

M>А зачем вам знать стандартизовано ли такое поведение?
Да интересно стало, во всех ли компиляторах применяется такое правило. Я пишу под VC.NET, а если сяду за, например, Borland, то там так же будет или нет. Раз это стандартом описано, значит это везде так будет.

M>Ясно одно что это так и никак иначе!
Верно сказано. Теперь и я это знаю!!!

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

V>Оценочки, оценочки ставить надо...

Ага. Готово!!!!

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


M>>А зачем вам знать стандартизовано ли такое поведение?
V_R>Да интересно стало, во всех ли компиляторах применяется такое правило. Я пишу под VC.NET, а если сяду за, например, Borland, то там так же будет или нет. Раз это стандартом описано, значит это везде так будет.


Казус в том, что это не совсем так. Можно поглядеть например здесь.

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



F>Тут дело не в стандарте, а в операции ИЛИ ( || )
F>Эта операция делает ИЛИ то, ИЛИ другое.

Сам-то понял чё сказал? Или это шутка такая, которую я не догоняю?

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

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


F>>Тут дело не в стандарте, а в операции ИЛИ ( || )
F>>Эта операция делает ИЛИ то, ИЛИ другое.

R>Оператор, значит, такой встаёт, смотрит, что тут у него по сторонам. Потом думает "что бы мне сделать из этого". И делает или то или другое.
R>А && — это его более трудолюбивый брат — он всегда делает и то и другое.

Хорошо сказал. Уважаю!

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

V_R>Раз это стандартом описано, значит это везде так будет.

Твои бы слова да Богу в уши

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

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

M>>А зачем вам знать стандартизовано ли такое поведение?
V_R>Да интересно стало, во всех ли компиляторах применяется такое правило. Я пишу под VC.NET, а если сяду за, например, Borland, то там так же будет или нет. Раз это стандартом описано, значит это везде так будет.

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

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

F>Тут дело не в стандарте, а в операции ИЛИ ( || )
F>Эта операция делает ИЛИ то, ИЛИ другое.

+10!

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

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

M>>>А зачем вам знать стандартизовано ли такое поведение?
V_R>>Да интересно стало, во всех ли компиляторах применяется такое правило. Я пишу под VC.NET, а если сяду за, например, Borland, то там так же будет или нет. Раз это стандартом описано, значит это везде так будет.

IM>Если какая-то конструкция языка влечет за собой неопределенное поведение, то стоит ли использовать ее, учитывая особенности конкретного компилятора?

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

P.S. Компиляторы (C++ Builder) сами по себе являются проблемой.

A_A>P.S. Компиляторы (C++ Builder) сами по себе являются проблемой.

Опечатка, имелось в виду

P.S. Компиляторы Borland (C++ Builder) сами по себе являются проблемой.

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

V_R>>>Да интересно стало, во всех ли компиляторах применяется такое правило. Я пишу под VC.NET, а если сяду за, например, Borland, то там так же будет или нет. Раз это стандартом описано, значит это везде так будет.

IM>>Если какая-то конструкция языка влечет за собой неопределенное поведение, то стоит ли использовать ее, учитывая особенности конкретного компилятора?

A_A>Нет, не стоит, даже если ты точно знаешь, что сделает компилятор.
A_A>Мало того, что не будет переносимости кода на другие компиляторы,
A_A>так ведь еще и при переходе на новую версию того же компилятора
A_A>могут возникнуть проблемы, причину которых сложно обнаружить.

Спасибо конечно, но это был фактически не вопрос, а ответ.

R>Не совсем так. Тут надо чётко различать 2 случая:
R>1. Фича не описана в стандарте языка с++ и не описана в документации к компилятору. Тут всё как ты сказал. Причём может сломаться даже при изменении настроек компиляции или ещё от чего-то неизвестного.
R>2. Фича не описана в стандарте языка с++ и описана в документации к компилятору. Тут ситуация немного другая. Если нет планов переходить на другие компиляторы, то нет причин не пользоваться этой фичей при необходимости. Производители компилятор поддерживают их не хуже чем "стандартные" фичи. Фактически тут можно плевать на стандарт iso языка c++, т.к. документацию к компилятору имеет приоритет.

R>

IMHO, в реальных проектах лучше таких "фич" избегать, если нет особой
необходимости в их использовании. С течением времени могут появляться
требования и задачи, которые ранее не были предусмотрены. Например,
портирование кода на GCC для работы под Linux/UNIX.

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

R>Казус в том, что это не совсем так. Можно поглядеть например здесь.

Бррррррррррррррррррррр. Стоп. Чего-то я не понял!!!! Ссылку посмотрел. Клево!!! Но не понятно. Можно это прокомментировать. Я понял что для каждого компилятора свой набор дефайнов идет, но как это отражается на мой вопрос. Т.е. Вы хотите сказать, что в строчке

if( f1() || f2() )

если истиной будет первая функция, то вторая тоже может вызваться??? А почему тогда так??? А если не так, то как???? Объясните пожалуйста.

Буду безмерно благодарен!!!

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

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

V_R>>Раз это стандартом описано, значит это везде так будет.

J>Твои бы слова да Богу в уши

Так нужно свято верить в это!

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

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

M>>>А зачем вам знать стандартизовано ли такое поведение?
V_R>>Да интересно стало, во всех ли компиляторах применяется такое правило. Я пишу под VC.NET, а если сяду за, например, Borland, то там так же будет или нет. Раз это стандартом описано, значит это везде так будет.

IM>Если какая-то конструкция языка влечет за собой неопределенное поведение, то стоит ли использовать ее, учитывая особенности конкретного компилятора?

Так в том то и дело. Я тоже не хочу использовать такие контсрукции, и чтоб не вляпаться в такую ситуацию и появился на свет этот вопрос! Тока я пока так и не понял это UB или нет! И почему!

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

B>Не волнуйся Науке неизвестны компиляторы, которые бы не выполняли требования о порядке вычисления выражений в operator || (если он не перегружен пользователем, конечно).
B>Ссылка просто показывает, что, к сожалению, многие компиляторы не в полной мере соответствуют стандарту, и разработчикам кросс-платформенных библиотек приходится прилагать много усилий, чтобы все это несоответствия обойти.
B>Но к твоей проблеме это не относится

Спасибаблин!!!!! Прояснилось. Огромные благодарности от меня!!!!

Только вот еще вопрос возник. Я всегда счител, что если компилятор С++ не соответствует стандарту, то получается он уже не компилятор С++, компилятор языка НУ_ОЧЕНЬ_ПОХОЖЕГО_НА_С++. Ведь, если он не выполняет требования стандарта, то это тоже самое, что и нарушить закон, а знчит этот компилятор уже "преступник" получается. Короче, я прав, что компилятор С++, нарушающий требования стандарта С++, собственно компилятором С++ и не является???

Спасибо!!!!

"Vovka_R" <50175@users.rsdn.ru> wrote in message news:1801135@news.rsdn.ru...
>
> Только вот еще вопрос возник. Я всегда счител, что если компилятор С++ не соответствует стандарту, то получается он уже не компилятор С++, компилятор языка НУ_ОЧЕНЬ_ПОХОЖЕГО_НА_С++. Ведь, если он не выполняет требования стандарта, то это тоже самое, что и нарушить закон, а знчит этот компилятор уже "преступник" получается. Короче, я прав, что компилятор С++, нарушающий требования стандарта С++, собственно компилятором С++ и не является???

Если смотреть со всей строгостью, то, наверное, прав. Только я не знаю, существует ли в природе компилятор, который соответствовал бы всем пунктам стандарта на 100%. Я сильно сомневаюсь, однако, поскольку сам стандарт подвержен периодическим изменениям. Получается, что компиляторов C++ вообще нет в природе?

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

V_R>Только вот еще вопрос возник. Я всегда счител, что если компилятор С++ не соответствует стандарту, то получается он уже не компилятор С++, компилятор языка НУ_ОЧЕНЬ_ПОХОЖЕГО_НА_С++. Ведь, если он не выполняет требования стандарта, то это тоже самое, что и нарушить закон, а знчит этот компилятор уже "преступник" получается. Короче, я прав, что компилятор С++, нарушающий требования стандарта С++, собственно компилятором С++ и не является???

На свете нет ни одного компилятора, полностью соответствующего текущему стандарту
Лучшим на сегодня считается Comeau

ЗЫ
Добро пожаловать в реальный мир компиляторов

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

Мда. Я идеалист. Я думал, что они все соответствуют стандарту. Ошибался.

Спасибо!!!

R>В общем, я имею в виду, что надо смотреть чо к чему. Если, конечно, известно, что проект будет портироваться — это одно. А если портировать не собираются + уже долго пишут и тестируют только под один компилятор, то уж если портировать собирутся, то тут всё равно проблем не оберёшься, это ж не ява.


R>

С этим-то я согласен. В том же Borland С++ Builder ты не обойдешься без использования борладовских расширений языка
при написании GUI приложений.
Просто я думал, что изначально речь шла об особенностях реализации, которые
стандарт C++ трактует как неопределенное поведение (UB), а не о vendor-specific расширениях
самого языка.

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

R>Или вот такую слышай байку про Александреску, что типа лет пять назад он писал программы на с++, которые не мог скомпилировать ни один из существующих компиляторов. Не знаю, насколько это правда, но по-моему смешно. Типа Александреску приходит к друзьям "Зацените, какая у меня программа крутая!". Они "Ну давай, запускай! посмотрим". Он "Не, у меня только на бумажке"

Прочитал подобную байку у Саттера: когда Степанов представлял первую версию STL комитету, то на тот момент ее (STL) мог компилить единственный компилятор.
Это конечно не просто "на бумажке", но тем не менее...

R>В свете всего вышесказанного, думаю, что в первую очередь надо отталкиваться как раз от существующих реализаций языка с++, а не от СТАНДАРТА. В конце концов это и есть тот язык, на котором мы пишем.
R>А не наоборот — стандарт превозносить, а реализации опускать.

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

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

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


R>>В свете всего вышесказанного, думаю, что в первую очередь надо отталкиваться как раз от существующих реализаций языка с++, а не от СТАНДАРТА. В конце концов это и есть тот язык, на котором мы пишем.
R>>А не наоборот — стандарт превозносить, а реализации опускать.

B>Ага, а потом приходит момент, когда нужно переносить проект на новую версию того же самого компилятора. И некоторые чудные вещи, которые не разрешены стандартом, но поддерживались языком, на котором писали раньше, вдруг перестают компилироваться И все оттого, что новая верся компилятора ближе к стандарту...

Любят тут люди любят путать документированные особеноссти и недокументированные.
Производители не только свои документированные фичи тщательно поддерживают от версии к версии. Так они ещё и свои особенности, которые противоречат СТАНДАРТУ, тщательно поддерживают.
Так что не надо про смену версии компилятора.

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

R>Любят тут люди любят путать документированные особеноссти и недокументированные.
R>Производители не только свои документированные фичи тщательно поддерживают от версии к версии. Так они ещё и свои особенности, которые противоречат СТАНДАРТУ, тщательно поддерживают.

Наиболее запомнившийся мне пример: возможность явного вызова контструктора в VC6 куда-то испарилась в VC7.1
Запомнился потому, что человек я ленивый, а портировать массу кода с VC6 на VC7.1 пришлось мне...

R>Так что не надо про смену версии компилятора.
То, что тебе не приходилось сталкиваться с исчезновением некоторых не поддерживаемых стандартом фич, совсем не означает, что подобные фичи не исчезают

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

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

R>>Любят тут люди любят путать документированные особеноссти и недокументированные.
R>>Производители не только свои документированные фичи тщательно поддерживают от версии к версии. Так они ещё и свои особенности, которые противоречат СТАНДАРТУ, тщательно поддерживают.

B>Наиболее запомнившийся мне пример: возможность явного вызова контструктора в VC6 куда-то испарилась в VC7.1
B>Запомнился потому, что человек я ленивый, а портировать массу кода с VC6 на VC7.1 пришлось мне...

R>>Так что не надо про смену версии компилятора.
B>То, что тебе не приходилось сталкиваться с исчезновением некоторых не поддерживаемых стандартом фич, совсем не означает, что подобные фичи не исчезают

Можно примеры.

Явный вызов конструктора был документирован?

Я могу привести в качестве примеров (речь о msvc):
все pragma,
все declspec,
__if_exists,
настройка компилятора "/Zc:wchar_t (wchar_t Is Native Type)" — сейчас в стандарте wchar_t всегда Native Type
настройка компилятора "/Zc:forScope (Force Conformance in for Loop Scope)" — исходя из стандарта она тоже не нужна

Вот такие вещи я называю документированными особенностями компилятора, у меня лично пока с ними проблем не возникало, потому что это является частью языка visual c++

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

V_R>Госпада, подскажите пожалуйста слудующую вещь.
V_R>

V_R>bool f1()
V_R>{
V_R>  //...
V_R>}

V_R>bool f2()
V_R>{
V_R>  //...
V_R>}

V_R>void main()
V_R>{
V_R>  if( f1() || f2() )
V_R>  //Что-то делаем

V_R>  //...
V_R>}
V_R>

V_R>Так вот вопрос в следующем. Знаю точно, что если функция f1 выполнится, то следующее условие в операторе if даже проверяться не будет, т.е. f2 даже не вызовется. А вот и вопрос: определено ли такое поведение стандартом???

V_R>Спасибо!!!

Сорри что не прочитал весь тред снизу... Он слишком большой а я слишком ленивый
Может там и есть то на чём я заострю...
А заострить я хочу на том, что операторы то эти перегружаются... А как их перегрузили... Оно тебе нада потом левій код изучать?
Так что я советую использовать вложенные конструкции if

if (f1())
{
}
else if (f2)
{
}

Меньше проблем + намного читабельней

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

R>Можно примеры.

((CString *) &p->m_pszInfo)->CString::CString (strInfo);

Вот такой код прекрасно компилировлся и работал в VC6.

R>Явный вызов конструктора был документирован?

Нет, это не было документировано. Но привел я этот пример в ответ на

Так они ещё и свои особенности, которые противоречат СТАНДАРТУ, тщательно поддерживают.

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

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

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

R>>Можно примеры.

B>

B>((CString *) &p->m_pszInfo)->CString::CString (strInfo);
B>

B>Вот такой код прекрасно компилировлся и работал в VC6.

R>>Явный вызов конструктора был документирован?

B>Нет, это не было документировано. Но привел я этот пример в ответ на
B>

B>Так они ещё и свои особенности, которые противоречат СТАНДАРТУ, тщательно поддерживают.

Тут я, конечно, имел в виду особенности, которые документированы, а не баги и т.д.


B>Что касается документированых несоответствий, то я с трудом представляю себе производителя, который бы в новых версиях убрал бы эти самые несоотвтетсвия — это потеря совместимости со старым кодом, и весьма вероятная потеря клиента. Тут, конечно, спорить нет никакого смысла.

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

DV>Сорри что не прочитал весь тред снизу... Он слишком большой а я слишком ленивый
DV>Может там и есть то на чём я заострю...
DV>А заострить я хочу на том, что операторы то эти перегружаются... А как их перегрузили... Оно тебе нада потом левій код изучать?
DV>Так что я советую использовать вложенные конструкции if
DV>

DV>if (f1())
DV>{
DV>}
DV>else if (f2)
DV>{
DV>}
DV>

DV>Меньше проблем + намного читабельней

А я тогда советую ещё не использовать функцию f1(), вдруг её кто изменил