Здравствуйте, WolfHound, Вы писали:
WH>Ты какой компилятор используешь? Например VC++7.1 позволяет перейти не в недра STL а туда откуда пошла бага.
Его, но и он не всегда справляется.
WH>Тут надо учитывать что VCL это паскаль... А выразительность паскаля на единицу кода гораздо меньше чем у С++. Это раз.
А это еще что за бегемотопотам? Давай не использовать понятия без их предварительного определения.
Что такое единица кода?
Что такое выразительность ЯП на единицу кода?
WH>Спирит это шаблонная библиотека которая использует метапрограммирование на всю катушку. А это абстрации несколько иного порядка чем VCL. Это два.
"Проблемы негров шерифа не колышут". Если нельзя написать просто, то почему сложность реализации рассматривается как достоинство?
WH>Спирит на дельфе написать не возможно. Это три.
Спорить здесь будем или сразу в "Священные войны"?
WH>Да и при чем тут это?
Да при том, что в ЯП ты предлагаешь операцию вычитания векторов обозначать символом "-". А операция-то не такая уж и простая...
K_O>>Не ComposeVectorVector, а Compose(Vector v1, Vector v2) или Vector.Compose(Vector v) WH>А чем оно лучше + я всеравно не понимаю.
Короче имя метода.
Здравствуйте ЗАПЯТАЯ Serginio1 ЗАПЯТАЯ Вы писали ДВОЕТОЧИЕ
S> Но лучше тогда S> f= a.VectorDiv(x).IntAdd(5).VectorMull(b).VectorSub( c.FloatMull(y).VectorSub(d.IntDiv(5))).VectorDiv(e).VectorSub(z)
Мне почему ДЕФИС то кажется ЗАПЯТАЯ что использование операторов несколько повышает читабельность кода ЗАПЯТАЯ при этом не только минимизируя пространство ЗАПЯТАЯ но и приближая синтаксис выражение к более привычному виду ТОЧКА ПЕРЕВОД_КАТЕРКИ
КРАСНАЯ_СТРОКА Для меня кажется диким использование
foo.Equals(bar)
потому как
foo dot Equals leftBracket bar rightBracket
гораздо еффективнее выражает мысль и однозначно подчеркивает мнение автора о читатетеле в целом и его интеллекте в частности
Здравствуйте, Kh_Oleg, Вы писали:
K_O>>>"/" — это только divide. Тогда как в случае с методом я могу в имени отразить особенности реализации: SafeDivide, IntDivide, FloatDivide. WH>>учитывая то как правило нет ни каких SafeDivide, IntDivide, FloatDivide..., а есть только divide то какой смысл? K_O>Как правило они есть! Только неявные, что порождает еще массу ошибок. K_O>
K_O>int a = 1, b = 2;
K_O>double aa = 1, bb = 2;
K_O>
K_O>выражения a/b и aa/bb дадут сильно разные результаты.
Результаты не просто разные, а имеют разные типы. Тип результата определяется типом опрерандов, также как в выражениях 1 + 1 и "1" + "1".
S> А вот здесь уже дело привычки. То есть ты считаешь, S> что ассемблерная комада была бы предпочтительней в таком виде S> % EAX,ECX S> / EAX,ECX S> << EAX,ECX
Во-первых, ассемблер не предназначен для написания математических формул. А ЯВУ изначально предназначались именно для этого. И хотя С предназначен не только для этого, сведЕние его к ассемблеру не улучшит читаемости.
Во-вторых, если зашла речь об улучшении ассемблера, то гораздо понятнее была бы такая запись:
EAX = EAX + ECX
И между прочим, ассемблеры сигнальных процессоров выглядят именно так. Поскольку предназначены они исключительно для вычислений, их ассемблеры разработаны такими, чтобы программа максимально походила на математические формулы.
K_O>Как правило они есть! Только неявные, что порождает еще массу ошибок. K_O>
K_O>int a = 1, b = 2;
K_O>double aa = 1, bb = 2;
K_O>
Блин, как меня бесят эти рассуждения о том, что в программировании порождает ошибки! А кто-нибудь пытался привести статистику ошибок? Может вы боретесь с ветряными мельницами? Каких ошибок больше: целочисленного деления или выхода индекса за пределы массива? Для борьбы с ошибками придумываются средства, которые сами потом становятся источником еще более трудноуловимых ошибок. Как, например, здесь.
Чтобы делать меньше ошибок нужно одно: опыт. То есть нужно больше писать программ, а не рассуждать о том, какие новомодние средства нужно применить для уменьшения числа ошибок.
P.S. Не сочни за личный наезд. Это больше касается Страуструпа и STL
Здравствуйте, SWW, Вы писали:
S>> А вот здесь уже дело привычки. То есть ты считаешь, S>> что ассемблерная комада была бы предпочтительней в таком виде S>> % EAX,ECX S>> / EAX,ECX S>> << EAX,ECX
SWW>Во-первых, ассемблер не предназначен для написания математических формул. А ЯВУ изначально предназначались именно для этого. И хотя С предназначен не только для этого, сведЕние его к ассемблеру не улучшит читаемости.
SWW>Во-вторых, если зашла речь об улучшении ассемблера, то гораздо понятнее была бы такая запись: SWW>EAX = EAX + ECX SWW>И между прочим, ассемблеры сигнальных процессоров выглядят именно так. Поскольку предназначены они исключительно для вычислений, их ассемблеры разработаны такими, чтобы программа максимально походила на математические формулы.
Ради бога. B какой математической записи присутствуют <<>>^& и насколько они выразительнее shl,shr,xor, and.
Это общепринятые понятия побитовых и булевых операций.
Давай введем ы,ъ,ё для их обозначения.
Обучение программированию должно начинаться с ассемблера, а он в нормальном виде отвечает всем процессам происходящем в ЭВМ.
Зачем вводить то, что не соответству реалиям, т.к. на сигнальные процессоры мало кто использует, а стековая архитектура ближе к регистровой.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Kh_Oleg, Вы писали:
K_O>Его, но и он не всегда справляется. Мне всегда информации хватало.
K_O>Что такое выразительность ЯП на единицу кода?
Грубо говоря колличество логики которое можно уместить в одном килобайте кода без потери читабельности и расширяемости.
K_O>"Проблемы негров шерифа не колышут". Если нельзя написать просто, то почему сложность реализации рассматривается как достоинство?
Приччем тут сложно? Спирит простая либа но не возможноя на дельфе потомучто там нет шаблонов.
2Serginio1 генерики ни когда не будут обладать такой гибкостию.
K_O>Спорить здесь будем или сразу в "Священные войны"?
Здесь. Ибо оба форума флеймовые но тут с упором на программирование.
K_O>Да при том, что в ЯП ты предлагаешь операцию вычитания векторов обозначать символом "-". А операция-то не такая уж и простая...
И что? Следуя этой логике мы придум к тому что что операторы вобще использовать нельзя.
Тк сложить два DWORD'а операция болие сложная чем сложить два BYTE'а.
А сложение чисел с плавующей точкой это вобще агхи тижолая операция, а сложение чисел разных типов это вобще ужас ибо производится конвертация типов перед сложением.
А конкатинация строк это вобще явление из другой оперы и к математике не относися следовательно не может обазначаться оператором +. А если вспомнить что там происходит динамическое выделение памяти и копирование произвольного объема данных...
Итого: оператор + можно использовать только для BYTE'ов, а если его можно использовать только для одного типа то на кой он вобще нужен?
Я считаю что если для данного типа данных оператор ИНТУИТИВНО понятен то он должен быть перегружен.
Те в математике вектора складывают оператором + так почему в языке программирования ВЫСОКОГО уровня нельзя складывать вектора оператором +?
Зачем писать v=subtract(compose(subtract(compose(v1, v2), v3), v4), v5); когда можно написать v=v1+v2-v3+v4-v5;?
Взять тотже спирит там операторы перегружены так чтобы синтаксис был максимально близок к сантаксису EBNF и это очень удобно.
ЯВУ для того и придумали чтобы сложные вещи можно было написать просто. Дык зачем на ЯВУ писать сложно?
... << RSDN@Home 1.1.3 beta 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
K_O>>"Проблемы негров шерифа не колышут". Если нельзя написать просто, то почему сложность реализации рассматривается как достоинство? WH>Приччем тут сложно? Спирит простая либа но не возможноя на дельфе потомучто там нет шаблонов. WH>2Serginio1 генерики ни когда не будут обладать такой гибкостию.
Это не значит, что на Delphi этого нельзя сделать. По большому счету шаблоны нужны, но дженерики более читабельны.
А шаблонное программирование, это отдельная техника не для слабонервных оссобенно в С++ синтаксисе. Если смортеть на проект R# то он мне очень импонирует. Смотрим на развите паттернов и их развитие на примере тугеза. Развите Шаблонов должны идти в сторону читабельности и проверки кода на этапе кодирования. В том же виде в каком они сейчас далеки от идеала. Вступай в ряды R#. И я буду наслаждаться плодами твоего труда.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, WolfHound, Вы писали:
WH>Я считаю что если для данного типа данных оператор ИНТУИТИВНО понятен то он должен быть перегружен. WH>Те в математике вектора складывают оператором + так почему в языке программирования ВЫСОКОГО уровня нельзя складывать вектора оператором +?
Проблема в том, что глядя на запись в мат. нотации ты всегда отличаещь вектор от скаляра. Соотвтесвенно — сложно спутать операцию сложения скаляров, и сложение векторов.
А вот, например, для опреаций над множествами (отличить в мат. натации множество, от того же скаляра не так просто, как скаляр от вектора... согласитесь) введены специальные символы... Хотя, + в случае объеденения множеств, тоже весьма "ИНТУИТИВНО понятен"... наверное.
Здравствуйте, WolfHound, Вы писали:
WH>Я считаю что если для данного типа данных оператор ИНТУИТИВНО понятен то он должен быть перегружен. WH>Те в математике вектора складывают оператором + так почему в языке программирования ВЫСОКОГО уровня нельзя складывать вектора оператором +? WH>Зачем писать v=subtract(compose(subtract(compose(v1, v2), v3), v4), v5); когда можно написать v=v1+v2-v3+v4-v5;? WH>Взять тотже спирит там операторы перегружены так чтобы синтаксис был максимально близок к сантаксису EBNF и это очень удобно.
ИМХО принципиальной разницы между операторами и функциями нет вообще. Смысловая нагрузка у них минимальна. Единственная их функция — служить псевдонимом адреса в виртуальной таблице.
Операторы в некоторых случаях чуть более осмысленны, так как имеют устойчивое значение, соответствующее их значению в математике. Т.е. оператор "+" предполагает по крайней мере ассоциативность, оператор "-" — операцию, противоположну "+" и т.д. А вот функция "add" не имеет вообще никакой смысловой нагрузки и обозначать может что угодно.
Если говорить о "непринципиальных" отичиях, то использование слов помогает при знакомсве с новым средством/библиотекой. Но если ты уже "в теме", то обилие повторяющихся слов скорее мешает понять смысл всего выражения. Хотелось бы иметь возможность выбора между этими двумя представлениями.
Я сейчас работаю над моделью языка с глобально-уникальными идентификаторами в качестве терминалов. Т.е. языка, где элементарные элементы — не буквы, а понятия, смысл которых определен независимо от конкретного языка или библиотекии икоторые имеют каждый свой guid (аналогично интерфейсам COM).
Например, мы можем определить понятие "поток данных типа ..." как функцию, которая возвращает значение заданного типа либо понятие "конец потока".
При написании программы мы задаем, что слово, например, "datastream" соответствует понятию с guid "поток данных", а "streamend" — понятию "конец потока".
Тогда если мы видим в тексте выражение типа datastream int, то мы знаем, например, что он возвращает значение типа int либо streamend и ничего больше.
Более того, мы не только сами это видим, но и можем "рассказать" это средствам, которые работают с этим кодом. Например, система документирования кода может взять где-нибудь по guid полное описание понятия и использовать его при описании используюших его функций и объектов. Мы можем описывать методы, которые работают для всех функций типа datastream. И т.д.
Здравствуйте, WolfHound, Вы писали:
K_O>>Что такое выразительность ЯП на единицу кода? WH>Грубо говоря колличество логики которое можно уместить в одном килобайте кода без потери читабельности и расширяемости.
Ну а что такое "количество логики"?
Кстати, если этот вывод сделан только на основании необходимости писать begin-end и procedure, function, property, да Integer вместо int, то это не агрумент.
Здравствуйте, Kh_Oleg, Вы писали:
K_O>Кстати, если этот вывод сделан только на основании необходимости писать begin-end и procedure, function, property, да Integer вместо int, то это не агрумент.
Вспоминатеся, кстати:
Проанализировав статистику боев с японцами в 1941-1945 годах, американе обнаружили, что несмотря на равенство сил оные американе побеждали чаще. Причину нашли — в английском языке средняя длина слова — 5 букв, в японском 13. То есть пока японец объяснит что к чему, американе уже стреляют... После этого как раз появилась у американ привычка давать короткие названия-клички как своим так и чужим самолетам, кораблям и т.п. Когда эта информация дошла до русских, то они вычислили среднюю длину слова в русском языке — 7 букв...
А далее просто выписка из конспекта "Но! В процессе управления боем КОМАНДИР АВТОМАТИЧЕСКИ ПЕРЕХОДИТ НА МАТ, И ИНФОРМАТИВНОСТЬ РЕЧИ ВОЗРАСТАЕТ В 2-3 РАЗА
Здравствуйте, INTP_mihoshi, Вы писали:
INT>Здравствуйте, WolfHound, Вы писали:
INT>ИМХО принципиальной разницы между операторами и функциями нет вообще. Смысловая нагрузка у них минимальна. Единственная их функция — служить псевдонимом адреса в виртуальной таблице.
Гы... а Вы посмотрите на это с точки зрения нотации — множества символов и правил их применения, используемые для представления лексических единиц и их взаимоотношений. Разница, имхо, достаточно большая и наглядная.
INT>Операторы в некоторых случаях чуть более осмысленны, так как имеют устойчивое значение, соответствующее их значению в математике. Т.е. оператор "+" предполагает по крайней мере ассоциативность, оператор "-" — операцию, противоположну "+" и т.д. А вот функция "add" не имеет вообще никакой смысловой нагрузки и обозначать может что угодно.
Я бы сказал, что оператор — "фраза" языка, определяющая законченный этап (в отличие, например от "функции" — в "пределе" последовательности операторов). Применительно к программисткой нотации можно сказать, что в состав операторов, как операнды, входят (или, могут входить) данные, функции и т.п.
INT>Если говорить о "непринципиальных" отичиях, то использование слов помогает при знакомсве с новым средством/библиотекой. Но если ты уже "в теме", то обилие повторяющихся слов скорее мешает понять смысл всего выражения. Хотелось бы иметь возможность выбора между этими двумя представлениями.
Другими словами... чем больше операторов, тем легче читается, но труднее понимается... так что ли?! Или на оборот?! Имхо, что-то тут не то
INT>Я сейчас работаю над моделью языка с глобально-уникальными идентификаторами в качестве терминалов. Т.е. языка, где элементарные элементы — не буквы, а понятия, смысл которых определен независимо от конкретного языка или библиотекии икоторые имеют каждый свой guid (аналогично интерфейсам COM).
INT>Например, мы можем определить понятие "поток данных типа ..." как функцию, которая возвращает значение заданного типа либо понятие "конец потока".
INT>При написании программы мы задаем, что слово, например, "datastream" соответствует понятию с guid "поток данных", а "streamend" — понятию "конец потока". INT>Тогда если мы видим в тексте выражение типа datastream int, то мы знаем, например, что он возвращает значение типа int либо streamend и ничего больше.
Имхо, ничего принципиального в этом нет Определение — это определение... я и так определяя ф-цию — определяю тип возвращаемого ей значения. Проблема-то в том, что при использовании ф-ции тип возвращаемого значения не очевиден. В метематике такой проблемы просто нет, так как понятие (в нашем смысле) "типа" — нивелированно. А у нас, в частности, при перегрузке операторов возникает праблема идентификации записи вида: A = B() + C()... что бы четко представлять себе ЧТО реально делает "+" нужно знать какие типы возвращают B() и C().
INT>Более того, мы не только сами это видим, но и можем "рассказать" это средствам, которые работают с этим кодом. Например, система документирования кода может взять где-нибудь по guid полное описание понятия и использовать его при описании используюших его функций и объектов. Мы можем описывать методы, которые работают для всех функций типа datastream. И т.д.
Это может быть полезно... но только в приложении к интструментарию...
А так хочется, чтоб минимальным иструментарием были карандаш и листок бумаги
Здравствуйте, Kh_Oleg, Вы писали:
K_O>Ну а что такое "количество логики"?
Да то и значит. Что одно и тоже написать на С++ и на паскале то на С++ за счет грамотного использования шаблонов и макросов получается значительно компактней. K_O>Кстати, если этот вывод сделан только на основании необходимости писать begin-end и procedure, function, property, да Integer вместо int, то это не агрумент.
Ты меня за кого держишь? Я тебе не Вирт который на == ополчился...
Взять хотябы туже сортировку для произвольного типа данных. На дельфе возможен только полиморфный вариант, а это
1)Не удобно
2)Не безопасно
3)Медленней чем для конкретного типа
шаблонная сортировка этим не страдает. А размер бинарника сейчас ни кого не волнует.
... << RSDN@Home 1.1.3 beta 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
K_O>>Ну а что такое "количество логики"? WH>Да то и значит. Что одно и тоже написать на С++ и на паскале то на С++ за счет грамотного использования шаблонов и макросов получается значительно компактней. А размер бинарника сейчас ни кого не волнует.
Шаблоны — это автоматизированный Copy-Paste.
Может размер бинарника и не такая уж критическая вещь, но вот время линковки — это, по крайней мере, в нашем проекте, самое узкое место. А все из-за шаблонов и макросов...
Здравствуйте, Kh_Oleg, Вы писали:
K_O>Здравствуйте, WolfHound, Вы писали:
K_O>>>Что такое выразительность ЯП на единицу кода? WH>>Грубо говоря колличество логики которое можно уместить в одном килобайте кода без потери читабельности и расширяемости. K_O>Ну а что такое "количество логики"?
K_O>Кстати, если этот вывод сделан только на основании необходимости писать begin-end и procedure, function, property, да Integer вместо int, то это не агрумент.
Может быть WolfHound говорит о избыточности языка? Хотя вряд ли... к "кол-ву логики" это не одним боком...
А вообще, выразительность — понятие субъективное, имхо... т.к. связано с категориями понимания. С этой точки зрения С горазбо большее "убожество" чем Паскаль.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Kh_Oleg, Вы писали:
K_O>>Ну а что такое "количество логики"? WH>Да то и значит. Что одно и тоже написать на С++ и на паскале то на С++ за счет грамотного использования шаблонов и макросов получается значительно компактней.
Осмелюсь заметить, что такая "выразительность" — суть обратное.
K_O>>Кстати, если этот вывод сделан только на основании необходимости писать begin-end и procedure, function, property, да Integer вместо int, то это не агрумент. WH>Ты меня за кого держишь? Я тебе не Вирт который на == ополчился...
И правильно делает... Ну скажите мне... так ли трудно зтедать оператор "=" контекснто зависимым? Всмысле, в условном контексте это сравнение на равенство, в безусловном — присваивание. Хотя бы так (хотя в этом смысле, Паскалевское ":=" тоже не фонтан... это извиняет лишь то, что новый оператор ввели для НОВОГО понятия, а не стали эти понятия подменять... и это тоже гораздо более логичней и понятней, чем использование для сравнения оператора "==". Витр на это не пошел, хотя наверное прекрасно знает что присваивание используется гораздо чаще сравнения). Контекстную зависимость принять и понять гораздо легче, чем понять почему понятный до этого символ = (дефакто, интерпритирующийся как сравнение на равенство) не может использоваться для сравнения на равенство!!!
Но, опять же, Вирт в этой статье, не столько ратует за Паскаль, сколько сетует на то что для обучения программирования дефакто избран С.
Здравствуйте, Kh_Oleg, Вы писали:
K_O>Здравствуйте, WolfHound, Вы писали:
K_O>>>Ну а что такое "количество логики"? WH>>Да то и значит. Что одно и тоже написать на С++ и на паскале то на С++ за счет грамотного использования шаблонов и макросов получается значительно компактней. А размер бинарника сейчас ни кого не волнует. K_O>Шаблоны — это автоматизированный Copy-Paste. K_O>Может размер бинарника и не такая уж критическая вещь, но вот время линковки — это, по крайней мере, в нашем проекте, самое узкое место. А все из-за шаблонов и макросов...
Ерунду несете. На время линковки шаблоны и т.б. макросы никак не влияют. И вообщем-то на скорость компиляции тоже. То что у вас что-то тормозит это следствие плохой изоляции. Там где надо сделать опережающее описание:
class Foo;
делается:
#include"Foo.h"
Небольшее изменение и все пересобирается.
По моему опыту шаблоны, при их грамотном употреблении, не влияют существенно на скорость компиляции. Все проблемы со скоростью компиляции/линковки исключительно результат криворукости.
Мне всегда информации хватало.
Определение — это определение... я и так определяя ф-цию — определяю тип возвращаемого ей значения. Проблема-то в том, что при использовании ф-ции тип возвращаемого значения не очевиден. В метематике такой проблемы просто нет, так как понятие (в нашем смысле) "типа" — нивелированно. А у нас, в частности, при перегрузке операторов возникает праблема идентификации записи вида: A = B() + C()... что бы четко представлять себе ЧТО реально делает "+" нужно знать какие типы возвращают B() и C(). 
