Настящии праграмисты ни пишут на плюсах, патаму што:
1) Настаящии прграмиры нифига ни петрят в указателях. Эта очинь сложна. К таму жи они видут к частым багам (и указатили тожи ). И ваще хрен знаит што я тут написал:

int a = 10;
(&a)[a&a+~(a|a)+1])=*(&a+(a&~a)*(a^a)*(~(int)&a-(0xFFFFFFFF–(int)&a)));

2) У ниво слишкам многа всяких закарючик (сматри выше) вместа таких панятных слов как then, begin, end, and, or, not, .... Фик разбирешь што сам только што написал.

3) Я уш ни гаварю пра всякие праверки выхада за придел масива, исключения при пирипалнении. Если ни делать таких праверак, то прога ни будит карректно работать.

4) Такой код ни работаит для 2113929216 и 2113929210:

int mval(int a, int b) {
   return (a+b)/2;
}

5) Там есть биззнакавыи целыи, паэтаму мой код ни работаит. А са знакавыми он тожи не работаит, патаму шта пирипалнение праисходит.

6) И ваще, шаблоны – ацтой, патаму шта у них нет канстрайнтав.

7) И ваще, плюсы – ацтой, патаму шта я ни умею них писать


Настаящии праграмисты ни пишут на диезах, патаму што:
1) Там нет указатилей. Эта аграничиваит миня, ни дает мне полнава кантроля над ситуацией. А я крутой праграмер! Я умею писать указатили. Сматрити, што я магу на плюсах:

int a = 10;
(&a)[a&a+~(a|a)+1])=*(&a+(a&~a)*(a^a)*(~(int)&a-(0xFFFFFFFF–(int)&a)));

2) Я уш ни гаварю пра всякие праверки выхада за придел масива, исключения при пирипалнении. Если делать такии праверки, то прога будит очинь сильна тармазить.

3) Там нет шаблонав. Шаблоны – эта крута!

4) Такой код ни работаит для 2113929216 и 2113929210:

int mval(int a, int b) {
   return (a+b)/2;
}

5) Там есть биззнакавыи целыи, паэтаму мой код ни работаит. А са знакавыми он тожи не работаит, патаму шта пирипалнение праисходит.

6) И ваще он ни кампилируица, а интырпритируица. Карочи тармазит.

7) И ваще, диезы – ацтой, патаму шта ани ат мелкасофта.


Настаящии праграмиры ни пишут на паскалях, патаму шта:
1) Там очинь глупыи и никрасивыи указатили. Сматити, што я магу на плюсах:

int a = 10;
(&a)[a&a+~(a|a)+1])=*(&a+(a&~a)*(a^a)*(~(int)&a-(0xFFFFFFFF–(int)&a)));

Лучши бы их вабще убрали...

2) Накаляит писать пастаянна :=, then, begin, end, and, or, not, div, mod, .... Сматити выши как эта можна сделать на плюсах. И низя абъявить пирименную, где захочишь.

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

4) Там нет шаблонав. Шаблоны – эта крута!

5) Там есть биззнакавыи целыи, паэтаму мой код ни работаит. А са знакавыми он тожи не работаит, патаму шта пирипалнение праисходит.

6) Такой код ни работаит для 2113929216 и 2113929210:

function mval(a, b: Integer): Integer;
begin
   Result := (a+b) div 2;
end;

7) И ваще, паскали (ни путать с маскалями!) – ацтой, патаму шта ани жрут многа места и гинирируют многа retав.


Карочи, чиста канкретныи риальныи програмиры ваще ни на чем ни пишут. Ани тока пиво пьют и чипцы жрут!!!

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

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

K>>Функции, логика которых не предусматривает ошибочных ситуаций, не должны кидать исключений. А функция вычисления среднего арифметического относится как раз к таким. Т.е. предложенное тобой решение с генерацией исключения неверно.

VD>Функция не учитывающая переполенеие уже ошибочна.

Очень серьезные дяди писали на серьезном языке Ada, где есть исключения по переполнению. Результат здесь.

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

К>Братику:
К>Во-первых, про исключения при переполнении. А не пофиг ли, что будет исключение? Ведь факт переполнения можно выявить и другим способом,

Каким?

Вообще-то, не пофиг. Идея с исключениями при переполнении состоит в следующем: после выполнения арифметических действий компилятор вставляет проверку на флаг переполнения и, в случае возникновения переполнения, генерирует исключительную ситуацию. Это позволяет реализовывать арифметические алгоритмы, не загромождая свой код проверками на возможность возникновения переполнений. Также это дает выигрыш в производительности, особенно там, где критичен каждый лишний if. И это совершенно перепендикулярно тому, как функция вернет ошибочный результат наверх: исключением, кодом ошибки или запустит более продвинутый (но более тормозной) алгоритм, который обработает такую ситуацию.

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

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

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

VD>>Функция не учитывающая переполенеие уже ошибочна.

A>Очень серьезные дяди писали на серьезном языке Ada, где есть исключения по переполнению. Результат здесь.

Читаем...

The internal SRI software exception was caused during execution of a data conversion from 64-bit floating point to 16-bit signed integer value. The floating point number which was converted had a value greater than what could be represented by a 16-bit signed integer. This resulted in an Operand Error. The data conversion instructions (in Ada code) were not protected from causing an Operand Error, although other conversions of comparable variables in the same place in the code were protected.

The error occurred in a part of the software that only performs alignment of the strap-down inertial platform. This software module computes meaningful results only before lift-off. As soon as the launcher lifts off, this function serves no purpose.

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

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

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

DB>>>

DB>>>std::vector<int> v;
DB>>>for (std::vector<int>::size_type i = v.size() - 1; i >= 0; ++i)
DB>>>{
DB>>>  ...
DB>>>}
DB>>>

VD>>Вот это пример хороший.

Ш>Ты внимательно прочитал этот код?

канешна — этож плюсы. а нормальный не плюсовый компилер и сам в состоянии понять что нада декремент делать!! ессно что на плюсах работать не будет

Hello, AlikGut!
You wrote on Fri, 18 Feb 2005 09:14:05 GMT:

DB>>>>

 DB>>>> std::vector<int> v;
 DB>>>> for (std::vector<int>::size_type i = v.size() - 1; i >= 0;
 DB>>>> ++i) { ... }

A> канешна — этож плюсы. а нормальный не плюсовый компилер и сам в
A> состоянии понять что нада декремент делать!! ессно что на плюсах
A> работать не будет

Интересно, как в этой ситуации может помочь декремент?

With best regards, Sergey.

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

K>Проблема переполнения остаётся и при использовании беззнаковых целых. А для int в данном случае решение есть и простое (не сказал бы что красивое, но...). Приводим a и b к long long, а после деления обратно к int.

В стандарте C++ нет типа long long ! это всё мелгомягкие дополнения решения есть но ещё кривее

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

_>int kakashka( int a, int b )
_>{
_>return (a>>1 + b>>1) + ( ((a&1)&&(b&1))?1:0 );
_>}

оно самое, только вот код со всеми супер оптимизациями займёт раз в 10 больше чем простой и глупый код в три команды на ассеблере — печально, ведь это один из самых низкоуровневых из высокоуровневых языков

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

К>>Во-первых, про исключения при переполнении. А не пофиг ли, что будет исключение? Ведь факт переполнения можно выявить и другим способом,

K_O>Каким?

Проверками предусловий, однако.

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

Вот так?

int mid(int a, int b) throw() // наружу мы ничего не кидаем
{
  try // попробуем быстрый, но небезопасный способ...
  {
    return (a+b)/2;
  }
  catch(overflow_error& ex) // облажались? тогда попробуем по-другому...
  {
    return a/2+b/2+(a%2+b%2)/2;
  }
}

Здесь, очевидно, использование метода облажались-переделали — это извращение.
А на каких практических задачах он эффективен?

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

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

Разумеется, бывают.
Просто — исключения (в любом виде: объектно-ориентированные, структурные, сигналы) не являются "серебряной пулей"! Нельзя бездумно молиться на них, а тем более — пользоваться где ни попадя.

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

_>>int kakashka( int a, int b )
_>>{
_>>return (a>>1 + b>>1) + ( ((a&1)&&(b&1))?1:0 );
_>>}

N>оно самое, только вот код со всеми супер оптимизациями займёт раз в 10 больше чем простой и глупый код в три команды на ассеблере — печально, ведь это один из самых низкоуровневых из высокоуровневых языков

1) Как я уже говорил, этот код неправильный.

2) Если какой-то процессор эффективно и без переполнения позволяет находить среднее арифметическое, и оно очень востребовано — то можно написать ассемблерную вставку.

; запретить INTO
cli

mov eax, _a_
add eax, _b_
ror eax, 1

; восстановить
sti

К>2) Если какой-то процессор эффективно и без переполнения позволяет находить среднее арифметическое, и оно очень востребовано — то можно написать ассемблерную вставку.
К>

К>; запретить INTO
К>cli

К>mov eax, _a_
К>add eax, _b_
К>ror eax, 1

К>; восстановить
К>sti
К>

а зачем CLI и STI то в этом случае?
насчёт ошибочности согласен, но и a/2 + b/2 + (a%2 + b%2)/2 не подарок явно!

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

К>>>Во-первых, про исключения при переполнении. А не пофиг ли, что будет исключение? Ведь факт переполнения можно выявить и другим способом,
K_O>>Каким?
К>Проверками предусловий, однако.

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

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

К>Вот так?
К>

К>int mid(int a, int b) throw() // наружу мы ничего не кидаем
К>{
К>  try // попробуем быстрый, но небезопасный способ...
К>  {
К>    return (a+b)/2;
К>  }
К>  catch(overflow_error& ex) // облажались? тогда попробуем по-другому...
К>  {
К>    return a/2+b/2+(a%2+b%2)/2;
К>  }
К>}
К>

К>Здесь, очевидно, использование метода облажались-переделали — это извращение.
К>А на каких практических задачах он эффективен?

На тех, для которых известно, что переполнение возникает очень редко.

К>Вот так?
К>

К>int mid(int a, int b) throw() // наружу мы ничего не кидаем
К>{
К>  try // попробуем быстрый, но небезопасный способ...
К>  {
К>    return (a+b)/2;
К>  }
К>  catch(overflow_error& ex) // облажались? тогда попробуем по-другому...
К>  {
К>    return a/2+b/2+(a%2+b%2)/2;
К>  }
К>}
К>

К>Здесь, очевидно, использование метода облажались-переделали — это извращение.
К>А на каких практических задачах он эффективен?

думаю что он эффективен там где не учитывается возможность переполнения а она происходит, пример как раз (a+b)/2 -- это типичная ошибка для программиста, там где не ткнули носом что он не прав, а сколько времени уйдёт у не опытного (а может и у опытного) чтобы понять в чём дело-то, ведь (a+b)/2 это как правло не вся программа, а случай переполнения скорее всго вообще не возникнет на этапе разработки и тестирования в российских условиях, когда проверяют только тыканьем кнопок. Особенно когда вы делаете не гуи или ещё какие задачи простые и не очень, а что-то вычислительное, учесть все переполнение иногда бывает сверх-издевательством.

может ещё DBC обсудим по ходу этого обсуждения (DBC = design by contracts, см. Eiffel)

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

K_O>Читаем...
K_O>

K_O>The internal SRI software exception was caused during execution of a data conversion from 64-bit floating point to 16-bit signed integer value. The floating point number which was converted had a value greater than what could be represented by a 16-bit signed integer. This resulted in an Operand Error. The data conversion instructions (in Ada code) were not protected from causing an Operand Error, although other conversions of comparable variables in the same place in the code were protected.

K_O>The error occurred in a part of the software that only performs alignment of the strap-down inertial platform. This software module computes meaningful results only before lift-off. As soon as the launcher lifts off, this function serves no purpose.

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

K_O>На самом деле ошибка была в том, что разработчики не предусмотрели такую ситуацию и не защитились от нее.

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

PS я неудачно выбрал пост для размещения ссылки. В этом обсуждении есть более хорошие места для нее

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

S>Интересно, как в этой ситуации может помочь декремент?

никак — но с ним будет в тыщу раз круче — один раз оно всетаки отработает а Вы, читайте самую самую нижнюю строчку в моей подписи

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

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

К>>>Во-первых, про исключения при переполнении. А не пофиг ли, что будет исключение? Ведь факт переполнения можно выявить и другим способом,

K_O>>Каким?

К>Проверками предусловий, однако.

А не логичнее(в таких языках как Java, C#) следующее:
1)позволить переполнению произойти
2)перехватить исключение и обернуть в свое исключение — однозначно идентифицирующее место возникновения
3)внешний код разруливает ситуацию по своему усмотрению( в моих задачах это запись в журнал ошибок с детальной информацией о произошедшем и окончание вычислительной сессии с немедленным приведением системы в максимально безопасное логическое состояние && (в зависимости от режима работы, если в режиме реальной эксплуатации — создание новой вычислительной сессии, получение новой порции данных и их обработка, иначе если это отладочный режим — шотдаун и последующий разбор полётов).
?

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

N>а зачем CLI и STI то в этом случае?

А, действительно, незачем. Это я забыл нафиг ассемблер.
Чтобы получить прерывание по переполнению, нужно самому вставлять инструкцию INTO после вычислений.
Извините.

N>насчёт ошибочности согласен, но и a/2 + b/2 + (a%2 + b%2)/2 не подарок явно!

Почему же не подарок? Деление округляет к меньшему по модулю, а остаток — знаковый.

Hello, AlikGut!
You wrote on Fri, 18 Feb 2005 11:46:11 GMT:

S>> Интересно, как в этой ситуации может помочь декремент?

A> никак — но с ним будет в тыщу раз круче — один раз оно всетаки
A> отработает

Оно по-любому будет работать пока батарейки не сядут

A> а Вы, читайте самую самую нижнюю строчку в моей подписи
А мне через текстовый NNTP подписей не видно.

With best regards, Sergey.

N>В стандарте C++ нет типа long long ! это всё мелгомягкие дополнения :) решения есть но ещё кривее :))

6.1.2.5 Types

3 There are five standard signed integer types,
designated as signed char, short int, int, long int, and
long long int. (These and other types may be designated in
several additional ways, as described in 6.5.2.) There may
also be implementation-defined extended signed integer
types.25 The standard and extended signed integer types are
collectively called just signed integer types.

Странно, в том тексте стандарта С++, что у меня есть, упоминания о "long long int" действительно нету. А в стандарте C — есть.
Но в любом случае это не расширения Microsoft, так как поддерживаются и gcc, например.
Скорее всего, это просто ещё не "переползло" окончательно из стандарта С в С++, но переползёт обязательно — куда же без стандартного типа long long int?