Здравствуйте, fddima, Вы писали:
F> Опять же — C++ сам как язык долго стоял, дикая энерционность в поддержке стандартов от производителей компиляторов (про gcc наверное лучше промолчать — ведь его только что-бы скомпилировать — нужна правильная трава, а если кросс-компиляция и не дайбог ещё и какой-нибудь musl — то ещё и правильные патчи). Сейчас то ли стандартов стало больше (и новый на носу) но кажется сииуация всё куда лучше.
Ну да. Из-за Джавы и Дотнета случился застой в С++.
Но уже "пелена спала", ИМХО.
Дополнительное спасибо мобильным технологиям.
F>Но C++ безжалостен в плане набора. Печатать нужно много. Хотя мне вот лично, в некоторых случаях куда больше нравится когда хедер отдельно — можно сосредоточится на контракте класса.
Именно.
Разработка на C# без серьезной поддержки IDE принципиально невозможна.
F>Короче — C# неповоротлив. C++ как раз очень подвижен и приспосабливаемый.
Да. На С++ запросто определяют кучи типов прямо по месту и оперируют ими. Для сравнимой гибкости в C# добавили анонимные классы — но они поддерживают функциональность только структур (записей).
Я заметил, что у меня на плюсах идёт оперирование большим кол-вом типов на тех же задачах, но сами эти типы более простые.
F>Но, млин, банальное отсутствие тайп алиасов (прозрачные и не прозрачные) на уровне метаданных это жестковато, я уже не говорю о том, что ввести нормально свой тип на основе примитивных — нельзя.
Тю. На C# банального typedef нет.
В каждом файле надо писать using ShortName = Some.Very.Long.Name<Of.Some.Type>.
Так-то да, строго-типизированные алиасы были бы интересны и в С++.
Я пока местами выкручиваюсь через всякие идиомы make_unique_type<T, UniqTag>.
подойдет. MS вполне мог бы такой браузер сделать.
V>Верно. В этом месте я ругаю Гугл, что они дали миру еще один стандарт, вместо доработки до нужд веба одного из имеющихся. V>Хотя, если начистоту, изобретённый с 0-ля байткод максимально близок к машинному, к тому же оптимизирован. V>Байткод дотнета или джавы принципиально НЕ может быть оптимизированным.
Угу при этом .Net Native создается именно из .Net Core
S>>На данный момент у Dart нет никаких премиуществ перед TS.
V>Это пока основной кейз использования Дарта — трансляция с исходника в исходник, т.е. в JS. V>Но этот кейз вот уже несколько дней как перестал быть основным, бо уже у тебя в браузере. V>Посмотрим, это дело времени.
Ну с таким же успехом можно добавить и кучу фич в TS или вообще использовать C#.
S>>Кстати я бывший дельфист, но больше программирую на C#. Для меня TS дается легко, а если будет транслятор из C# в TS (а может он и есть), то многие вещи не сложно перетащить
V>В Dart перетащить из C# намного проще — языки ОЧЕНЬ похожи. V>Я не удивлюсь, если когда-нить они станут близнецами. ))
Так и TS и C# тоже ооочень похожи. Отличие только в обявлении типа. А мне это больше нравится.
Плюс автовывод типа в функциях.
А тот же рефлектор прекрасно транслировао Il код в любой язык
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, Serginio1, Вы писали:
S>> Есть .Net Native. Как раз симпатичный такой ЁжеУж. F> Давай по шагам какие пакеты поставить что-бы хотя бы портабельный код получился в целевой экзешник. Заодно не забудь про тонну нативных .obj которые там тоже должны оказаться. Я или что-то пропустил, или это всё пока в воздухе.
Здравствуйте, vdimas, Вы писали:
V>Ну да. Из-за Джавы и Дотнета случился застой в С++. V>Но уже "пелена спала", ИМХО. V>Дополнительное спасибо мобильным технологиям.
Мне кажется он случился задолго (вовремя) и исключительно из-за некачественных компиляторов C++. Ну т.е. банальный пробел между > > требовали некотопые долговато. Это ж сущая мелочь — но приятно же. Ну и куда более серьезные вещи.
V>Именно. V>Разработка на C# без серьезной поддержки IDE принципиально невозможна.
Интересно другое — сейчас студия способна схавать chrome не упав. Т.е. очень приличный интеллисенс сейчас есть и у плюсов. Реально.
F>>Короче — C# неповоротлив. C++ как раз очень подвижен и приспосабливаемый. V>Да. На С++ запросто определяют кучи типов прямо по месту и оперируют ими. Для сравнимой гибкости в C# добавили анонимные классы — но они поддерживают функциональность только структур (записей).
Аноним и есть аноним, что внутри. Возьми как пример — v8 или skia — и типизировано и зассерчено по самое. А я на шарпе не могу даже в структуру инт завернуть — в интероп методах они передаются иначе у мс и в линуксах (последние всегда возвращают указатель, а мс — короткие структуры передает by value). Короче — куда там до объявления типов из системы типов С (в смычле кг/ам ой... я имел ввиду С из мат/физики). Реально шарп сосёт. Более того Эрик недавно на SO упорно агитировал за long вместо специализированных типов навроде size_t. В общем мне когда я был маленьктм — виделось это верно. Сейчас — нихерашечки это верным не кажется. Тем более uint/sint — когда все их можно безопасно складывать иои вычитать в зависимости от ожидаемого рещультата (и кстати checked/unchecked — прям в выражениях мне нравится — ясно что ожидаем получить). Но даже банальное: frameId, requestId и хзId — все должны имеено свой тип (или opaque alias). Но нет. Эрику эта логика недоступна — имеем и в шарповых библиотеках полнейший разброд. Увы.
V>Я заметил, что у меня на плюсах идёт оперирование большим кол-вом типов на тех же задачах, но сами эти типы более простые.
Я сам код не пишу (крайне редко),чаще дорабатываю готовый... что бы быть точным — код хромиума. Там нет ничего сложного, кроме объема. Объем там прибивает. Но он написан хорошо и его легко читать. Волшебных шаблонов там нет и имхо — они нахер не нужны. Да простят меня ярые плюсовики — всё что делается на шаблонах именно из области адванцэд — это бред. Надо отлучиться от этого и посмотреть на то как делаются макросы в других языках (примеров аж двп). Но это чисто моё имхо. Мне кажется что практики предпочитают более открытые механизмы и всё. Но отмечу — в целом — С+× как раз идёт в правильном направлении. К сожалению — вынужденно, поэтому всё не примитивное — выглядит уродски. Для хейтеров ещё раз повторю (это не тебе vdimas) — иаботающее решение лучше виртуального и неработающего. Поэтому по факту на сегодня к C++ как к языку — просто не может быть претензий. Претензии есть, но это тогда будет другой язык
V>Тю. На C# банального typedef нет. V>В каждом файле надо писать using ShortName = Some.Very.Long.Name<Of.Some.Type>.
Я и говорю — на уровне метаданных этого нет. Или копипастить или ква. Я opaque вообще нет (в C++ вроде планируются?). Но опять же — в C++ мы легко int завернём в класс вот вам и opaque. И zero-cost абстракция скорее всего тоже будет рядом. (понятно что new myInt() это глупо).
V>Так-то да, строго-типизированные алиасы были бы интересны и в С++. V>Я пока местами выкручиваюсь через всякие идиомы make_unique_type<T, UniqTag>.
Я читал пропозишны на тему opaque aliases. Поживём увидим. Просто в C++ ничегг не мешает его реализовать как есть имея доступные конструкции (class и операторы) — java и c# — именно как языки тут импотенты. Хотя в целом, имхо — C# большмй импотент. Надо заняться стиранием типов вообще как преобразование, а не заниматься их традиционной херней "а вдруг" и шарить код это ахеренно. Кстати на основе чего они так решили — публке неизвестно. В смысле замеров то не было. Их просто не могло быть.
Здравствуйте, fddima, Вы писали:
F>- ах, системный вызов послал нас на? ну и хер с ним! F>- ах — в этом случае в этом параметре приезжает нулл? ой ну тогда нах (return).
Ну... это безответственность.
Может, затем вкладка Хрома и должна жить в отдельном процессе, что нуегонах? ))
F>В купе с факторами — это нисколичко не лучше. Я душрй за корректность, затем за оптимизацию на нулах. Но нет: куча кода просто ничерта не делает если ему подать нул на вход: а это — прямой путь в ад. Собственно они там давно. Но это не про C++ — это больше про гугл и их браузер.
Ну да. Я у себя по работе активно юзаю NotNull<> идиому.
Эдакий смарт-поинтер в качестве параметра аргумента.
Удобно делать typedef типа таких:
По аналогии с тем, что ссылки (references) в C++ по-идее не могут быть NULL.
Хотя, конечно могут.
Поэтому, такой велосипед.
Подать NULL извне становится невозможно.
Проверять на NULL внутри становится не нужно.
Здравствуйте, Serginio1, Вы писали:
V>>Ужассс... )) S> А что ужасного? или приведи пример не ужасного и сравним.
Только если на CORBA. ))
Просто подход к "вызову методов удалённых объектов" давно умер, как я считал.
Я им десяток с лишним лет отзанимался когда-то, хватит.
Сейчас есть просто жуткий трафик "туда" и "оттуда".
Соответственно, все операции становятся асинхронными, никакого вызова удалённых процедур нет.
Сама эта система по вызову удалённых процедур — она очень тяжеловесная (таблицы проксей, ресолвинг, согласование времени жизни и т.д.), это всё отнимает тики процессора. Зачем так делать?
Здравствуйте, vdimas, Вы писали:
V>Ну... это безответственность. V>Может, затем вкладка Хрома и должна жить в отдельном процессе, что нуегонах? ))
Я эим плотно занимаюсь лет 5. Сначала я думал как ты. Потом понял — exceptionless в гугле = мужет ну его нах? Короче игнорирование ошибок можно встретить в самых разных частях. Я вообще верю в exeptionless code, но без помощи компилятора он невозможен. Иначе — так мли иначе где-нибудь тихо проглатываем ошибки: и тут нюанс часть проглотов ожидаем, а часть нет. В этом смысое исключения или любой другой механизм верифицируемый компилятором — рулит. Эт чисто моё имхо. Уверен, что ихние разработчики меня бы распяли.
V>Ну да. Я у себя по работе активно юзаю NotNull<> идиому. V>Эдакий смарт-поинтер в качестве параметра аргумента.
У них в коде никаких тайп/вэлью хинтов нет. соотв. ptr.get() и проверили. в V8 напротив очень много шаблонов на тему что ожидается. но V8 — это отдельный проект (по отношению к остальному коду).
V>По аналогии с тем, что ссылки (references) в C++ по-идее не могут быть NULL.
Опять же — по идее. На практике легко могут. Благо как минимум x86/64 модель памяти и "гвардейцы" об этом заботятся. (arm тоже или нет, сори за нубский вопрос?).
V>Хотя, конечно могут. V>Поэтому, такой велосипед. V>Подать NULL извне становится невозможно. V>Проверять на NULL внутри становится не нужно.
Ах. Ну конечно! Нахер это делать, если это делает целевое оборудование? Мржет не всё... но я не знаю. Имхо плоская модель памяти это уже стандарт как и как минимум 4К невалидных чтений в начале.
Врядли в космос посылают программы которые стартуют с адреса ноль или пишут там?
Здравствуйте, Serginio1, Вы писали:
V>>Байткод дотнета или джавы принципиально НЕ может быть оптимизированным. S> Угу при этом .Net Native создается именно из .Net Core
Еще раз.
В .Net Native оптимизируется конечный нейтивный код из байт-кода дотнетной VM.
Но сам этот байт-код не оптимизирован и не может быть оптимизирован.
Гугл, напротив, предлагает уже оптимизированный байт-код.
S>Так и TS и C# тоже ооочень похожи.
Э, нет.
S>Отличие только в обявлении типа.
В аннотациях типа.
Это серьезное отличие синтаксиса, которое тянет за собой много чего.
В С-подобных языках указание типа переменной одновременно означает объявление переменной.
Т.е. операция два в одном получается.
А если не хочется указывать тип (аннотацию), например, если тип переменной может быть выведен, то требуется ключевое слово для объявления переменных. Мы же не хотим пользоваться не объявленными переменными верно?
А если при этом, таки, требуется указать тип переменной, то получается совсем ж-па, т.к. у нас будет и ключевое слово, и имя переменной и аннотация её типа. Неудобно, как по мне.
S>Плюс автовывод типа в функциях.
Так и в Dart автовывод присутствует.
И ковариантность полноценная:
Mammal peekMammalList(List<Mammal> list) {
return list[2];
}
main() {
List<Cow> cowList = new List<Cow>(4);
peekMammalList(cowList);
// Covariant use:
// * static type checking OK
// * dynamic type checking OK
// * runs happily
}
А в C# полноценная ковариантность поддерживается только на встроенных массивах.
Но это же бред, верно?
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
V>>>Ужассс... )) S>> А что ужасного? или приведи пример не ужасного и сравним.
V>Только если на CORBA. ))
Ну и в чем разница? Та же обертка, при этом с кучей ненужного кода. V>Просто подход к "вызову методов удалённых объектов" давно умер, как я считал. V>Я им десяток с лишним лет отзанимался когда-то, хватит.
Угу WCF, обертки над Rest Удобный REST для Xamarin-приложений
V>Сейчас есть просто жуткий трафик "туда" и "оттуда". V>Соответственно, все операции становятся асинхронными, никакого вызова удалённых процедур нет.
Можно и асинхронно, просто неудобно
V>Сама эта система по вызову удалённых процедур — она очень тяжеловесная (таблицы проксей, ресолвинг, согласование времени жизни и т.д.), это всё отнимает тики процессора. Зачем так делать?
Нет там никаких таблиц. Есть DynamicObject, есть финализаторы. При этом ссылки на удаленные объекты убираются пачками по 50 штук.
Что там тяжеловесного. Скорость обмена по Tcp/Ip 15 000 в секунду.
А вызов из натива порядка 500 000 вызовов в секунду
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
V>>>Байткод дотнета или джавы принципиально НЕ может быть оптимизированным. S>> Угу при этом .Net Native создается именно из .Net Core
V>Еще раз. V>В .Net Native оптимизируется конечный нейтивный код из байт-кода дотнетной VM. V>Но сам этот байт-код не оптимизирован и не может быть оптимизирован. V>Гугл, напротив, предлагает уже оптимизированный байт-код.
И чем он не оптимизирован. Для примера
На самом деле есть две возможности оптимизации при компиляции в Il Roslyn и компиляция в натив RyuJIT
S>>Так и TS и C# тоже ооочень похожи.
V>Э, нет.
S>>Отличие только в обявлении типа.
V>В аннотациях типа. V>Это серьезное отличие синтаксиса, которое тянет за собой много чего.
Так в Darte и этого нет. Ничего это за собой не тянет. Поверь мне. Я то в отличие от тебя пишу на нем.
V>В С-подобных языках указание типа переменной одновременно означает объявление переменной. V>Т.е. операция два в одном получается. V>А если не хочется указывать тип (аннотацию), например, если тип переменной может быть выведен, то требуется ключевое слово для объявления переменных. Мы же не хотим пользоваться не объявленными переменными верно?
Так и в Ts тоже самое. Только вместо
string value
имеем
value:string
V>А если при этом, таки, требуется указать тип переменной, то получается совсем ж-па, т.к. у нас будет и ключевое слово, и имя переменной и аннотация её типа. Неудобно, как по мне.
ты в чем жопу то увидел.
Для тебя value:string жопа по отношению string value
S>>Плюс автовывод типа в функциях.
V>Так и в Dart автовывод присутствует. V>И ковариантность полноценная: V>
Здравствуйте, Somescout, Вы писали:
S>>>Это ваш способ спора — повторять один и тот же тезис до посинения? Тогда считайте выделенное моим новым ответом на каждое подобное сообщение.
I>>Я уже сказал — можно сравнить оба решения, табличкой, шоб интереснее было. А то может оказаться так, что твоё решение в общем случае то и не работает. Бгг.
S>Давайте, простая табличка:
Для начала твоё решение у меня не запускается ни на одном из компах (три), ни на телефоне, ни на планшетах(два)
Похоже твой боксёр не явился на матч, а у моего найдена проблема — не умеет встроеные функции.
Здравствуйте, Serginio1, Вы писали:
V>>Так и в чем прикол продолжать есть кактус?
S> На самом деле сейчас Angular 2 может подмять под себя кучу Фреймворков.
Вообще то Ангуляр первый подмял. А на второй мигрируют без особых проблем, если не было серверной логики на клиенте
S>неудобно писать постоянно this при обращении к полям класса, хотя конечно он значительно приятнее es5 и все таки поддержка типов и аннотаций значительно предпочтительнее чем es6
TypeScript позволяет проектировать принципиально иначе, полагаться на точные механизмы компилятора и тд. Соответственно при желании кода получается намного меньше, чем в JS. В каждой либе, которая портируется из JS, куча кода тупо выбрасывается при сохранении поведения и качества.
Здравствуйте, fddima, Вы писали:
V>>Так-то да, строго-типизированные алиасы были бы интересны и в С++. V>>Я пока местами выкручиваюсь через всякие идиомы make_unique_type<T, UniqTag>. F>Я читал пропозишны на тему opaque aliases. Поживём увидим. Просто в C++ ничегг не мешает его реализовать как есть имея доступные конструкции (class и операторы)
Можно делать типизированные значения простых типов через
enum class MyChar : char {};
Но тут тоже наблюдается некое inconsistence, например, вот так нельзя:
MyChar a('a');
Можно только так:
MyChar b = MyChar('b');
// или так
MyChar c(MyChar('c'));
Здравствуйте, vdimas, Вы писали:
V>Более того, идёт отказ от DOM. V>Потому что модель DOM — это тоже устаревшая тупая хрень, ограничивающая всё, что только можно ограничить. DOM был нужен исключительно и только для JS.
А что взамен?
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
V>>Потому что модель DOM — это тоже устаревшая тупая хрень, ограничивающая всё, что только можно ограничить. DOM был нужен исключительно и только для JS. LP>А что взамен?
Некий "типизированный" стандарт, его нейтивное ABI.
Ведь сейчас так странно получается, что сам DOM унутре в браузерах всегда нейтивный, бо все браузерные движки, достойные внимания — все нейтивные. Но чтобы предоставить доступ к элементам DOM, эти легковесные указатели на нейтивные объекты пакуются в весьма тяжеловесные обёртки и в таком виде подаются в "среду исполнения" JS. И, если оставить стандарт DOM в текущем виде, то небходимо будет из этих тяжеловесных объектов получить еще более тяжеловесные обертки второго уровня для нейтива + непонятные правила вызова методов. Через рефлексию как сейчас? Ведь это жуткие тормоза. Прямой типизированный вызов метода будет эффективнее в сотни раз.
Поэтому, DOM должен быть нейтивным, строго-типизированным, включая нейтивное же АПИ по его рефкаунтингу. А вот уже эти тяжеловесные обертки пусть создаёт тяжеловесная же скриптовая среда, если оно ей надо, конечно. Потому что на том же C# через интероп можно вызывать нейтивные методы вполне легковесно без создания тяжеловесных оберток. Ну или как минимум выбирать — создавать ли такую обертку (для дальнейшего хранения) или нет.
Ну и с подсчётом ссылок куча сценариев облегчаются. Например, если в теле колбэка от события DOM не запоминаем поданный непосредственный указатель на HTML-элемент, то никакого рефкаунтинга не происходит. Чаще всего в колбэке надо выполнить какие-то действия с объектом, т.е. просто вызвать метод/другой у него. Или точно так же получить через селектор некий другой HTML-элемент и тут же произвести с ним некие действия без сохранения на него ссылки. Подобный алгоритм рефкаунтинга реализуется в boost::intrusive_ptr и он кардинально отличается от алгоритма рефкаунтинга в COM, где любой возвращённый тебе указатель на IUnknown уже заведомо будет "проинкрементирован". Т.е., можно сделать вполне легковесную систему даже в плане избегания лишних парных операций инкремента/декремента.
Здравствуйте, Serginio1, Вы писали:
V>>Гугл, напротив, предлагает уже оптимизированный байт-код. S> И чем он не оптимизирован. Для примера S>roslyn-linq-rewrite
Ты уже давал эту ссылку.
Переписывание исходника — это еще не тот уровень оптимизаций.
S>На самом деле есть две возможности оптимизации при компиляции в Il Roslyn и компиляция в натив RyuJIT
Да, речь идёт о чем-то вроде .Net Native, где одним из target будет webasm.
V>>В аннотациях типа. V>>Это серьезное отличие синтаксиса, которое тянет за собой много чего. S>Так в Darte и этого нет. Ничего это за собой не тянет. Поверь мне. Я то в отличие от тебя пишу на нем.
Чего нет? Аннотаций типов?
V>>А если при этом, таки, требуется указать тип переменной, то получается совсем ж-па, т.к. у нас будет и ключевое слово, и имя переменной и аннотация её типа. Неудобно, как по мне. S>ты в чем жопу то увидел.
Если ты её не увидел, то это минус тебе.
Перечитай выделенное внимательней.
S>Для тебя value:string жопа по отношению string value
Вот это ошибка на TS:
abs: string = xyz();
Надо так:
let abs: string = xyz();
Итого, имеем лишнее ключевое слово let.
Аналогично для объявления ф-ий тоже требуется некое ключевое слово.
В Дарте никаких лишних ключевых слов не требуется.
V>>Так и в Dart автовывод присутствует. V>>И ковариантность полноценная: S>В TS это так S>
Суть была в том, что peekMammalList ожидает аргумент List<Mammal>, а ему подают на вход List<Cow>.
V>>А в C# полноценная ковариантность поддерживается только на встроенных массивах. S> Почему? в Дженериках и в делегатах S> interface ICovariant<out R> { }
Ну так какие проблемы?
Покажешь мне условный пример с MyList<T>?
Здравствуйте, Serginio1, Вы писали:
V>>Просто подход к "вызову методов удалённых объектов" давно умер, как я считал. V>>Я им десяток с лишним лет отзанимался когда-то, хватит. S> Угу WCF, обертки над Rest Удобный REST для Xamarin-приложений
Асинхронные же, как я и настаиваю.
V>>Сейчас есть просто жуткий трафик "туда" и "оттуда". V>>Соответственно, все операции становятся асинхронными, никакого вызова удалённых процедур нет. S> Можно и асинхронно, просто неудобно
Наоборот, это удобно.
Ты же сам дал ссылку на асинхронный интерфейс.
Асинхронность позволяет строить вменяемую потоковую модель приложения.
Потому что синхронные удалённые вызовы де-факто не работают в реальных приложениях.
Я посвятил этому много лет и хорошо понимаю, о чем речь.
Почти всегда приходится отказываться от синхронщины.
V>>Сама эта система по вызову удалённых процедур — она очень тяжеловесная (таблицы проксей, ресолвинг, согласование времени жизни и т.д.), это всё отнимает тики процессора. Зачем так делать?
S> Нет там никаких таблиц.
Без таблиц экземпляров стабов-проксей неозможна асинхронная реализация, как показано по твоей собственной ссылке.
Ты её сам-то читал?
"Кто", по-твоему, вызовет продолжение у Task вот здесь:
На практике легко могут. Благо как минимум x86/64 модель памяти и "гвардейцы" об этом заботятся. (arm тоже или нет, сори за нубский вопрос?).
