О константности. Продолжаю публикацию списка преступлений Страуса++

[yigal_s]

Свершенно мерзкое словечко const. Стоит только лишь наивно поверить, что константность лучше указывать, чем игнорировать, как код начинает пестрить этим словечком, что АхредуптусЪ русский дореволюционный буквой Ъ. А ежели где его и позабудешь - компилятор, ессно, тебя не поправит, "сойдет и так".

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

Например,
char **a;
приличной реализации языка следует понимать как константный указатель на константный указатель на константный символ.

А, к примеру,

char var **a = getAddress();
**a = 'Ъ';

следует понимать как цепочку константых указателей на неконстантный символ (который мы, собственно, и собрались менять). И вот тут-то, если где словечко var будет позабыто, компилятор начнет ругаться практически наверняка.

Мало этого. Слово var по большому счету тоже излишне. Неконстантность значения есть, вообще говоря, преступление перед Разумом. В приличном языке оператор присваивания, меняющий значение, уместен не более, чем оператор goto. Что это за бред такой?! Вы где-то видели в математике (оперирующей символами сплошь и рядом) какой-то там "оператор присваивания"?! Оператор присваивания полностью запутывает программу, принуждая программиста отслеживать так называемые "изменения переменных" - это пострашнее отслеживания любых переходов с метки на метку. Язык Prolog же, к примеру, как и следовало ожидать, прекрасно обходится без оператора присваивания. Ибо нафиг не нужен.

Comments

[yigal_s]

> делают практичными некоторые методики, о которых в C++ и иже с ним даже думать не получается

А именно? Что Вы имеете в виду?

> означает ли это, что система не должна в принципе допускать возможности работать иным образом?

Сложный вопрос. С одной стороны, кашу маслом не испортишь. Но вот считать RTTI и вообще интроспекцию необходимой частью OO без демонстрации сереьзных примеров применения, я бы не стал.
При этом я не отрицаю реальную необходимость RTTI в С++, как уже было сказано - но это в силу ограниченности средств языка (того же отсутствия мультиметодов), а не в силу естественности применения RTTI в OO.

Кастирование нуля в указатель итп., конечно, не очень удачно. Но почему нельзя рассматривать строки как указатели на память - именно ради оптимизации, понятно не очень. Так или иначе, понятно, что среда действительно крайне ненадёжна - мне как раз, в отличие от вас, видится, что отчасти это следствие именно оптимизации (строк и массивов вообще).

> выкидывать информацию вообще в принципе некрасиво

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

> тип объектов как нечто, присутствующее лишь при компиляции. это чисто философски неприятно

RTTI уже есть (его значение в С++ я не преуменьшаю). А что еще нужно, кроме него, чтобы тип объекта присутствовал в Run Time? Доступ к контейнеру, содержащему имена и типы всех методов объекта? :-) Или? И что мы с такой информацией такого можем сделать?

И опять же, как отсутствие типа объекта превращает делает нам "unsafe runtime environment" ?

[cmm.livejournal.com]

> И опять же, как отсутствие типа объекта превращает делает нам "unsafe runtime environment" ?

а очень просто.

файл "ook.h":

struct a {
  int x;
};

файл "eek.h":

struct a {
  int y;
  int x;
};

файл "ook.cpp":

#include "ook.h"

struct a *
make_new_a () {
  return new struct a;
}

файл "eek.cpp":

#include "eek.h"

struct a *make_new_a ();

int
main (int argc, char *argv[]) {
  struct a *foo = make_new_a ();
  foo->x = 5;
}

скомпилируйте ook.cpp и eek.cpp и слинкуйте вместе.  ответьте на вопрос: что именно считать определением типа "a" в результирующей программе, и будет ли она работать? :)

> > делают практичными некоторые методики, о которых в C++ и иже с ним даже думать не получается
>А именно? Что Вы имеете в виду?

нетушки :).  я пока ещё не убедился, что мы вообще на одном языке разговариваем.  потому что если Вам кажется, что Вам (или, если угодно, Вам как (по крайней мере, отчасти) типичному представителю любителей C++) пытаются "продать" safe runtimes, то мы друг друга не понимаем.

> Сложный вопрос. С одной стороны, кашу маслом не испортишь. Но вот считать RTTI и вообще интроспекцию необходимой частью OO без демонстрации сереьзных примеров применения, я бы не стал. При этом я не отрицаю реальную необходимость RTTI в С++, как уже было сказано - но это в силу ограниченности средств языка (того же отсутствия мультиметодов), а не в силу естественности применения RTTI в OO.

I beg your pardon?  объектная ориентация подразумевает типирование объектов, точка.  необходимой частью принятого стиля программирования на C++ RTTI, очевидно, не является.  (это одна из причин, по которым о C++ желательно забыть, ну да ладно. :))

> Кастирование нуля в указатель итп., конечно, не очень удачно.

принцип "I don't care if this is wrong, as long as this is fast" вообще не очень удачен.

> Но почему нельзя рассматривать строки как указатели на память - именно ради оптимизации, понятно не очень. Так или иначе, понятно, что среда действительно крайне ненадёжна - мне как раз, в отличие от вас, видится, что отчасти это следствие именно оптимизации (строк и массивов вообще).

строка была не самым удачным примером, поскольку в C/C++ это действительно указатель на память.  давайте так: "abc" — это именно и только указатель на место, где сидят 'a', 'b', 'c' и '\0'.  а не номер 67868767, не массив целых чисел, не ...

> > выкидывать информацию вообще в принципе некрасиво
> Слишком общее утверждение. Эдак, вы еще захотите, чтобы программе были доступны собственные исходники.

не захочу.  система типов (и прочая интересная структурная информация) никакого отношения к исходникам не имеет и исходников для интерпретации не требует.

> RTTI уже есть (его значение в С++ я не преуменьшаю). А что еще нужно, кроме него, чтобы тип объекта присутствовал в Run Time? Доступ к контейнеру, содержащему имена и типы всех методов объекта? :-)

не вижу причин для смайлика.  насчёт имён не знаю, зависит от языка.  но какую-то идентификацию — безусловно.  потому что method dispatch обязан принимаеть во внимание тип объекта (а не тип указателя при компиляции и т.д.).  вообще-то, в случае C++, такой "контейнер" принято называть vtable.

ладно методы.  вот что абсолютно необходимо, так это описание data layout'а каждого класса.

> И что мы с такой информацией такого можем сделать?

пожалуйте изучить (ещё разок) примерчик из начала данного комментария. :)