Здравствуйте, OdesitVadim, Вы писали: AKh>>>>Имхо тут надо различать оператор деления языка и математический оператор деления. Вы сравниваете совсем разные понятия. OV>>>Ок. вот я и не понимаю: зачем плодить сущности? AKh>>Как сказал Саттер с Александреску "Предпочитайте минимальные классы монолитным". OV>Непонял, причем это здесь
У меня "сущность" автоматически ассоциировалась с классом.
AKh>>Моя точка зрения такая (попробую быть последовательным): AKh>>Оператор деления языка можно "отнаследовать" от математического, т.к. он выполняет те же функции. OV> Как кто то с класиков тоже сказал, унаследованный класс не должен изменять сущность базового. Кто то на этом форуме с сишников кричал мне что наследование — ужос.
Да, должна быть композиция.
[...]
AKh>>Это и является обоснованием рациональности ввода 2-х типов операций деления. OV>Но я бы оставил для целого деления симпол "\" и всё. Тоесть
Как вариант. Но это уже другая тема — синтаксис языка.
OV>3/2 = 1.5 OV>3\2 = 1 OV>3.0/2 = 1.5 OV>3.0\2 = 1 (или 1.0?) Вот здесь я бы задумался, наверно ругаться надо, так как 3.4\2 я сложно представляю OV>таким образом всё было бы по местам.
Думаю, расстановкой приоритетов (тип аргументов или тип оператора) эти проблемы бы решились.
А можно, кстати, не расстановкой приоритетов, а вернуться к вопросу о преобразовании типов, с которого это началось. Если считать, что типом результата должнен руководить оператор, то 3.0\2 = 1 останется однозначно верным. Но встает другой ворос, а 1 — это int или long? Тогда типом результата должен быть один из операторов. Логично взять делимое. Тогда 3.0\2 = 1.0 — верно. Неявное преоразование типов отсутсвует (на расширения (int*int=long) не будем обращать внимание).
Что же делает С++? Неявное преобразование типов отсутсвует. Даже, если взять пример 3/2 = 1.5. Здесь целый аргумент преобразуется в вещественный, что не способствует точности отсутсвия неявного преобразования. С++ как раз решает эту проблему. Так что на счет примера неявного преобразования
OV>А вы все настройки варнингов включили? там почему то по умолчанию UnSafe операции не отмечены. Для меня варнинги — ошибки, так как это потенциальные ошибки. OV>В младших версиях за такое сразу получал по шапке. Куда мир котиться. Жаль по рукой нет 3 делфи.
Буду благодарен если скажите где это найти, ибо искал долго, но судя повсему плохо искал. Также жалею что в Делфе нету опции интерпретировать ворнинг как ошибку.
Здравствуйте, AKh, Вы писали:
AKh>А можно, кстати, не расстановкой приоритетов, а вернуться к вопросу о преобразовании типов, с которого это началось. Если считать, что типом результата должнен руководить оператор, то 3.0\2 = 1 останется однозначно верным. Но встает другой ворос, а 1 — это int или long? Тогда типом результата должен быть один из операторов. Логично взять делимое. Тогда 3.0\2 = 1.0 — верно. Неявное преоразование типов отсутсвует (на расширения (int*int=long) не будем обращать внимание).
согласен. Где то так и я мыслю. AKh>Что же делает С++? Неявное преобразование типов отсутсвует. Даже, если взять пример 3/2 = 1.5. Здесь целый аргумент преобразуется в вещественный, что не способствует точности отсутсвия неявного преобразования. С++ как раз решает эту проблему. Так что на счет примера неявного преобразования
вы все таки не правы.
подождите, в С++ 3/2 = 1.5???
Только что проверял на компиляторе — нет, 1, так как и положено языку. Или Великий Стандарт думает по другому уже и компилятор не показатель???
Здравствуйте, OdesitVadim, Вы писали:
AKh>>Что же делает С++? Неявное преобразование типов отсутсвует. Даже, если взять пример 3/2 = 1.5. Здесь целый аргумент преобразуется в вещественный, что не способствует точности отсутсвия неявного преобразования. С++ как раз решает эту проблему. Так что на счет примера неявного преобразования
вы все таки не правы. OV>подождите, в С++ 3/2 = 1.5??? OV>Только что проверял на компиляторе — нет, 1, так как и положено языку. Или Великий Стандарт думает по другому уже и компилятор не показатель???
Вы меня не правельно поняли. 3/2 = 1.5, как и предыдущий пример взят из вашего контекста (с оператором \). Я даже отметил, что здесь "аргумент преобразуется в вещественный", а "С++ как раз решает эту проблему", т.е. в С++ все как и было спланировано (т.е. у него, в данном случае, получается, что тип результата — тип делимого).
Здравствуйте, vasmann, Вы писали:
OV>>А вы все настройки варнингов включили? там почему то по умолчанию UnSafe операции не отмечены. Для меня варнинги — ошибки, так как это потенциальные ошибки. OV>>В младших версиях за такое сразу получал по шапке. Куда мир котиться. Жаль по рукой нет 3 делфи.
V>Буду благодарен если скажите где это найти, ибо искал долго, но судя повсему плохо искал. Также жалею что в Делфе нету опции интерпретировать ворнинг как ошибку.
Вот как интерпретировать ворнинг как ошибку я не знаю. Я просто привык убирать все ворнинги и хинты. Полностью. Даже хинт — потенциальный глюк в будущем. Но бывают случаи, когда я всё таки не согласен с компилятором. Тогда я явно ставлю Отключение ворнингов на данную строку с припиской почему.
Это у меня выглядит так:
{$WARNINGS OFF}//обяснения, почему здесь. обычно это TODO.
//Палённая строка
{$WARNINGS ON}
Включить дополнительные варнинги надо так.
Project-Options...-Compiler messages должны все галочки стоять, кроме "Default"
Вкладка Compiler. "Typed @ operator" — сразу забудет о многих странных преобразованиях.
"Assignable type constants" должна быть снята.
"Stack frame" лучше поставить — преобразования это не исправит, но для отладки — очень помогает — отладчик начинает видеть значения параметров в окне "Call stack"
Здравствуйте, AKh, Вы писали:
AKh>Вы меня не правельно поняли. 3/2 = 1.5, как и предыдущий пример взят из вашего контекста (с оператором \). Я даже отметил, что здесь "аргумент преобразуется в вещественный", а "С++ как раз решает эту проблему", т.е. в С++ все как и было спланировано (т.е. у него, в данном случае, получается, что тип результата — тип делимого).
AKh>Извенясь, если не достаточно подробно изложил.
А я уже испугался, что стандарт поменяли.
V>Не знаю чего, но вот Complier-messages это наверно единственное куда я не лазил — и как окозалось зря.
Что-то я не могу найти такую вкладку. Delphi6.
Здравствуйте, OdesitVadim, Вы писали:
OV>>>А вот создателей Си/С++ за результат выражения 3/2 расстрелял. очень сложно логике здравой поддаётся. (ну мож на процессорах и понятно, но в нормальной жизни...) V>>Все очень здраво — свои намерения выражайте явно а не неявно V>>3/2 — это деление двух целых OV>Да, но скажи это в школе или институте. Они пальчиком у виска покрутят. Только Сипрограммеры и им подобные понимают эту "особенность"
В каждом языке свой устав. Некоторые покрутят пальчиком у скрепыша в экселе: почему 2+2*2 = 6, когда на калькуляторе получается 8?
OV>Ведь если 3 яблока на двоих делить, то куда ещё одно денеться?
А в Хаскелле результат 3/2 — это Frac a => a. Попытка скормить Int или Integer в любую часть выражения — компилятор надаёт по рукам. И правильно: делить можно только то, что делится. Яблоки — можно (ножом). Болты — нельзя (даже ножовкой: это уже будут не болты, а металлолом).
Здравствуйте, ., Вы писали:
.>OdesitVadim wrote:
>> Да, но скажи это в школе или институте. Они пальчиком у виска покрутят. .>А что скажешь насчёт sqrt(-5)?
В фортране (язык математиков?) всё было просто. там это работало, если указать что числа комплексные.
В Си/Паскале во время выполнения выскочит ошибка, которую можно перевести как "Не знаю как это сделать.". Согласитесь, это разные вещи, когда программа говорит, что она не знает/не умеет и когда она по "дивным" правилам (по "дивным", потомучто одним они просты, другим — дики, третим совсем непонятно, но все более-менее смирились)
Но и в Си++, и в Делфи (начиная с 2005) можно обявить свой тип а ля TComplex, определить для него действия и вуаля. Всё так как ожидается (потому что сам определял
Кстати, для делфи такой модуль почти в стандартной поставке.
Здравствуйте, OdesitVadim, Вы писали:
OV>Здравствуйте, ., Вы писали:
.>>OdesitVadim wrote:
>>> Да, но скажи это в школе или институте. Они пальчиком у виска покрутят. .>>А что скажешь насчёт sqrt(-5)? OV>В фортране (язык математиков?) всё было просто. там это работало, если указать что числа комплексные.
OV>В Си/Паскале во время выполнения выскочит ошибка, которую можно перевести как "Не знаю как это сделать.". Согласитесь, это разные вещи, когда программа говорит, что она не знает/не умеет и когда она по "дивным" правилам (по "дивным", потомучто одним они просты, другим — дики, третим совсем непонятно, но все более-менее смирились)
OV>Но и в Си++, и в Делфи (начиная с 2005) можно обявить свой тип а ля TComplex, определить для него действия и вуаля. Всё так как ожидается (потому что сам определял OV>Кстати, для делфи такой модуль почти в стандартной поставке.
Только вот беда, нет перегруженных операторов. И по этому вместо привычных +-*/ нужно писать дивные не математические фразы
add, sub, mult, div... Вы сами своим словам противоречите.
В одном месте вам не привычно, а другом то что не привычно — привычно — определитесь уже.
Здравствуйте, vasmann, Вы писали:
V>Только вот беда, нет перегруженных операторов. И по этому вместо привычных +-*/ нужно писать дивные не математические фразы V>add, sub, mult, div... Вы сами своим словам противоречите.
Отстали от жизни. Всё есть. V>В одном месте вам не привычно, а другом то что не привычно — привычно — определитесь уже.
Различайте моё отношение и отношение других. Мне чудно, но привык. Другим это абсолютно нормально. Другим нет.
Здравствуйте, OdesitVadim, Вы писали:
OV>Здравствуйте, vasmann, Вы писали:
V>>Только вот беда, нет перегруженных операторов. И по этому вместо привычных +-*/ нужно писать дивные не математические фразы V>>add, sub, mult, div... Вы сами своим словам противоречите. OV>Отстали от жизни. Всё есть.
В делфе можно перегужать операторы? Или это фича только для комплексных? Если последнее — мне это не представляет никакой ценности, ибо комплексные числа не нужны (мне, пока что
V>>В одном месте вам не привычно, а другом то что не привычно — привычно — определитесь уже. OV>Различайте моё отношение и отношение других. Мне чудно, но привык. Другим это абсолютно нормально. Другим нет.
А в чем проблема? Ну чудно? Ну нормально? Что тут не так? Мы ж документацию читаем на английском и не лезем им в их язык с заявками типа — чудной у вас язык, нет, в чем проблема тогда с языками программирования? Выучил правила, и все, не волнует тебе чудно или нет — применяй свои знания. Не нравится — велкам туда — где не чудно. Проще нужно относиться к жизни.
Блин, вообще тема ушла в жесткий оффтоп — зато прикольно.
Здравствуйте, vasmann, Вы писали:
V>В делфе можно перегужать операторы? Или это фича только для комплексных? Если последнее — мне это не представляет никакой ценности, ибо комплексные числа не нужны (мне, пока что
Можно. +-/* точно можно. Нужно просто обявить новую запись (record) и добавить процедуры, которые будут собственно осуществлять действия.
я думаю это развеит ваши неведанья.
type
TComplex = packed record
strict private
procedure Defuzz;
private
class procedure Init; static;
public
var
Real, Imaginary: Double;
class var
Symbol: string; // defaults to 'i'
SymbolBeforeImaginary: Boolean; // defaults to false
DefuzzAtZero: Boolean; // defaults to trueclass operator Round(const AValue: TComplex): Int64;
class operator Trunc(const AValue: TComplex): Int64;
class operator Equal(const Left, Right: TComplex): Boolean;
class operator NotEqual(const Left, Right: TComplex): Boolean;
class operator LessThan(const Left, Right: TComplex): Boolean;
class operator LessThanOrEqual(const Left, Right: TComplex): Boolean;
class operator GreaterThan(const Left, Right: TComplex): Boolean;
class operator GreaterThanOrEqual(const Left, Right: TComplex): Boolean;
class operator Add(const Left, Right: TComplex): TComplex;
class operator Subtract(const Left, Right: TComplex): TComplex;
class operator Multiply(const Left, Right: TComplex): TComplex;
class operator Divide(const Left, Right: TComplex): TComplex;
class operator Negative(const AValue: TComplex): TComplex;
// Note: currently Implicit operators work like Explicit operators in Win32,
// i.e. they need an explicit type-castclass operator Implicit(const AValue: Double): TComplex;
class operator Implicit(const AValue: Integer): TComplex;
class operator Implicit(const AValue: Int64): TComplex;
class operator Implicit(const AValue: Variant): TComplex;
class operator Explicit(const AValue: TComplex): Double;
class operator Explicit(const AValue: TComplex): Integer;
class operator Explicit(const AValue: TComplex): Int64;
end;
И как пример, реализация некоторых из них.
class function TComplex.From(const AReal, AImaginary: Double): TComplex;
begin
Result.Real := AReal;
Result.Imaginary := AImaginary;
if DefuzzAtZero then
Result.Defuzz;
end;
class operator TComplex.Add(const Left, Right: TComplex): TComplex;
begin
Result := From(Left.Real + Right.Real, Left.Imaginary + Right.Imaginary);
end;
class operator TComplex.Subtract(const Left, Right: TComplex): TComplex;
begin
Result := From(Left.Real - Right.Real, Left.Imaginary - Right.Imaginary);
end;
class operator TComplex.Multiply(const Left, Right: TComplex): TComplex;
begin
Result := From((Left.Real * Right.Real) - (Left.Imaginary * Right.Imaginary),
(Left.Real * Right.Imaginary) + (Left.Imaginary * Right.Real));
end;
Здравствуйте, OdesitVadim, Вы писали:
OV>Здравствуйте, vasmann, Вы писали:
V>>В делфе можно перегужать операторы? Или это фича только для комплексных? Если последнее — мне это не представляет никакой ценности, ибо комплексные числа не нужны (мне, пока что OV>Можно. +-/* точно можно. Нужно просто обявить новую запись (record) и добавить процедуры, которые будут собственно осуществлять действия. OV>я думаю это развеит ваши неведанья. OV>
OV>type
OV> TComplex = packed record
OV> strict private
OV> procedure Defuzz;
OV> private
OV> class procedure Init; static;
OV> public
OV> var
OV> Real, Imaginary: Double;
OV> class var
OV> Symbol: string; // defaults to 'i'
OV> SymbolBeforeImaginary: Boolean; // defaults to false
OV> DefuzzAtZero: Boolean; // defaults to true
OV> class operator Round(const AValue: TComplex): Int64;
OV> class operator Trunc(const AValue: TComplex): Int64;
OV> class operator Equal(const Left, Right: TComplex): Boolean;
OV> class operator NotEqual(const Left, Right: TComplex): Boolean;
OV> class operator LessThan(const Left, Right: TComplex): Boolean;
OV> class operator LessThanOrEqual(const Left, Right: TComplex): Boolean;
OV> class operator GreaterThan(const Left, Right: TComplex): Boolean;
OV> class operator GreaterThanOrEqual(const Left, Right: TComplex): Boolean;
OV> class operator Add(const Left, Right: TComplex): TComplex;
OV> class operator Subtract(const Left, Right: TComplex): TComplex;
OV> class operator Multiply(const Left, Right: TComplex): TComplex;
OV> class operator Divide(const Left, Right: TComplex): TComplex;
OV> class operator Negative(const AValue: TComplex): TComplex;
OV> // Note: currently Implicit operators work like Explicit operators in Win32,
OV> // i.e. they need an explicit type-cast
OV> class operator Implicit(const AValue: Double): TComplex;
OV> class operator Implicit(const AValue: Integer): TComplex;
OV> class operator Implicit(const AValue: Int64): TComplex;
OV> class operator Implicit(const AValue: Variant): TComplex;
OV> class operator Explicit(const AValue: TComplex): Double;
OV> class operator Explicit(const AValue: TComplex): Integer;
OV> class operator Explicit(const AValue: TComplex): Int64;
OV> end;
OV>
Круто, хоть что-то чем нечего .
Но это же не полноценная перегрузка операторов. Так что тоже не то. Но как уже сказал — лучше чем ничего. Просто со стороны бормана наблюдается такая тенденция, как в анегдоте про обезьяну — я и умная и красивая, но не разорваться же мне, городят что попало, шоб було а практического применения кроме как комплексных чисел я не вижу. Возможно кто то матрицы будет этим крутить, вертеть, но тогда все равно нужно будет иметь что то типа вроперов — перевода класса в структуру и по структуре создание рекорда — в общем это не то, и без этого я мог жить и жить смогу.
На самом деле, лично для мен Система Типов стоит важнее кастрированных операторов.
Здравствуйте, vasmann, Вы писали:
V>Круто, хоть что-то чем нечего .
Ну а вы так хотели, что бы у нас было на уровне 90. V>Но это же не полноценная перегрузка операторов. Так что тоже не то.
А что не хватает? V>Но как уже сказал — лучше чем ничего. Просто со стороны бормана наблюдается такая тенденция, как в анегдоте про обезьяну — я и умная и красивая, но не разорваться же мне, городят что попало, шоб було а практического применения кроме как комплексных чисел я не вижу. Возможно кто то матрицы будет этим крутить, вертеть, но тогда все равно нужно будет иметь что то типа вроперов — перевода класса в структуру и по структуре создание рекорда — в общем это не то, и без этого я мог жить и жить смогу.
V>На самом деле, лично для мен Система Типов стоит важнее кастрированных операторов.
Здравствуйте, vasmann, Вы писали:
V>Я не удивлюсь если они прикрутят еще "недо-шаблоны" к Делфе, это будет нечто.
Мое мнение — все грабли растут из референсной модели. И даже чего т омне кажется что сделали ее не из-за того что она какие то плюсы несет в себе (ну вот хоть убейте, не вижу я преимущества в том что мне в каждой функции писать такое:
begin
myFavoriteObject := TMyFavoriteObject.Create(args);
try
.....
finally
myFavoriteObject.free;
end;
Мне все больше кажется что эту модель выбрали просто насло С++ — типа хоть чемто будет отличаться, в то время как в С++ мы имеем все механизмы нам необходимые
нужна ссылка? Получите &.
нужен поинтер на обеькт — получите и распишитесь
нужен обьект который урет при разрушении стека — получите.
И отсюда ж сколько прелестей вытекает.
Здравствуйте, OdesitVadim, Вы писали:
OV>Здравствуйте, vasmann, Вы писали:
V>>Круто, хоть что-то чем нечего . OV>Ну а вы так хотели, что бы у нас было на уровне 90.
А вы считаете граблявое, костылявое решение лучше заранее заложенного элегантного в язык?
Я нет.
Вы считаете что та перегрузка операторов которую смогли вкрутить/ввертеть борманци в делфи это та перегрузка которую дает стандарт С++? Не смешите.
Как я уже отписался выше — все кривости растут из референсной модели которая ничего, не то чтобы ничего а ВООБЩЕ НИЧЕГО положительно в себе не несет, кроме как гемороя. Но это ж раздел уже священных воин.
И главное — с этим можно жить и как не странно можно програмить.
Перекуём баги на фичи!
