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

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

N>>положим захотелось нам искать среднее двух чисел и написали мы функцию:
N>>int kaka (int a, int b){return (a+b)/2;}

N>>и всё вроде тип-топ, но вот тут сунули нам два числа (вполне корректных):

N>>int a = 2113929216;
N>>int b = 2113929210;

N>>и что? а какое решение-то простое есть? ассемблер в три команды не предлогать, всё на с++
N>>p.s. я решение знаю, но не сказал бы что оно простое

_>

_>int kaka (int a, int b) {
_>  return b + (a-b)/2;
_>}
_>

_>Чем так сложно-то?
_>Только теперь это не для всех signed int'ов будет работать
_>Если серьёзно, то отсутствие проверок на переполнение или написания заведомо безопасного кода, который понадобится только в редких случаях очень больших чисел — это обычная дилемма выбора между временем (и разработки и выполнения) и качеством.

_>В конце-концов, если у программиста не хватило ума/времени усмотреть опасность в "return (a+b)/2;", то вряд ли он предусмотрит корректную обработку OverflowException

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

int kaka(int a, int b) {
   try {
      return (a+b)/2;
   } catch (OverflowException) {
      return b + (a-b)/2;
   }
}

Но только выглядит

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

4>Я без сомнения чайник и,....

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

Лучше почитывай и анализируй если уж заинтересовался бесполезнешими из споров

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

4>Я без сомнения чайник

Если Вы и правда начинающий, то я согласен с мнением AlexEagle: лучше набраться опыта (язык важен, но он — все же — не главное); послушать тех, послушать других, и сделать по-своему.

4>и, как мне тут объяснили, сноб (что бы это слово значило),

Во-первых, на тот случай, если смысл слова неясен, существуют словари.
Во-вторых, я имел в виду тех программистов на Си++ (многих), с которыми тесно общался долгие годы, и кого я хорошо знаю. Причем, называя их "снобами", я уж никак не хочу их обидеть (я говорю о своих приятелях, и они с радостью бы подтвердили мои слова — на все другие языки они смотрят "свысока").
Так что я назвал "снобом" не Вас, хотя меня и удивила Ваша фраза:

Впрочем, можно поговорить на чем пишут программы биологи или мастера слесарного дела.

4>Язык программирования — это прежде всего язык общения, а уже потом технология. С-подобный синтаксис — лучший придуманняй на данный момент (или это тоже спорный вопрос?).

Раз существуют разные точки зрения, этот вопрос, видимо, надо считать спорным.
Если Вы спросите мое личное мнение, то я предпочитаю синтаксис Модулы-2 и Оберона.
Во-первых, он лучше (ИМХО) читается и понимается. (И это несмотря на то, что я почти 20 лет пишу преимущественно на Си и (с начала 90-х) на Си++!)
Во-вторых, грамматика Модулы-2 (и Оберона) позволяет быстрее находить ошибки (многих из них вообще избежать) и больше способствуют оптимизации кода (за счет приводимости графов — подробности в "красном драконе" Ахо, Сети и Ульмана).

4>Поддержка любого другого синтаксиса — маркетинговая необходимость всем понятно каких фирм.

Каких?
Вот когда Sun передрала Оберон, но использовала Си-подобный синтаксис, — это маркетинговый ход.
А какие фирмы Вы имеете в виду?

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

AVC>>>Ответ: Неадкватность языков и компиляторов, использованных в написании операционной системы (C и C++). [/q]
P>>Плохому танцору... Кстати интересно, неужели в MS не нашлось ни одного человека, знаюцего про Оберон? Сомневаюсь... Видать показался еще более "неадекватным".
AVC>Угу. Показался настолько неадекватным, что Microsoft начала настоящую "охоту" на "оберонщиков".

Боюсь ты не понял "глубины вопроса" На момент написания Windows (не .Net, а именно Windows, старой доброй надстройки над DOS) Оберон вроде уже существовал. Однако мелкософтом оказался невостребован, заюзали C/C++. На момент написания Win95 — уж точно оберон не просто был, а был уже довольно хорошо раскручен. И снова — мимо кассы, не заинтересовал, решили придерживаться старой испытанной технологии. Но стоп, ведь кроме нее была еще New Technology a/k/a Win NT, казалось бы там-то сам бог велел использовать все самое прогрессивное, включая язык? Да нет, и тут — старый добрый C[++]... Теперь вот надо понимать MS спохватились и решили отказаться от пережитков? ИМХО поздновато, больше похоже на попытку списать свои старые ошибки на "неудачный компилятор" и заодно попиарить свои новые технологии. А насчет того, что оберонщиков юзали при написании .Net — разве ж я возражаю? Было бы странно, если б не юзали — как-никак академический проект с многолетней историей. Одного того, что они уже набили много шишек — достаточно чтоб взять их в проект, за одного битого, как известно, двух небитых дают.

AVC>Среди представленных летом 2000г. 12 компиляторов для .NET было 2 Оберона: Oberon-2 и Component Pascal. (Поговаривают, что только они и работали без ошибок. )

"Нет здоровых людей, есть непроверявшиеся!" (с) врачи
"Да кому он нужен, этот неуловимый Джо..." (с) анек


AVC>Уже говорилось, что программисты на Си++ — снобы и зазнайки.
AVC>Разве неверно говорилось?

ХЗ, я на нем не программирую. Во всяком случае профессионально.

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

AVC>Раз существуют разные точки зрения, этот вопрос, видимо, надо считать спорным.
AVC>Если Вы спросите мое личное мнение, то я предпочитаю синтаксис Модулы-2 и Оберона.
AVC>Во-первых, он лучше (ИМХО) читается и понимается. (И это несмотря на то, что я почти 20 лет пишу преимущественно на Си и (с начала 90-х) на Си++!)
AVC>Во-вторых, грамматика Модулы-2 (и Оберона) позволяет быстрее находить ошибки (многих из них вообще избежать) и больше способствуют оптимизации кода (за счет приводимости графов — подробности в "красном драконе" Ахо, Сети и Ульмана).

Вы, очевидно, невнимательно читали книгу. Там же ясно, черным по белому написано:
"Использование только структурированных конструкций управления потоком, таких как if-then-else, while-do, continue и break, приводит к программам, графы потоков которых всегда приводимы".
В реальности, это не проблема в C/C++, поскольку использование goto (или switch для прыжка внуть цикла) в нормально написаных программах есть вещь исключительная.
И вообще -- чем больше возможностей, тем больше возможностей и для написания эффективного кода.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

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

AVC>Как раз на тему переполнений и прочей "гадости".
AVC>См. страничку:
AVC>http://www.inr.ac.ru/~info21/blackbox/disciplina/arr_bounds_checks.htm
AVC>Вот выдержка:

Вопрос: Что мешает Майкрософт компилировать Windows XP с включенной опцией контроля выхода за границы массивов?
AVC>Ответ: Неадкватность языков и компиляторов, использованных в написании операционной системы (C и C++).

Представь себе, случилось. Вся операционка (драйвера, ядро, утилиты — все-все) переписана на свервысоконадежном языке. Попробуй оценить, сколько тысяч раз в секунду будет выполняться проверка выхода счетчика за свои границы, правильности строки и т.п. Там много чего придется ежесекундно проверять!
В твоем любимом компиляторе тоже все счетчики сначала сами проверятся, а потом уже до твоих доберутся.
И можно развить идею. Зачем тормозить на полпути?
Во всех деревьях также необходимо проверять, что ветки указывают на правильный адрес, а не куда попало. Также обязательно следить, чтобы случайно не образовалось циклических ссылок и дубликатов ключей.
Запретить null terminated string, всегда следить на уровне ОС, чтобы длина строки вдруг не превысила бы размер выделенного ей блока памяти.
Много чего можно придумать, чтобы надежно защититься от глупых ошибок и страшных дырок.

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

AVC>>Раз существуют разные точки зрения, этот вопрос, видимо, надо считать спорным.
AVC>>Если Вы спросите мое личное мнение, то я предпочитаю синтаксис Модулы-2 и Оберона.
AVC>>Во-первых, он лучше (ИМХО) читается и понимается. (И это несмотря на то, что я почти 20 лет пишу преимущественно на Си и (с начала 90-х) на Си++!)
AVC>>Во-вторых, грамматика Модулы-2 (и Оберона) позволяет быстрее находить ошибки (многих из них вообще избежать) и больше способствуют оптимизации кода (за счет приводимости графов — подробности в "красном драконе" Ахо, Сети и Ульмана).

Ш>Вы, очевидно, невнимательно читали книгу. Там же ясно, черным по белому написано:
Ш>"Использование только структурированных конструкций управления потоком, таких как if-then-else, while-do, continue и break, приводит к программам, графы потоков которых всегда приводимы".

Действительно, использование только указанных конструкций гарантирует приводимость потоков графов.
В чем именно проявилась моя невнимательность?

Ш>В реальности, это не проблема в C/C++, поскольку использование goto (или switch для прыжка внуть цикла) в нормально написаных программах есть вещь исключительная.

Одно дело, когда оператора goto вообще нет в языке (как в Модуле-2 и Обероне).
И совсем другое, когда он просто редко используется.
В первом случае возможна синтаксически управляемая оптимизация, во втором — приходится дополнительно анализировать графы потоков управления.

Ш>И вообще -- чем больше возможностей, тем больше возможностей и для написания эффективного кода.

ИМХО, как раз наоборот — тем больше возможностей написать неэффективный код.

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

AVC>>Как раз на тему переполнений и прочей "гадости".
AVC>>См. страничку:
AVC>>http://www.inr.ac.ru/~info21/blackbox/disciplina/arr_bounds_checks.htm
AVC>>Вот выдержка:

Вопрос: Что мешает Майкрософт компилировать Windows XP с включенной опцией контроля выхода за границы массивов?
AVC>>Ответ: Неадкватность языков и компиляторов, использованных в написании операционной системы (C и C++).

М>Представь себе, случилось. Вся операционка (драйвера, ядро, утилиты — все-все) переписана на свервысоконадежном языке. Попробуй оценить, сколько тысяч раз в секунду будет выполняться проверка выхода счетчика за свои границы, правильности строки и т.п. Там много чего придется ежесекундно проверять!
М>В твоем любимом компиляторе тоже все счетчики сначала сами проверятся, а потом уже до твоих доберутся.
М>И можно развить идею. Зачем тормозить на полпути?
М>Во всех деревьях также необходимо проверять, что ветки указывают на правильный адрес, а не куда попало. Также обязательно следить, чтобы случайно не образовалось циклических ссылок и дубликатов ключей.

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

М>Запретить null terminated string, всегда следить на уровне ОС, чтобы длина строки вдруг не превысила бы размер выделенного ей блока памяти.

Для этого нет нужды запрещать null terminated string.

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

Хороших идей должно быть много.
И какова мораль?
Если Вы хотите намекнуть, что многократно упадет эффективность, то Вы заблуждаетесь.
По результатам сравнения программ с проверками и без оных было установлено — падение эффективности не превышает 10%. А зачастую — не превышает 1%.
Если же для Вас так критичен этот процент, то отладьте программу, а затем отключите проверки.

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

AVC>Так это все давно реализовано.
AVC>Вы со своей идеей опоздали.

Как я понял, новых идей никто и не предлагает... Предложение относится только к использованию всех возможных проверок.

AVC>Если Вы хотите намекнуть, что многократно упадет эффективность, то Вы заблуждаетесь.
AVC>По результатам сравнения программ с проверками и без оных было установлено — падение эффективности не превышает 10%. А зачастую — не превышает 1%.

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

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

AVC>Если же для Вас так критичен этот процент, то отладьте программу, а затем отключите проверки.

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

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

A>Как я понял, новых идей никто и не предлагает... Предложение относится только к использованию всех возможных проверок.

AVC>>Если Вы хотите намекнуть, что многократно упадет эффективность, то Вы заблуждаетесь.
AVC>>По результатам сравнения программ с проверками и без оных было установлено — падение эффективности не превышает 10%. А зачастую — не превышает 1%.

A>ИМХО некорректная цифра, т.к. эти программы испытывались на "классической" операционной системе — без встроенных проверок границ и указателей.

A>А если сама система начнёт проверять границы? На десять ли процентов рухнет производительность, или таки поболее? Операционка-то посложнее даже самых крутых офисных пакетов будет...

Такая операционка существует с 80-х годов: ОС Оберон.
Не так давно на RSDN с жаром дебатировался вопрос: нужна ли ОС Оберон защита памяти?
Дело в том, что наличие указанных проверок в ОС Оберон приводит не к уменьшению, а к увеличению производительности, т.к. не требуется нескольких адресных пространств, а достаточно одного; нет нужды "щелкать" контекстами. (В Обероне компилятор гарантирует "сохранность" памяти.)
В итоге минимальный системный вызов в Обероне в 30 раз быстрее, чем в Linux.

AVC>>Если же для Вас так критичен этот процент, то отладьте программу, а затем отключите проверки.

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

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

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

AVC>Я бы и в релизном коде оставлял проверки, когда важна корректность результата.

Интересно, а как корректность результата будет обеспечиваться проверками? Такая проверка лишь даст возможность как можно более корректно вывалить программу/модуль, при условии, что исключение было поймано и соответсвующим образом обработано (что делается редко).

Хотя конечно можно и вместо

int summ(int[] a) {
   int r = 0;

   for (int i = 0; i < a.Length; r += a[i++]);

   return r;
}

писать

int summ(int[] a) {
   int r = 0, i = 0;

   try {
      while (true)
         r += a[i++];
   } catch (IndexOutOfRangeException) {
      return r;
   }
}

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

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

AVC>Так что я назвал "снобом" не Вас, хотя меня и удивила Ваша фраза:

Впрочем, можно поговорить на чем пишут программы биологи или мастера слесарного дела.

Это, в свою очередь, меня удивила Ваша фраза:

Очевидно, продуманный минимализм средств является ключевым требованием, если мы хотим, чтобы язык программирования мирно «уживался» в мозгу исследователей со всей необходимой физикой, математикой и проч. знаниями.

Довод в ветке "Почему настоящие программисты избегают C++"?

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

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

A>>Как я понял, новых идей никто и не предлагает... Предложение относится только к использованию всех возможных проверок.

AVC>>>Если Вы хотите намекнуть, что многократно упадет эффективность, то Вы заблуждаетесь.
AVC>>>По результатам сравнения программ с проверками и без оных было установлено — падение эффективности не превышает 10%. А зачастую — не превышает 1%.

A>>ИМХО некорректная цифра, т.к. эти программы испытывались на "классической" операционной системе — без встроенных проверок границ и указателей.

A>>А если сама система начнёт проверять границы? На десять ли процентов рухнет производительность, или таки поболее? Операционка-то посложнее даже самых крутых офисных пакетов будет...

AVC>Такая операционка существует с 80-х годов: ОС Оберон.
AVC>Не так давно на RSDN с жаром дебатировался вопрос: нужна ли ОС Оберон защита памяти?
AVC>Дело в том, что наличие указанных проверок в ОС Оберон приводит не к уменьшению, а к увеличению производительности, т.к. не требуется нескольких адресных пространств, а достаточно одного; нет нужды "щелкать" контекстами. (В Обероне компилятор гарантирует "сохранность" памяти.)
AVC>В итоге минимальный системный вызов в Обероне в 30 раз быстрее, чем в Linux.

А эта ОС платная? Если нет, то можно ли себе где-нибудь скачать? (Хочется пощупать, что это такое, да и если доки какие есть — почитать).
Прошу прощения за вопросы чайника, но я до прочтения споров об этой системе вообще никогда про нее не слышал...

AVC>>>Если же для Вас так критичен этот процент, то отладьте программу, а затем отключите проверки.

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

AVC>Я бы и в релизном коде оставлял проверки, когда важна корректность результата.

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

E__>...можно ли себе где-нибудь скачать?

Фантастика на 2-м этаже

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

AVC>По результатам сравнения программ с проверками и без оных было установлено — падение эффективности не превышает 10%. А зачастую — не превышает 1%.

Правильно! Будут даже сотые доли процента!
Ну, не нужны массивы ядру ОС... Точнее, очень редко используются.
А вот как проверять те замысловатые хитросплетения, которые там на самом деле есть — это под большим вопросом.

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

Прошу прощения, что не долго отвечал.
Было не до Интернета.

AVC>>По результатам сравнения программ с проверками и без оных было установлено — падение эффективности не превышает 10%. А зачастую — не превышает 1%.

М>Правильно! Будут даже сотые доли процента!
М>Ну, не нужны массивы ядру ОС... Точнее, очень редко используются.

Увы, я не понял, что Вы хотели этим сказать.
Массивы используются часто, и ядро ОС не является исключением.
Возьмите для примера хотя бы буферы ввода/вывода, которые так любят переполняться.
Если же Вы хотели сказать, что потеря эффективности незначительная только потому, что массивы используются редко, то это (ИМХО) сомнительное утверждение.
Рассмотрим простой пример:

PROCEDURE InitArray(VAR a: ARRAY OF INTEGER);
  VAR i: LONGINT;
BEGIN
  FOR i := 0 TO LEN(a)-1 DO
    a[i] := 0
  END
END InitArray;

Много ли нужно run-time проверок, чтобы удостовериться, что индекс не выходит за границы массива?
Очевидно, ни одной. Потери эффективности нет вовсе!
А ведь это самый "ходовой" вид цикла в Обероне (и не только).
Проверка на выход за границы массива в данном случае полностью происходит на этапе компиляции.
А вот для Си/Си++ это невозможно: там передается не массив, а указатель. Что не одно и то же.

М>А вот как проверять те замысловатые хитросплетения, которые там на самом деле есть — это под большим вопросом.

А в чем, собственно, заключается этот "большой" вопрос?

AVC>А вот для Си/Си++ это невозможно: там передается не массив, а указатель. Что не одно и то же.
Дык и тут тоже передается указатель и длина массива (в неявном виде). А Си++ такое и не надо. Проверки нужны только в отладочной версии, всё.

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

DB>Все эти "комментарии" лишний раз доказывают, что 99% всех программистов на С++ -- просто ламеры. Автор языка, кстати, попадает в эти 99%

Ну просвети нас, тёмных, пророк-Братик!

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

T>жена — Pascal
T>проститутка — C++
T>любовница — ?

любовница -- коды PDP11 например. И потрахаешься в волю и пользы никакой

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

AVC>То, что большинство (конечно, не все) программистов на Си++ — "снобы", это правда.
AVC>Я общаюсь практически только с Си++никами (т.к. сам пишу на Си++), так что могу это подтвердить, исходя из опыта.

А может просто не попёрло с коллегами?
Лично я знаю много людей, которые программируют на C++, правда они не воспринимают его как что-то такое важное для них лично. Обычные люди. Разные. Снобов тоже видал. Обычно они очень любят итераторы, шаблоны, Александреску, те, кто знают, любят boost (ил инаоборот ненавидят) и плодят какой-то очень сложный для понимания средним программистом на C++ код.
Правда я не стал бы их называть "настоящие программисты", потому что такой программист -- это в первую очередь хороший инженер.

Мне кажется, что такойц программист в первую очередь должен ценить два свойства кода:
1) Простота.
2) Лбой человек подойдёт и разберётся и поймёт, например, как багу поправить, или как к своей задаче адаптировать.

А "гибкость" и "красота" ценностями не являются. Ну а если являются, то это скорее ворма литературы илит поэзии.
Такие "поэтические программисты" обычно снобы. Но разве они настоящие?