- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
trait NumericUpperBound[Num1, Num2, UpperBound]
implicit object NumericUpperBoundIDD extends NumericUpperBound[Int, Double, Double]
implicit object NumericUpperBoundDID extends NumericUpperBound[Double, Int, Double]
def compareTwoNumbers3[N1, N2, N3](n1: N1, n2: N2)
(implicit nub: NumericUpperBound[N1, N2, N3],
conv1: NumericConversion[N1, N3],
conv2: NumericConversion[N2, N3],
ord: Ordering[N3]): Int = {
ord compare (conv1 convert n1, conv2 convert n2)
}
Скала, сравниваем два числа.
Вот, задался целью на досуге познакомится с этим замечателным языком, а теперь такое отвращение к потерпевшему испытываю, что даже кушать не могу.
Follow us!
Ну и нужно понимать, что такое нужно написать для, как минимум, всех встроенных числовых классов.
На этом ресурсе уже есть человек с подобной патологией. Вам обоим нужно срочно обратиться к специалисту.
Я чего-то не понимаю?
http://lmazy.verrech.net/wp-content/uploads/2011/02/scala_type_hierarchy.png
Вот что да скорее всего произойдет, так это через пару лет все прогрессивное человечество перейдет на 128-битные системы и тогда на короткий промежуток времени кто-то вспомнит о том, как неплохо было бы все-таки абстрагировать математику от физических возможностей оборудования, а потом, как всегда, появится новая побрякушка, типа Явы под еще большим слоем штукатурки, и все успокоятся и будут использовать какие-нибудь SuperLong MegaLong и т.п.
Кроме того, я об этом и говорил - это почти не нужно на практике, интерес чисто академический.
В остальном я ответил - implicits.
Как раз таки в подавляющем большинстве случаев меня абсолютно не колышит сколько там байтов помещается в какое число. Нужно будет оптимизировать? - окей, я заинтересуюсь, а для того, чтобы написать функцию для, например, подстановки чисел в шаблоны сиквел запросов - ну есть все-таки дела по-важнее.
Я его так называю просто по определению, потому что он не включен в указанную иерархию views. Вы называйте как вам будет угодно.
>Как раз таки в подавляющем большинстве случаев меня абсолютно не колышит сколько там байтов помещается в какое число.
Так используйте всегда BigInteger/BigDecimal, приводя все остальное. Проблема высосана из пальца, поэтому у нее и нет "стандартного" решения.
Пойдите пожалуйтесь производителям мотоциклов, что двух колес не хватает для устойчивости.
Т.е. вот как Оракл написали свой Number в отместку стандарному явовскому - так и мне прийдется изгалятся и писать заменитель скаловскому Number потому что родной - некондиционный. А потом, естесственно, в другой библиотеке окажется другой Number, и они будут несовместимы и понеслась, фасады, декораторы, адапторы и т.п.
Но самое обидное в этом то, что человек жеж не совсем идиот: перед ним уже были языки в которых все было правильно сделано. Ну возьми да скопируй! Нет, надо было какую-то херню придумать.
Я @wvxvw, я не хочу ничего ни к чему приводить, я хочу трололо
Ну я. Fixed 16:16 был нужен. Для с
> SuperLong MegaLong
Эти крестоблядские long long long должны сдохнуть, должны остаться int32,int64,int128...
В жабе правильно сделали, все размеры зафиксировали. В Go тоже все числовые типы фиксированы и называются int32, int64, uint32, uint64, float32, float64, etc.
ну и boost/cstdint.hpp - появился явно раньше, чем ты вообще начал активно писать на с++, да так, чтобы тебе уже надоело implementation-dependent
typedef unsigned char u08;
typedef unsigned short u16;
typedef unsigned long u32;
по сути дела, этих трёх строчек хватает на почти всё, что связано с четким заданием длин
если внезапно какая экзотическая платформа, для нее просто напросто передефайнивалось что нужно (тут возможны только подбор int/long под 32 бита - на моей памяти таких прецендентов не было)
да, не было стандартного заголовка, ну так настоящих индейцев это не должно останавливать
Неистово плюсую Заебало это. Сишка - говно.
>В жабе правильно сделали
Но не до конца. Унификацию надо было.
>int32, int64, uint32, uint64, float32, float64
Архиверно. Если делаешь кроссплатформенный ассемблер, то стоит делать именно так.
Более того я бы вообще расширил. Целые типы вообще любого размера . Назвал бы так
i1,i2,i3..i8,...i16,..,i1024
ui1,ui2,ui3..ui8,...ui16,..ui1024
Флоаты только f16,f32,f64,f128 - согласно IEEE 754.
Целые можно объединять в особые массивы с которыми производятся групповые операции.
Компилятор сам решает как их выполнять (цикл, развернутый цикл, специнструкции).
Также можно кастить i8x4=i32. Никаких наркоманских скобок для каста, только функция cast(type,val) и так везде - практически всё функции.
Джва года жду такой язык.
Единственное что их держит - традиции, распространн`ность и костыли.
И давно пора, взять с них самые ценные находки синтаксиса, убрать лишнее и отправить на свалку, потому что часто на асме проще писать.
Какой же это ЯВУ?
чем выше уровень языка, тем на большие компромиссы по быстродействию придется пойти ради удобства и скорости разработки приемлемого качества
приемлемое качество - это не падает у заказчика и выполняется с заданными критериями скорости, удобно сопровождать и дорабатывать
байтоёбство хорошо только для развлечений
Она разрабатывалась для PDP-7, с тех пор всё сильно поменялось.
>если тебе часто требуется писать на асме
Нужен нормальный, высокоуровневый, портируемый асм. А не иллюзия оного.
Ну да, отсюда, кстати, и строки с ноликом в конце.
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html
Повторение не будет лишним.
А кеш поисковика или транслате разве не показывает?
i1,i2,i3..i8,...i16,..,i1024
IL от LLVM. Там насколько помню так и есть.
Но я думал об таком коротком нейминге задолго до того как познакомился с LLVM.
Унификацию?
кстати, что тебя остановило?
Ну какого хуя "+" не определяется автоматом из "+=" ?
http://liveworkspace.org/code/1bfn3d$1
Схуяли лол
В Аде все операторы для жизни объекта автоматически определяются по трём методам, в сишке надо делать минимум 4, при этом кококонструктор кококопии по умолчанию некорректен (так как использует лишь копии членов), а конструктор сдвига - корректен (так как использует операторы объекта, а не его членов).
> и как это теперь отключить
Просто определить нужный оператор по-своему?
> http://liveworkspace.org/code/1bfn3d$1
Фу, бустятина...
что значит copy ctor по умолчанию некорректен?
для твоего (не твоего) fixed разве некорректно:
foo a(100), b(a);
если всё описать, кроме него, то его не будет вообще
If the definition of a class X does not explicitly declare a move constructor, one will be implicitly declared as defaulted if and only if
— X does not have a user-declared copy constructor,
— X does not have a user-declared copy assignment operator,
— X does not have a user-declared move assignment operator,
— X does not have a user-declared destructor, and
— the move constructor would not be implicitly defined as deleted.
При каких условиях вызывается movector? Если его не описывать, то что, в этих условиях вызовется ошибка компиляции?
Или вызовется copyctor+dtor?
в т.ч. и потому что нужна совместимость с охулиардами кода, написанного под с++03
но в основном потому, что неявный перемещающий конструктор должен повызывать перемещающие конструкторы для всех членов класса - т.е. будет некая гарантия, что члены класса самостоятельно способны разобраться с этим
как только ты объявляешь свой деструктор, или копи конструктор или всё остальное, что описано в списке - ты показываешь, что только силами членов класса не всё разруливается, нужны дополнительные действия а раз так - значит и мув конструктор будет плохо работающим, и притом, что он суть оптимизирующая поебень над копи конструктором, от него проще молча отказаться - создаст меньше проблем
Дык это и значит считай, что "сгенерировался по умолчанию movector, корректный, но неоптимальный", то, что это в пункте 1.234 на странице 567 стандарта называется "movectorа нет", волнует только стандартоёбов, это уже придирка в буквам, а не сути, а суть в том, что поведение в случае необходимости перемещения по умолчанию всегда генерируется корректно, если вся остальная рожь определена, а вот поведение при необходимости копирования - нихуяшечки.
специально для тебя строчкой ниже есть приписка:
When the move constructor is not implicitly declared or explicitly supplied, expressions that otherwise would have invoked the move constructor may instead invoke a copy constructor.
А суть не меняется.
В сишке поведение при копировании по умолчанию не определяется даже когда его можно вывести (например, из оператора =), а поведение при перемещении - определяется.
конструктор это конструктор, заимствование значения из другого объекта - это другое
по мне так гораздо лучше понимать, что если я сам не объявлю, то компилятор за меня сделает понятную работу - почленный вызов
чем непонятную - на что он должен заменить operator = при конструировании? на вызов конструктора по умолчанию и присваивание?
Да, это очень сложно для убогого крестоблядского языка, додуматься до такой вещи, как
> на вызов конструктора по умолчанию и присваивание?
А, не, додумался....
В Аде вместо copyctor делается
FieldCopy + Adjust
вместо = делается
Finalize + FieldCopy + Adjust
Поэтому вместо 4 методов (ctor,dtor,copyctor,=) в Аде достаточно описать только 3 (Initialize, Adjust, Finalize) и тогда гарантирована корректная реализация = и copyctor. Да, она зачастую неоптимальна, и то, что её нельзя оптимизировать - это недостаток языка, но 99% применения автообъектов - это всякая хренота, которую копировать нельзя вообще.
я пишу копирующий конструктор и operator = раз в столетие
я серьезно, наверное один класс из сотни или реже требует что-нибудь эдакое
ты слишком преувеличиваешь трудозатраты на описание "лишних" 2 методов - описать то их нужно для 1% классов, а пенальти твоя ада даёт на 100% объектов, и оптимизировать это нельзя
но ты можешь продолжать плакаться о том, как несправедлив мир, что стёр пальцы в кровь и что на твоем маленьком мониторе не влезают крестоублюдочные конструкции но это всё тщетно, смирись с величием С++ пред лицом ничтожных язычишек, как упомянутая тут всуе ада
Любой класс с нетривиальным деструктором требует их написания. Лю-бой.
Даже просто объявить в привате без тела - и то надо.
> а пенальти твоя ада даёт на 100% объектов
Нет, только на подликах.
И возьмём ту же реализацию строк. По сравнению с крестами пенальти будет только в одном, ровно одному случае - если и новая строка, и старая имеют одинаковую длину - не надо подёргивать кучу.
Вот у меня в последнем проекте нетривиальный деструктор только в одном классе из 50+. Я что-то делаю не так?
А раз тебе нужны нетривиальные деструкторы - то в 99% случаев либо ты юзаешь хардкорные сырые указатели, либо твой класс имеет non-copyable семантику, и copyctor и = достаточно заблочить.
И тогда всё равно я должен писать эту рожь
http://www.boost.org/doc/libs/1_53_0/boost/noncopyable.hpp
напиши свой такой же класс да наследуйся от него везде, где надо
мало того, что писать придется немного, так еще и всем понятно будет при первом взгляде на шапку класса, чем лезть в дебри private и искать отключенные конструкторы
>> TarasB: Скопируй то, скопируй сё, из коробки должны быть эти вещи.
просто у тарасика аллергия, он же велогонщик
его "орлёнок" до сих пор в отличном состоянии
Это не коробка, это ящик Пандоры.
P.S. Когда там уже boost::logging протащат...
который из?
Любой из двух, лишь бы довели до ума и "стандартизировали". Я их пока не изучал, если честно.
свой костыль пока что ближе к телу
да и проблему многопоточного смешивания логов он тут как то отдельно вынес, хотя это должна быть core feature
в общем пробовать пока не сильно охота
http://poehali.net/attach/Photo0108.jpg
Заметь, это ты сам сказал.
Да ладно, с чего это вдруг деструктор вызывается при movector?
http://liveworkspace.org/code/3xXuhg$0
именно поэтому в примерах зануляется что надо в перемещенном объекте, чтобы деструктор ничего не запортил
Ням-ням, свежая бустятинка.
> кококонструктор кококопии по умолчанию некорректен
Если все члены с кокосемантикой кокозначений, то вполне кококорректен.
ps: Ой, нитуда написал и вообще кокококмента борманда не заметил
То кококопишешь кококорректную кококоверсию кококосам.
Ну вот сколько у тебя в проекте классов, которым действительно нужны недефолтные оператор копирования и конструктор копий?
Из моего опыта:
1) Часть классов некопируема в принципе (виджеты, потоки, всякая ерунда, связанная с сокетами). У них эти операторы не только не нужны, но и вредны. А поэтому тупо заблочены путем их выноса в приват (макросом НОНКОПИЕЙБЛ или руками).
2) Другая часть классов имеет семантику значений, и все их члены тоже имеют такую семантику. В таких случаях ничего писать не нужно, дефолтовые реализации справятся.
3) И очень-очень небольшой части классов реально нужны эти операторы. Как правило это низкоуровневая поебень, содержащая сырые указатели.
Если у тебя очень много классов попадающих в категорию 3, то задумайся, скорее всего ты что-то делаешь не так...
т.е. третий вариант рулит - и писать мало, и не макрос
Можешь вот отсюда спиздить класс: http://www.boost.org/doc/libs/1_53_0/libs/utility/utility.htm#Class_noncopyable.
Так подключи коробку с бустом. В ней дохрена вещей, которые так или иначе пришлось бы велосипедить. Меня, например, на днях очень порадовало дерево свойств с поддержкой json.
P.S. Там полно header-only компонентов, которые можно подключать даже не собирая бустолиб под целевую платформу.
P.P.S. Почему пишу "скопируй"? Да тупо потому, что иначе ты скажешь "нахуй мне тащить весь буст в мой уютненький крестоблядский проектик".
Нахуй мне подключать этот ужасный буст в мой уютненький крестоблядский проектик?
Чтобы не писать велосипеды ;)
P.S. Без буста\кутишки\каких-то других либ\своих велосипедов кресты совершенно неюзабельны. Стандартной либы хватит разве что на написание лаб, да и то не всегда...
1) смартпоинтеры: http://www.boost.org/doc/libs/1_53_0/libs/smart_ptr/smart_ptr.htm.
2) контейнеры для указателей:http://www.boost.org/doc/libs/1_53_0/libs/ptr_container/doc/ptr_container.html
Это, во многих случаях, позволяет избавиться от деструкторов.
И тут внезапно широкое распространение получают троичные компьютеры и какой-нибудь g+++ 6.0 захихикает: "какой у тебя int короткий!" в палитре не хватает бледно-зеленого
Приводить к доблу, а потом сравнивать на равенство? Наркоман в треде.
А BigInteger ты как к доблу приведешь? С сохраниением лишь порядков? Для больших чисел это работать не будет. Будешь сравнивать порядки, но не сами данные и так после приведения большее число вполне может стать меньшим. Куллстори
BigInteger не приведется к Double, потому что его вообще нельзя передать в эту функцию - он не удовлетворяет условию верхней границе типов.
Пожалуйста, ознакомьтесь с документацией перед тем, как сказать очередную глупость.
Я о том же. Я о методологии.
А почему так?
http://docs.scala-lang.org/tutorials/tour/views.html
http://stackoverflow.com/q/15735352/484666
Добрый вы человек: выбрали лучший ответ и код из этого ответа запостили на говнокод.
http://www.artima.com/weblogs/viewpost.jsp?thread=163733
пусть компилятор самостоятельно подберет operator < для обоих аргументов исходя из их возможностей
http://liveworkspace.org/code/gEOrP$0
совсем непохоже на то, что хотел от скалы ОП
Что, в прочем, никак не умаляет их огромной практической ценности.
перенос duck typing, adl и прочие темплейтные обыденности в рантайм сулит много геморроя
Если этот "глупый" темплейт раскрыватся в пару-тройку асмокоманд, то это инстанциирование будет плюсом ;)
Оно все заинлайнится, если нужно и никто не заметит
Ну уж не надо утрировать. Строго говоря, в функциональных языках нельзя сравнить два числа разных типов. На это даже крестокомпилятор кресторугаться крестоворнингами будет. Нужно привести к одному типу. Scala тут не при чём.
А чувак на стековерфлоу объелся имплиситных функциональных грибов.
мне кажется, следует сказать "в строго типизируемых"
Если вы запамятовали, я вам напомню: в SICP как раз описывается построение таблицы runtime-преобразований (coersions), которые сначала приводят аргументы к общему типу, а затем уже выполняют обобщённую операцию. Но операции работают только над однотипными аргументами. Цитирую:
This coercion scheme has many advantages over the method of defining explicit cross-type operations, as outlined above. Although we still need to write coercion procedures to relate the types (possibly n^2 procedures for a system with n types), we need to write only one procedure for each pair of types rather than a different procedure for each collection of types and each generic operation.*
Собственно, примерно такую таблицу (только работающую в compile-time) и пытался вам построить советчик с SO, только нужды в ней в 99% случаев нет никакой. Ибо существуют преобразования, теряющие информацию при работе в обе стороны, и программисту лучше явно указывать, что именно он хочет получить.