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

[yigal_s]

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

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

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

А, к примеру,

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

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

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

Comments

[oblomov-jerusal.livejournal.com]

Вы жалуетесь на то, что C++ - не функциональный язык? А зачем вы тогда им пользуетесь? (Или я воспринимаю ваш текст слишком всерьез?)

[yigal_s]

> А зачем вы тогда им пользуетесь?

Дык, однолюб я. Т.е. жутко консервативен. Опять же, нравится мне ООП. Тот, который не во главе с Арафатом.

> (Или я воспринимаю ваш текст слишком всерьез?)

:-)))

хе-хе

[cmm.livejournal.com]

> Опять же, нравится мне ООП

"I invented the term Object-Oriented, and I can tell you I did not have C++ in mind."
-- Alan Key

Re: хе-хе

[yigal_s]

Дык, согласно его же критериям, С++ - вполне OO. Что делать, не мог же Alan Key иметь всё "in mind".

Хотя, на мой взгляд, определение выглядит устаревшим.

[cmm.livejournal.com]

это проблема с такая с определениями: все неявные условия вовремя не укажешь, поскольку предугадать вектор изменения контекста невозможно.
Кей, к примеру, определённо имел в виду объектную ориентацию программ, а не языка, понимаемого компилятором.
программы, написанные на C++, после компиляции объектно-ориентированными не являются (кроме тех редких случаев, когда все методы виртуальны, программист позаботился не отключить RTTI, и программа умеет читать свою собственную debug info).
термин "объектно-ориентированное" и звучит именно таким образом (а не, скажем, "класс-ориентированное" или "фигурно-скобочно-ориентированное"), потому что говорит об объектах.  объект — это такая фигня, которая существует (то есть живёт в оперативной памяти, может быть идентифицирована, и имеет определёный тип) во время работы программы, а не её компиляции.
людям, пишущим batch-утилиты и не пользующимся никакой интроспекцией, это различие неважно.  многим другим — важно.

[yigal_s]

У меня, наверное, маленький кругозор.

Что до RTTI, то помимо реализации мультиметодов, напрямую в С++ неподдерживаемых и всякой базовой мелочи, вроде стриминга идетнификаторов классов, я не вижу реальной необходимости в RTTI.

Что до Debug Info - опять же применение неясно. Что такого хорошего можно поиметь с интроспеции?

[cmm.livejournal.com]

с интроспекции можно поиметь её саму.  она делает возможным настоящий data-oriented programming, каковой очень подходит для всякого рода больших, долго живущих и расширяемых систем.
как показывает опыт, объяснять необходимость подобных радостей жизни совершенно бесполезно.  если припрёт — поймёте сами, если не припрёт (а припирает далеко не всех, и это абсолютно нормально) — то и ну его.
чтобы меня правильно поняли: я вовсе не утверждаю, что C++ говно, потому что не по-настоящему объектно-ориентирован (он говно по достаточному количеству иных причин, право же).  объектная ориентация не есть сама по себе критерий качества.  я всего лишь пытался объяснить, что (как мне кажется) мог иметь в виду г-н Кей, поскольку (как мне, опять-таки, кажется) я понимаю откуда пляшут его определения, поскольку я неплохо знаком с системами типа Smalltalk'а и Lisp'а.

[yigal_s]

Нет, всё нормально.

И понятно, что объяснить можно тому, кто и так всё почти понимает. По крайней мере, в двух абзацах.

Может, хоть ссылочки адекватнуе кинете по интроспекции и её нетривиальной пользе для долгоживущих систем, data-oriented programming и проч? - я б почитал.

[cmm.livejournal.com]

а не надо ссылочек.
вот поглядите, скажем, на стоящее перед Вами в данный момэнт устройство типа "персональный компьютер".  на нём бежит большая, долгоживущая и интроспективная по самое не могу программа, называемая "операционная система".
предположим, эта система называется "юникс" (система типа "виндоуз" отличается от системы типа "юникс", но не существенно.  "юникс" в принципе сильно проще, а посему представляет из себя лучший пример).  аналогом "процедур" в языке "юникс" являются бинарные программы, интерпретируемые процессором.  аналогом аргументов являются строчки из коммандной строки.  аналогом пойнтеров — имена файлов.  аналогом структур данных — файлы.  единственным типом данных, который понимает "юникс", является голая строка из байтов, у которой даже длина не указана.  имеется также run-time environment, называемый "ядро операционной системы", отвечающий за разделение процедур друг от дружки, подчищание экскрементов, убиение слищком жадных до памяти процедур, и прочая.
теперь представьте, что в качестве базового языка и run-time environment'а мы имеем что-то менее идиотское чем "юникс", например Smalltalk, или Lisp, или на худой конец Java.  представьте себе теперь, что на основе подобного базиса написана настоящая операционная система (примеры имели место, и вполне успешные, кстати).  можно ли написать подобную вещь привычным class-oriented стилем?  нельзя, поскольку все объекты, с которыми подобной программе придётся иметь дело — "manifestly typed", то есть самоописывающиеся.  их тип закодирован в них самих, мы не можем рассказать его компилятору и забыть о нём.
теперь более практически: программирование на Smalltalk, Lisp, или на худой конец Java разумнее рассматривать не как "написал код, скомпилировал в маааленький исполняемый файл, отправил заказчику", а как "взял исходную систему, расширил её своей функциональностью".  таким образом, философия системы естественным образом перетекает в философию приложений, реализованных на базе этой системы.
что же касается "data-oriented programming", то ничего особенно содержательного в этом понятии нет.  это просто следствие из видения мира, в котором полноценные типированные объекты (а не C++-like куски памяти, тип которых когда-то знал компилятор) живут в программе, а не только в компиляторе.
если всё-таки хочется ссылок, то лучше сгрузить с сети хороший Smalltalk или Common Lisp и поиграться с ним. :)

[yigal_s]

Аналогии понятны, но в чем состоит интроспективность операционной системы, из вашего поста мне не было ясным.

Опять же, видимо, в силу моего ограниченного опыта, не совсем понятно, что нормальная программа (а не дебаггер-трассировщик какой-нибудь) может сделать с "полноценным типированным объектом" такого нетривиального. Есть, конечно, отдельные случаи, когда имеет смысл выяснить, поддерживает ли объект тот или иной интерфейс (C++ RTTI, COM IIDs etc.), но кажется, по большей части такая практика свидетельствует о неполноценности дизайна, который приводит к череде if-ов, разбросанных там-сям в программе и крайне тяжело поддерживаемых в больших проектах. Кажется, за такую практику Страуструп где-то и критиковал SmallTalk.

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

[cmm.livejournal.com]

> Аналогии понятны, но в чем состоит интроспективность операционной системы, из вашего поста мне не было ясным.

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

> Опять же, видимо, в силу моего ограниченного опыта, не совсем понятно, что нормальная программа (а не дебаггер-трассировщик какой-нибудь) может сделать с "полноценным типированным объектом" такого нетривиального. Есть, конечно, отдельные случаи, когда имеет смысл выяснить, поддерживает ли объект тот или иной интерфейс (C++ RTTI, COM IIDs etc.), но кажется, по большей части такая практика свидетельствует о неполноценности дизайна, который приводит к череде if-ов, разбросанных там-сям в программе и крайне тяжело поддерживаемых в больших проектах. Кажется, за такую практику Страуструп где-то и критиковал SmallTalk.

мой предыдущий пост был достаточно сумбурен, и этот обещает быть не лучше. :)

основная идея в следующем: говоря о data-oriented programming, я не пытаюсь что-либо рекламировать.  я очевидным образом не сумел сформулировать самый важный пункт: DOP не есть что-то, что получается посредством сознательного применения каких-то там специальных методик.  DOP — это то, что остаётся после отказа от явных глупостей.  разумеется, придерживающиеся философии DOP системы делают практичными некоторые методики, о которых в C++ и иже с ним даже думать не получается, но это уже следствие и в данном контексте менее интересно.

например, я не в коем случае не утверждаю чего-либо о [не]желательности полноценного дизайна.  ясное дело, наличие дизайна объективно лучше, чем отсутствие такового.  означает ли это, что система не должна в принципе допускать возможности работать иным образом?

давайте я для простоты перечислю (некоторые) фундаментальные аспекты философии C++ и иже с ним, которые я считаю глупостями:

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

0 — это число 0, а ни в коем случае не указатель на объект, сидящий по адресу 0, и не значок с кодом 0.

"abc" — это строка "abc", а не число 1633837824 и не указатель на объект по соответствующему адресу.

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

2. тип объектов как нечто, присутствующее лишь при компиляции.  это чисто философски неприятно ещё и по той простой причине, что выкидывать информацию вообще в принципе некрасиво.  кто он, чёрт возьми, такой, этот компилятор, и почему он считает себя умнее меня?

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

3. (как следствие из предыдущих пунктов) unsafe runtime environment.  в наше время это просто смешно, это даже оптимизацией не назовёшь, это мазохизм чистой воды (не говоря уже о проблемах с security).

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

это правильно. :)

[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'а каждого класса.

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

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

> после компиляции объектно-ориентированными не являю

[poige.livejournal.com]

Объекты это же не вещь в себе. Им нужна среда, верно? Далее, средой можно считать интерпретатор (не забывая про то, что он сам откомпилирован, и выполняется на вполне определённом железе), а можно — и то самое «определённое железо». В чём, в таком случае, какие-либо ключевые отличия? Моё личное мнение таково, что термин «ООП» следует применять не к тому, как всё представлено на момент выполнения, а к тому, как это выглядит при разработке программы, какими концепциями пользуются разработчик, так сказать.

Re: > после компиляции объектно-ориентированными не яв

[cmm.livejournal.com]

если я правильно помню контекст, я всего лишь пытался объяснить оригинальное (т.е. согласно Алану Кею) определение и мотивацию термина "ООП" — и только.  никаких эмоций я по данному поводу не испытывал и не испытываю, споры о религиозной терминологии считаю бесполезной тратой времени, и поговорить на данную в высшей степени фасцинирующюю тему ещё, честно говоря, не горю желанием.

извините. :)

> пытался объяснить оригинальное (т.е. согласно Алану К

[poige.livejournal.com]

[…]
> извините. :)

np :-)

[ex-ilyavinar899.livejournal.com]

Вам нужен язык для машины потоков данных VAL: http://www.bath.ac.uk/~cs2jmal/prog4/index.html

[thornik.livejournal.com]

Нифига не понял. Речь напоминает прожжёного функциональщика, который уже и сам верит, что присваивание не нужно, хотя тысячи программистов это делают и даже как-то не задумываются, нужно ли его выкидывать.

У вас есть какое-то разумное объяснение, почему в программе переменные - вторичны, а константы - первичны?

[yigal_s]

"И вот тут-то, если где словечко var будет позабыто, компилятор начнет ругаться практически наверняка"

[thornik.livejournal.com]

А почему вы решили, что констант в программе больше переменных?
Вот посчитал по прожекту число присваиваний:
---------- DB_LAYER.CS: 225
---------- EFT.CS: 41
---------- TMS_MANAGEMENT.CS: 28
---------- TREASURYMONITORSERVICE.CS: 137
---------- TREASURYMONITORSERVICE_AIRTIME.CS: 79
---------- TREASURYMONITORSERVICE_LOYALTY.CS: 49
---------- TREASURYMONITORSERVICE_SPUR.CS: 33
---------- TREASURYMONITORSERVICE_TRANSACTION.CS: 144
---------- TREASURYMONITORSERVICE_VOUCHERS.CS: 35

Я бы сказал, не так уж и мало! Часть, так и быть, инициализация (хотя у меня большинство констант сидят в enum), но остальных присвоений тоже немерянно!

Я хочу сказать так: ни var, ни const не спасает от банально тупых алгоритмов. Куда больше гемороя приносят неочевидные "особенности" чужих функций.