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


PD>>Именно благодаря этому код на C/C++ столь эффективен.

Т>Опыт общения с различными программами заставляет меня усомниться в истинности данного высказывания.

Личный опыт сравнения кода, сгенерированного VC++ (Release, конечно) и оптимизированного кода на ассемблере позволяет мне делать это утверждение.

Павел Кузнецов wrote:
> К сожалению, в отличие от C++, поддержки сколько-нибудь сложных
> вычислений при таком подходе не выйдет, т.к. в процессе вычислений и L^4
> (квадрат площади), и L^5 (площать * объем), и L / T (скорость), и L^2 /
> T^2 (квадрат скорости), и M * L / T (импульс), и M * L^2 / T^2
> (энергия), и M^2 * L^4 / T^4 (квадрат энергии), и т.п. легко получаются...
>

Это детали реализации. Можно сгенерировать модуль с типами, названными в
духе t3l_2m1e1 (размерность Кл*кг*с*с*с/(м*м)).

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

ПК>Отсюда какой должен следовать вывод у человека, которому надежность работы его программ небезразлична? На мой взгляд простой: не передавать массивы в C++ через указатели.
Или не использовать C++. Тоже вариант.

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

ГВ>Следовательно, проверять индекс нужно до его использования, следовательно, проверять индекс на уровне массива никакой необходимости нет — всё равно он ему "приходит" уже заведомо корректным.

А если приходит всё же не корректным, тогда что, портить память?

AVC>>Еще иногда требуется проверка динамического типа переменной. Для этого в Обероне достаточно одного сравнения.

ГВ>А это вообще часто называется ошибкой проектирования.

Наоборот. Это такой способ проектирования.
http://www.inr.ac.ru/~info21/wirth/programming_in_oberon.pdf

Programming in Oberon
Niklaus Wirth
Part 4
23. Object-oriented Programming
23.4. Handlers and Messages

  PROCEDURE Handle(f: Figure; VAR msg: Message);
    VAR r: Rectangle;
  BEGIN r := f(Rectangle);
    IF msg IS DrawMsg THEN (*draw rectangle r*)
    ELSIF msg IS MarkMsg THEN MarkRectangle(r, msg(MarkMsg).on)
    ELSIF msg IS MoveMsg THEN
      INC(r.x, msg(MoveMsg).x); INC(r.y, msg(MoveMsg).y)
    ELSIF …
    END
  END Handle

Component Pascal:

TYPE
  Message = ABSTRACT RECORD END;

  CtrlMsg = RECORD (Message)
    Key: INTEGER;
    Shift: SET
  END;

  TickMsg = RECORD (Message)
    TickCount: INTEGER
  END;

  ...

  PROCEDURE Receive(VAR msg: Message);
  BEGIN
    WITH msg: CtrlMsg DO (* Только одна проверка. Внутри блока проверок больше нет *)
        ... 
        IF msg.Key = 13 THEN ... END;
        ...
      | msg: TickMsg DO  (* Только одна проверка. Внутри блока проверок больше нет *)
        ...
        IF msg.TickCount > last THEN ... END;
        ...  
    ELSE
      (* Тип сообщения не опознан *)
    END     
  END Receive;

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

Попробую резюмировать.

Все примеры, что ты приводил, относятся к той самой части языка, которая не type-safety и досталась в наследие от C. И конечно же, ты можешь неявно привести массив к указателю, обратиться за границы массива и т.д. и т.п. Компилятор тебе этого не запретит. Но кто тебя заставляет это делать? Никто. Это как раз пример той самой "запретительной" конвенции, о которой я говорил чуть раньше. Не используй массивы — есть много им альтернатив, начиная с std::vector. Не используй голые указатели — смарт-пойнтеров огромное множество. Type safety будет почти 100%. И глядишь, все станет радужнее и приятнее.
Все эти низкоуровневые элементы есть смысл использовать только при реализации высокоуровневых примитивов и/или в критичных по производительности местах (хотя и тут надо смотреть внимательно — зачастую высокоуровневые средства типа тех же смарт-пойнтеров никакого run-time оверхеда в себе не несут). Конечно, если ты начнешь направо и налево указатели разбрасывать да массивы к указателям приводить, ничего путного не получится. Но не надо, пожалуйста, приводить это в качестве довода — никто не заставляет тебя их использовать где попало.

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

CX>Попробую резюмировать.

CX>Все примеры, что ты приводил, относятся к той самой части языка, которая не type-safety и досталась в наследие от C. И конечно же, ты можешь неявно привести массив к указателю, обратиться за границы массива и т.д. и т.п. Компилятор тебе этого не запретит. Но кто тебя заставляет это делать? Никто. Это как раз пример той самой "запретительной" конвенции, о которой я говорил чуть раньше. Не используй массивы — есть много им альтернатив, начиная с std::vector. Не используй голые указатели — смарт-пойнтеров огромное множество. Type safety будет почти 100%. И глядишь, все станет радужнее и приятнее.
CX>Все эти низкоуровневые элементы есть смысл использовать только при реализации высокоуровневых примитивов и/или в критичных по производительности местах (хотя и тут надо смотреть внимательно — зачастую высокоуровневые средства типа тех же смарт-пойнтеров никакого run-time оверхеда в себе не несут). Конечно, если ты начнешь направо и налево указатели разбрасывать да массивы к указателям приводить, ничего путного не получится. Но не надо, пожалуйста, приводить это в качестве довода — никто не заставляет тебя их использовать где попало.

Дмитрий, конечно, я согласен с тобой в том, что "надо делать хорошо и не надо плохо".
Но мне вот подумалось, что твой совет мало отличается от совета Трурля не использовать Си++ вообще.

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

AVC>Дмитрий, конечно, я согласен с тобой в том, что "надо делать хорошо и не надо плохо".
AVC>Но мне вот подумалось, что твой совет мало отличается от совета Трурля не использовать Си++ вообще.

Ну почему же — отличается. Прежде всего тем, что в моем случае, если понадобится, я смогу использовать и голые указатели, и прочее. Кроме того, отказавшись от C++, я потеряю мощнейшую вещь, которой нет пока ни в одном другом языке — шаблонное метапрограммирование.

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

CX> Но кто тебя заставляет это делать? Никто... Не используй массивы .... Не используй голые указатели...
Вспомнилась одна фраза, сказанная по другому поводу.

... у меня есть одна маленькая славная штучка, ... которая нужна как зайцу стоп-сигнал... и, при некоторой изобретательности, и затратив надлежащее время и усердие — можно сделать так, что она даже не будет мешать!

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

Т>Вспомнилась одна фраза, сказанная по другому поводу.
Т>

... у меня есть одна маленькая славная штучка, ... которая нужна как зайцу стоп-сигнал... и, при некоторой изобретательности, и затратив надлежащее время и усердие — можно сделать так, что она даже не будет мешать!

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

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

CX> Кроме того, отказавшись от C++, я потеряю мощнейшую вещь, которой нет пока ни в одном другом языке — шаблонное метапрограммирование.

Наверное стоит изобрести совершенно новый язык принципиально основанный на шаблонах но не имеющий к С++ ни какого отношения. Вот тогда программисты наконец-то бросят С++...

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

CX>Кроме того, отказавшись от C++, я потеряю мощнейшую вещь, которой нет пока ни в одном другом языке — шаблонное метапрограммирование.

А чем шаблонное метапрограммирование лучше нешаблонного?

Наверное, лет через 10 рекомендации будут звучать примерно так:

Не используй шаблоны — есть много им альтернатив, начиная с мегафичи X...

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, CrystaX, Вы писали:

CX>> Кроме того, отказавшись от C++, я потеряю мощнейшую вещь, которой нет пока ни в одном другом языке — шаблонное метапрограммирование.

СГ>Наверное стоит изобрести совершенно новый язык принципиально основанный на шаблонах но не имеющий к С++ ни какого отношения. Вот тогда программисты наконец-то бросят С++...

Вряд ли. Сила C++ не в отдельных парадигмах, а в тесной их взаимосвязи в рамках одного языка.

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

CX>Здравствуйте, Сергей Губанов, Вы писали:

СГ>>Здравствуйте, CrystaX, Вы писали:

CX>>> Кроме того, отказавшись от C++, я потеряю мощнейшую вещь, которой нет пока ни в одном другом языке — шаблонное метапрограммирование.

СГ>>Наверное стоит изобрести совершенно новый язык принципиально основанный на шаблонах но не имеющий к С++ ни какого отношения. Вот тогда программисты наконец-то бросят С++...

CX>Вряд ли. Сила C++ не в отдельных парадигмах, а в тесной их взаимосвязи в рамках одного языка.

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

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

CX>Здравствуйте, Трурль, Вы писали:

Т>>Вспомнилась одна фраза, сказанная по другому поводу.
Т>>

... у меня есть одна маленькая славная штучка, ... которая нужна как зайцу стоп-сигнал... и, при некоторой изобретательности, и затратив надлежащее время и усердие — можно сделать так, что она даже не будет мешать!

CX>
CX>Да, это все действительно забавно, но вообще Ваша фраза — только следствие того, что пока во внимание принимаются только недостатки C++ и не принимаются достоинства. Неужели Вы их не видите (достоинств)?

Ну, поскольку ветка посвящена написанию надежных программ, то достоинства C++ в плане помощи создания таких программ, еще поискать нужно.
К сожалению.

Здравствуйте, Сергей Губанов, Вы писали:

ГВ>>А это вообще часто называется ошибкой проектирования.

СГ>Наоборот. Это такой способ проектирования.

Больше того, когда перекомпиляция невозможна (хотя бы из-за того, что существует огромное количество клиентного кода), этот способ остается единственным.
См. Оберон, Windows etc.

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

AVC>>Дмитрий, конечно, я согласен с тобой в том, что "надо делать хорошо и не надо плохо".
AVC>>Но мне вот подумалось, что твой совет мало отличается от совета Трурля не использовать Си++ вообще.

CX>Ну почему же — отличается. Прежде всего тем, что в моем случае, если понадобится, я смогу использовать и голые указатели, и прочее. Кроме того, отказавшись от C++, я потеряю мощнейшую вещь, которой нет пока ни в одном другом языке — шаблонное метапрограммирование.

Наслышан. Правда, все примеры, которые мне попадались, сводились к вычислениям во времени компиляции. Других выгод я пока не видел.
А, как таковое, метапрограммирование существует во многих языках — Lisp, Oberon и т.д.

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

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

CX>>Кроме того, отказавшись от C++, я потеряю мощнейшую вещь, которой нет пока ни в одном другом языке — шаблонное метапрограммирование.

Т>А чем шаблонное метапрограммирование лучше нешаблонного?

Попробуйте — увидите. Я приводил уже пример реализации системы единиц с автоматическим пересчетом из одной системы в жругую, с выводом нового типа из операций, в которых участвуют другие типы (скорость = длина/время) и с запретом преобразования из одного типа в другой. Как мне удалось это сделать? А именно с помощью шаблонного метапрограммирования, причем основывался я на boost::mpl, который весь сплошь — информация для компилятора, не генерирующая никаких вычислений в run-time.

Т>Наверное, лет через 10 рекомендации будут звучать примерно так:
Т>

Не используй шаблоны — есть много им альтернатив, начиная с мегафичи X...

Вряд ли. Просто потому, что шаблоны к тому времени изменятся, но сохранят то лучшее, что в них есть сейчас. Да, современные C++ шаблоны можно во многом улучшить, но в них есть то, чего нет ни в каком другом языке — механизм вычислений на этапе компиляции.

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

CX>>
CX>>Да, это все действительно забавно, но вообще Ваша фраза — только следствие того, что пока во внимание принимаются только недостатки C++ и не принимаются достоинства. Неужели Вы их не видите (достоинств)?

E>Ну, поскольку ветка посвящена написанию надежных программ, то достоинства C++ в плане помощи создания таких программ, еще поискать нужно.
E>К сожалению.

Надо разделять два понятия:
1. Язык помогает писать надежные программы
2. Язык запрещает писать ненадежные программы.

Так вот, C++ помогает писать надежные, но не запрещает писать ненадежные программы, только и всего.

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

CX>>Ну почему же — отличается. Прежде всего тем, что в моем случае, если понадобится, я смогу использовать и голые указатели, и прочее. Кроме того, отказавшись от C++, я потеряю мощнейшую вещь, которой нет пока ни в одном другом языке — шаблонное метапрограммирование.

AVC>Наслышан. Правда, все примеры, которые мне попадались, сводились к вычислениям во времени компиляции. Других выгод я пока не видел.

А разве этого недостаточно?

AVC>А, как таковое, метапрограммирование существует во многих языках — Lisp, Oberon и т.д.

Согласен. Но я говорил именно о шаблонном метапрограммировании, compile-time программировании, присущем только C++.

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

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

CX>>>
CX>>>Да, это все действительно забавно, но вообще Ваша фраза — только следствие того, что пока во внимание принимаются только недостатки C++ и не принимаются достоинства. Неужели Вы их не видите (достоинств)?

E>>Ну, поскольку ветка посвящена написанию надежных программ, то достоинства C++ в плане помощи создания таких программ, еще поискать нужно.
E>>К сожалению.

Я бы подкоректировал твой список:

CX>Надо разделять два понятия:
CX>1. Язык помогает писать надежные программы
CX>2. Язык запрещает писать ненадежные программы.
3. Язык позволяет писать надежные программы.

CX>Так вот, C++ помогает писать надежные, но не запрещает писать ненадежные программы, только и всего.

Имхо, C++ позволяет писать надежные программы.