Сообщение Re[20]: Комплексные числа от 14.02.2022 14:07
Изменено 14.02.2022 14:12 vdimas
Re[20]: Комплексные числа
Здравствуйте, T4r4sB, Вы писали:
TB>Никто не применяет [] к итератору, это тупо опасно, легко выскочить за диапазон.
На это я уже отвечал:
https://en.cppreference.com/w/cpp/ranges/view_interface/operator_at
Просто взгляни внимательней на описание.
TB>Да, примерно так, только символов можно поменьше. Типа isBetween(a, 0, b);
Пока что использование статических классов как неймспейсов особо не прижилось, кроме известных стандартных классов, типа Console.
И это правильно, ИМХО, т.к. из-за легаси прошлых лет не сложилась система абстрактных/шаблонных свободных ф-ий и не устоялось их "стандартное" именование, как в плюсах.
Во многом из-за того, что вычисления/сравнение и т.д. над типами-числами нельзя было описывать естественным образом через генерики.
Теперь стало можно, но это вот только что.
Теперь должно пройти много лет, чтобы новые практики стали мейнстримом, обрастя по дороге новыми соглашениями и прочими правилами хорошего тона.
Ну и, реализация для случая 0, b может быть самой дешевой, т.е. надо как-то иначе называть, типа MyCoolComparer.CheckIndex(index, size);
V>>Плюс для шарпа надо расписать комбинаторику сочетаний целочисленных типов в сигнатурах в конкретных типах.
TB>Не понял, поясни
Речь идёт о сравнении потенциально разных типов данных.
Соответственно, нужны сочетания сигнатур для знаковых/беззнаковых и для разной ширины бит, т.е. потребуется написать несколько перезагрузок ф-ии CheckIndex.
Теперь сравни с тем, что для "экосистемы" беззнаковых размеров, если опуститься на уровень встроенных массивов, то всё работает изкаробки.
На худой конец есть еще встроенные ср-ва — способ приведения беззнакового к знаковому описан в стандарте, и в аппаратуре ничего не стоит. Но обратное приведение специфировано лишь для неполного множества значений и его вообще рекомендуется избегать.
Это то, почему построить беззнаковую экосистему поверх навязанной знаковой гемморойно и вряд ли имеет смысл.
Зато если самому с 0-ля разработать под себя контейнеры, то всё выглядит вполне стройно.
Потому что вот так можно:
А тут ошибка компиляции, требуется явное приведение к знаковому:
Понятно, что все приведенные контра относительно слабы и пахнут разве что небольшим геммороем, но зачем это для случая, скажем, когда я использую самописные контейнеры, выполненные как value-type, и оперирую в операциях чаще, спанами, чем GC-ссылками на классы-контейнеры?
Плюс сам шарп представляет из себя такую экосистему, где можно и нужно избегать "синтаксического оверхеда" и прочего лишнего мусора/телодвижений в коде, иначе зачем он вообще? ))
Сегодня шарп даёт много для этого даже для случая расписывания собственной экосистемы эффективных контейнеров с 0-ля.
Например, даже если value-type контейнер необходимо передавать по ссылке, то последние версии шарпа и тут помогли:
Затем при вызове указывать in не обязательно, в отличие от ref.
На всяк случай in означает read-only ссылку и, соответственно, я могу вызывать только readonly-методы контейнера.
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-8.0/readonly-instance-members
Что тоже привносит хоть какую-то строгость в код — я могу распространять по цепочке вызовов константность ссылочных аргументов, типа как в С++.
А необходимость при вызове модифицирующих ф-ий подставлять ref я вообще приветствую — в плюсах мне чего-то подобного не хватает.
Такие модифицирующие ф-ии редки и должны обращать на себя внимание программиста.
Одно пока мест неудобно — для value-типов нельзя определить конструктор копирования, поэтому в коде надо следить, чтобы ненароком не скопировать такой контейнер в обычную переменную. Хотя, и в плюсах копирование контейнера чаще указывает на ошибку, но в плюсах хоть можно наследоваться/агрегировать и в своём типе уже запретить оператор и конструктор копирования... Но зато как в плюсах можно копировать ссылку на свои value-типы, сверху в пол-тыка пишется маленькая обвязка для реализации std.move (оно именно так у меня и называется), в общем, на данном этапе развития шарпа жить уже хоть как-то можно. ))
TB>Никто не применяет [] к итератору, это тупо опасно, легко выскочить за диапазон.
На это я уже отвечал:
https://en.cppreference.com/w/cpp/ranges/view_interface/operator_at
Просто взгляни внимательней на описание.
TB>Да, примерно так, только символов можно поменьше. Типа isBetween(a, 0, b);
Пока что использование статических классов как неймспейсов особо не прижилось, кроме известных стандартных классов, типа Console.
И это правильно, ИМХО, т.к. из-за легаси прошлых лет не сложилась система абстрактных/шаблонных свободных ф-ий и не устоялось их "стандартное" именование, как в плюсах.
Во многом из-за того, что вычисления/сравнение и т.д. над типами-числами нельзя было описывать естественным образом через генерики.
Теперь стало можно, но это вот только что.
Теперь должно пройти много лет, чтобы новые практики стали мейнстримом, обрастя по дороге новыми соглашениями и прочими правилами хорошего тона.
Ну и, реализация для случая 0, b может быть самой дешевой, т.е. надо как-то иначе называть, типа MyCoolComparer.CheckIndex(index, size);
V>>Плюс для шарпа надо расписать комбинаторику сочетаний целочисленных типов в сигнатурах в конкретных типах.
TB>Не понял, поясни
Речь идёт о сравнении потенциально разных типов данных.
Соответственно, нужны сочетания сигнатур для знаковых/беззнаковых и для разной ширины бит, т.е. потребуется написать несколько перезагрузок ф-ии CheckIndex.
Теперь сравни с тем, что для "экосистемы" беззнаковых размеров, если опуститься на уровень встроенных массивов, то всё работает изкаробки.
На худой конец есть еще встроенные ср-ва — способ приведения беззнакового к знаковому описан в стандарте, и в аппаратуре ничего не стоит. Но обратное приведение специфировано лишь для неполного множества значений и его вообще рекомендуется избегать.
Это то, почему построить беззнаковую экосистему поверх навязанной знаковой гемморойно и вряд ли имеет смысл.
Зато если самому с 0-ля разработать под себя контейнеры, то всё выглядит вполне стройно.
Потому что вот так можно:
int[] arr = {1, 2, 3};
ulong i = 2; // uint i
Console.WriteLine (arr[i]);А тут ошибка компиляции, требуется явное приведение к знаковому:
List<int> arr = new List<int> () {1, 2, 3};
ulong i = 2; // uint i
Console.WriteLine (arr[i]);Понятно, что все приведенные контра относительно слабы и пахнут разве что небольшим геммороем, но зачем это для случая, скажем, когда я использую самописные контейнеры, выполненные как value-type, и оперирую в операциях чаще, спанами, чем GC-ссылками на классы-контейнеры?
Плюс сам шарп представляет из себя такую экосистему, где можно и нужно избегать "синтаксического оверхеда" и прочего лишнего мусора/телодвижений в коде, иначе зачем он вообще? ))
Сегодня шарп даёт много для этого даже для случая расписывания собственной экосистемы эффективных контейнеров с 0-ля.
Например, даже если value-type контейнер необходимо передавать по ссылке, то последние версии шарпа и тут помогли:
void SomeOperation<T>(in vector<T> vec)Затем при вызове указывать in не обязательно, в отличие от ref.
На всяк случай in означает read-only ссылку и, соответственно, я могу вызывать только readonly-методы контейнера.
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-8.0/readonly-instance-members
Что тоже привносит хоть какую-то строгость в код — я могу распространять по цепочке вызовов константность ссылочных аргументов, типа как в С++.
А необходимость при вызове модифицирующих ф-ий подставлять ref я вообще приветствую — в плюсах мне чего-то подобного не хватает.
Такие модифицирующие ф-ии редки и должны обращать на себя внимание программиста.
Одно пока мест неудобно — для value-типов нельзя определить конструктор копирования, поэтому в коде надо следить, чтобы ненароком не скопировать такой контейнер в обычную переменную. Хотя, и в плюсах копирование контейнера чаще указывает на ошибку, но в плюсах хоть можно наследоваться/агрегировать и в своём типе уже запретить оператор и конструктор копирования... Но зато как в плюсах можно копировать ссылку на свои value-типы, сверху в пол-тыка пишется маленькая обвязка для реализации std.move (оно именно так у меня и называется), в общем, на данном этапе развития шарпа жить уже хоть как-то можно. ))
Re[20]: Комплексные числа
Здравствуйте, T4r4sB, Вы писали:
TB>Никто не применяет [] к итератору, это тупо опасно, легко выскочить за диапазон.
На это я уже отвечал:
https://en.cppreference.com/w/cpp/ranges/view_interface/operator_at
Просто взгляни внимательней на описание.
TB>Да, примерно так, только символов можно поменьше. Типа isBetween(a, 0, b);
Пока что использование статических классов как неймспейсов особо не прижилось, кроме известных стандартных классов, типа Console.
И это правильно, ИМХО, т.к. из-за легаси прошлых лет не сложилась система абстрактных/шаблонных свободных ф-ий и не устоялось их "стандартное" именование, как в плюсах.
Во многом из-за того, что вычисления/сравнение и т.д. над типами-числами нельзя было описывать естественным образом через генерики.
Теперь стало можно, но это вот только что.
Теперь должно пройти много лет, чтобы новые практики стали мейнстримом, обрастя по дороге новыми соглашениями и прочими правилами хорошего тона.
Ну и, реализация для случая 0, b может быть самой дешевой, т.е. надо как-то иначе называть, типа MyCoolComparer.CheckIndex(index, size);
V>>Плюс для шарпа надо расписать комбинаторику сочетаний целочисленных типов в сигнатурах в конкретных типах.
TB>Не понял, поясни
Речь идёт о сравнении потенциально разных типов данных.
Соответственно, нужны сочетания сигнатур для знаковых/беззнаковых и для разной ширины бит, т.е. потребуется написать несколько перезагрузок ф-ии CheckIndex.
Теперь сравни с тем, что для "экосистемы" беззнаковых размеров, если опуститься на уровень встроенных массивов, то всё работает изкаробки.
На худой конец есть еще встроенные ср-ва — способ приведения беззнакового к знаковому описан в стандарте, и в аппаратуре ничего не стоит. Но обратное приведение специфировано лишь для неполного множества значений и его вообще рекомендуется избегать.
Это то, почему построить беззнаковую экосистему поверх навязанной знаковой гемморойно и вряд ли имеет смысл.
Зато если самому с 0-ля разработать под себя контейнеры, то всё выглядит вполне стройно.
Потому что вот так можно:
А тут ошибка компиляции, требуется явное приведение к знаковому:
Понятно, что все приведенные контра относительно слабы и пахнут разве что небольшим геммороем, но зачем это для случая, скажем, когда я использую самописные контейнеры, выполненные как value-type, и оперирую в операциях чаще спанами, чем GC-ссылками на классы-контейнеры?
Плюс сам шарп представляет из себя такую экосистему, где можно и нужно избегать "синтаксического оверхеда" и прочего лишнего мусора/телодвижений в коде, иначе зачем он вообще? ))
Сегодня шарп даёт много для этого даже для случая расписывания собственной экосистемы эффективных контейнеров с 0-ля.
Например, даже если value-type контейнер необходимо передавать по ссылке, то последние версии шарпа и тут помогли:
Затем при вызове указывать in не обязательно, в отличие от ref.
На всяк случай in означает read-only ссылку и, соответственно, я могу вызывать только readonly-методы контейнера.
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-8.0/readonly-instance-members
Что тоже привносит хоть какую-то строгость в код — я могу распространять по цепочке вызовов константность ссылочных аргументов, типа как в С++.
А необходимость при вызове модифицирующих ф-ий подставлять ref я вообще приветствую — в плюсах мне чего-то подобного не хватает.
Такие модифицирующие ф-ии редки и должны обращать на себя внимание программиста.
Одно пока мест неудобно — для value-типов нельзя определить конструктор копирования, поэтому в коде надо следить, чтобы ненароком не скопировать такой контейнер в обычную переменную. Хотя, и в плюсах копирование контейнера чаще указывает на ошибку, но в плюсах хоть можно наследоваться/агрегировать и в своём типе уже запретить оператор и конструктор копирования... Но зато как в плюсах можно копировать ссылку на свои value-типы, сверху в пол-тыка пишется маленькая обвязка для реализации std.move (оно именно так у меня и называется), в общем, на данном этапе развития шарпа жить уже хоть как-то можно. ))
TB>Никто не применяет [] к итератору, это тупо опасно, легко выскочить за диапазон.
На это я уже отвечал:
https://en.cppreference.com/w/cpp/ranges/view_interface/operator_at
Просто взгляни внимательней на описание.
TB>Да, примерно так, только символов можно поменьше. Типа isBetween(a, 0, b);
Пока что использование статических классов как неймспейсов особо не прижилось, кроме известных стандартных классов, типа Console.
И это правильно, ИМХО, т.к. из-за легаси прошлых лет не сложилась система абстрактных/шаблонных свободных ф-ий и не устоялось их "стандартное" именование, как в плюсах.
Во многом из-за того, что вычисления/сравнение и т.д. над типами-числами нельзя было описывать естественным образом через генерики.
Теперь стало можно, но это вот только что.
Теперь должно пройти много лет, чтобы новые практики стали мейнстримом, обрастя по дороге новыми соглашениями и прочими правилами хорошего тона.
Ну и, реализация для случая 0, b может быть самой дешевой, т.е. надо как-то иначе называть, типа MyCoolComparer.CheckIndex(index, size);
V>>Плюс для шарпа надо расписать комбинаторику сочетаний целочисленных типов в сигнатурах в конкретных типах.
TB>Не понял, поясни
Речь идёт о сравнении потенциально разных типов данных.
Соответственно, нужны сочетания сигнатур для знаковых/беззнаковых и для разной ширины бит, т.е. потребуется написать несколько перезагрузок ф-ии CheckIndex.
Теперь сравни с тем, что для "экосистемы" беззнаковых размеров, если опуститься на уровень встроенных массивов, то всё работает изкаробки.
На худой конец есть еще встроенные ср-ва — способ приведения беззнакового к знаковому описан в стандарте, и в аппаратуре ничего не стоит. Но обратное приведение специфировано лишь для неполного множества значений и его вообще рекомендуется избегать.
Это то, почему построить беззнаковую экосистему поверх навязанной знаковой гемморойно и вряд ли имеет смысл.
Зато если самому с 0-ля разработать под себя контейнеры, то всё выглядит вполне стройно.
Потому что вот так можно:
int[] arr = {1, 2, 3};
ulong i = 2; // uint i
Console.WriteLine (arr[i]);А тут ошибка компиляции, требуется явное приведение к знаковому:
List<int> arr = new List<int> () {1, 2, 3};
ulong i = 2; // uint i
Console.WriteLine (arr[i]);Понятно, что все приведенные контра относительно слабы и пахнут разве что небольшим геммороем, но зачем это для случая, скажем, когда я использую самописные контейнеры, выполненные как value-type, и оперирую в операциях чаще спанами, чем GC-ссылками на классы-контейнеры?
Плюс сам шарп представляет из себя такую экосистему, где можно и нужно избегать "синтаксического оверхеда" и прочего лишнего мусора/телодвижений в коде, иначе зачем он вообще? ))
Сегодня шарп даёт много для этого даже для случая расписывания собственной экосистемы эффективных контейнеров с 0-ля.
Например, даже если value-type контейнер необходимо передавать по ссылке, то последние версии шарпа и тут помогли:
void SomeOperation<T>(in vector<T> vec)Затем при вызове указывать in не обязательно, в отличие от ref.
На всяк случай in означает read-only ссылку и, соответственно, я могу вызывать только readonly-методы контейнера.
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-8.0/readonly-instance-members
Что тоже привносит хоть какую-то строгость в код — я могу распространять по цепочке вызовов константность ссылочных аргументов, типа как в С++.
А необходимость при вызове модифицирующих ф-ий подставлять ref я вообще приветствую — в плюсах мне чего-то подобного не хватает.
Такие модифицирующие ф-ии редки и должны обращать на себя внимание программиста.
Одно пока мест неудобно — для value-типов нельзя определить конструктор копирования, поэтому в коде надо следить, чтобы ненароком не скопировать такой контейнер в обычную переменную. Хотя, и в плюсах копирование контейнера чаще указывает на ошибку, но в плюсах хоть можно наследоваться/агрегировать и в своём типе уже запретить оператор и конструктор копирования... Но зато как в плюсах можно копировать ссылку на свои value-типы, сверху в пол-тыка пишется маленькая обвязка для реализации std.move (оно именно так у меня и называется), в общем, на данном этапе развития шарпа жить уже хоть как-то можно. ))