Для меня Ди очень удобный (можно делать что хочу, как хочу, и это часто будет выглядеть приятно). Широкий спектр от уровня Си и ниже до высокоуровневых высот всяких higher-kinded types. И при этом быстрый. В итоге годится и там, где был нужен С++, и там, где иные пишут на питоне или скале.. Ну и статическая интроспекция (на которой стоит Design by introspection) - это такой наркотик, как освоишь, потом сложно слезть. :)

мне по части сравнения с Erlang хотелось бы

А, плюсы Ди по сравнению с Эрлангом. Ща:

можно перефразировать: удобнее, чем Erlang и далее по тексту)

посмотри как я там про остальные языки написал, нужно что-то в этом духе

Эрланг все же тормозной. Он интерпретируемый как PHP (хотя есть вариант с JIT компиляцией - HiPE - но его редко в продакшне используют, видимо, не все там гладко). Ди компилируется в нативный код. Эрланг динамически типизированный. Это плохо и для скорости (неэффективное представление данных), и для моей психики. На динамических языках писать что-то большое - это для особенных людей, я так не могу. У Ди синтаксис человеческий. Эрланг многое унаследовал от Пролога, все эти запятые с точками это ужос. Троллинг (но правда) : по умолчанию строка в эрланге это связанный список чисел! Ну как так можно вообще? :)

строка это число??

Список из букв, каждая буква - число.

Т.е. на фоне эрланга Ди намного эффективнее представляет данные в памяти, не тратит процессор на интерпретацию байткода, и бережет программиста по части синтаксиса, типизации и удобства в целом. Но по устойчивости к ошибкам и по средствам для распределенных вычислений Ди сосет.

Эрланг все же тормозной. Он интерпретируемый как PHP (хотя есть вариант с JIT компиляцией - HiPE - но его редко в продакшне используют, видимо, не все там гладко). Ди компилируется в нативный код. Эрланг динамически типизированный. Это плохо и для скорости (неэффективное представление данных), и для моей психики. На динамических языках писать что-то большое - это для особенных людей, я так не могу. У Ди синтаксис человеческий. Эрланг многое унаследовал от Пролога, все эти запятые с точками это ужос. Троллинг (но правда) : по умолчанию строка в эрланге это связанный список чисел! Ну как так можно вообще? :)

прям вот честный двунаправленный список? т.е. код символа, ссылка на предыдущий код, ссылка на следующий код?

Однонаправленный, возможно

господа знают толк)

хотя, так подстроки удалять быстрее, чем из массива)

хотя, так подстроки удалять быстрее, чем из массива)

Если строка короткая — быстрее как раз таки реаллоцировать новый массив, чем обходить список. А для больших строк есть rope которые так и реализовываются.

В хаскеле так же было, только типизированно все же. Там String = [Char], список Char'ов

Но с тех пор в хаскель завезли еще штук пять разных типов строк.

В эрланге теперь тоже есть более нормальные строки (не списки), но с ними как-то иначе надо обращаться, не как с родными строками.

хотя, так подстроки удалять быстрее, чем из массива)

Если только из начала. Ведь вырезать середину так просто не выйдет - начало строки это иммутабельный список. Надо построить новый список, где начало будет как у исходной строки, а продолжением будет хвост старой. Использовать начало старой не выйдет.

а да, иммутабельность же

можно я повторюсь с вопросом еще раз, мб, кто что-нибудь подскажет, направление размшлений, так сказать:

Andrey Bukhanovsky, [Sep 19, 2017, 10:11:03 AM]: пробую разобраться с шаблонами никак не могу понять, почему происходит такая штука: class cContainerArray{ template container(T){Array!T objects;} this(){} void add(T)(T obj){container!(T).objects ~= obj;} ulong getSize(T)(){return container!(T).objects.length;} } cContainerArray cA = new cContainerArray(); cContainerArray cB = new cContainerArray(); cA.add!(object)(obj1); cB.add!(object)(obj2); writeln(«cB size is ", cB.getSize!(object)()); получаю результат - «cB size is 2», по идее должно быть 1 то есть obj1 и obj2 попадают в оба массива

переписать-то я переписал этот пример, но все равно получается как-то странно

а вопрос по приведенному примеру - почему все же так получается?

Тут надо смотреть, куда попадает объявленное внутри template. Видимо, не в поля класса, хоть темплейт и описан внутри класса.

Скорее всего, тут класс лишь namespace обеспечивает

А получается глобальный массив objects

да, какой-то эффект глоабльности (:

https://github.com/PhilippeSigaud/D-templates-tutorial/blob/master/D-templates-tutorial.pdf

уже все перетрес, переписал вот так:

class cContainerArray(T){ //template container(T){Array!T objects;} Array!T objects; this(){} void add(T obj){objects ~= obj;} ulong getSize(){return objects.length;} }

но тогда получается еще забава одна

попробую в словах описать - если я объект такого класса размещаю в другом классе, например, buffer, а потом делаю, например, массив таких буферов, то получается опять =глобальность= - объект, занесенный в objects любого из буферов появляется в каждом таком буфере (:

если просто создавать объект класса cContainerArray, то все нормально

Тут надо просто не забывать, что class в D это семантически как struct * в С++. Поле-объект это лишь указатель.

10 побитовых копий буфера будут иметь 10 равных указателей на один и тот же объект

я делаю так:

auto _buffs = new cContainerArray!cBuffer; for (int i = 0; i < _countBuffers; i++){ _buffers ~= new cBuffer(); }

но сути, видимо ,не меняет

Если целиком пример на gist.github.com или там dpaste положишь, сможем ответить

ок, сегодня постараюсь сделать, спасибо.

На канале про Раст сформулировали определение низкоуровневости :)

Если целиком пример на gist.github.com или там dpaste положишь, сможем ответить

https://gist.github.com/aburuss/9663f6829b8cfd23afc0543ba7398335

ну вот как-то так. туплю, наверное, попросту. но понять не могу как (:

https://dpaste.dzfl.pl/0916f0f572d1

_objects = new cContainerArray!cObject надо делать в конструкторе cBuffer

Тогда это выполняется при создании каждого буффера

А то, что было - там один объект создавался в компайл-тайме, и все объекты типа cBuffer имели ссылку на него одного

Когда что-то инициализируем в классе не в конструкторе, а field = value,

то это значение запоминается в "слепке" для инициализации объектов этого типа

вот оно что. а у меня в начальных версиях было в конструкторе, но по ходу суеты выпало наружу. спасибо большое за объяснение.

Там интересный эффект - если в конструкторе cContainerArray добавить writeln (как в моем примере), то он не дает напиать _objects = new cContainerArray!cObject за пределами конструктора, т.е. ему надо это значение вычислить в компайл-тайме единожды, а там writeln недоступен.

в общем - читать мне еще кучу всего (:

еще раз спасибо!

Так, а режим betterC в LDC был доступен? Просто этот ключ вроде бы давно очень был. Что он до этого делал?

Кстати, я по моему спрашивал как место можно резервировать для массива? Кроме Length вот еще вариант: string x = [1,2,3,4,5]; x.reserve = 100; writeln(x.capacity);

только не понятна разница с .length

https://dlang.org/phobos/object.html#.reserve

только не понятна разница с .length

Length вроде показывает кол-во элементов именно, a reverve именно зарезервированную память

но length же изменяемое...

но length же изменяемое...

а foreach Не на length опирается? просто тогда если зарезервировать много места через length, то много итераций будет

почему много? по идее наоборот мало.

почему много? по идее наоборот мало.

ну смотри, length = 100, значит каждый форич будет 100 раз проходить, даже если у тебя там всего 3 элемента, остальное на будущее

reserve устанавливает именно capacity через _d_arraysetcapacity, а length именно длину массива

другими словами, когда выставляется length=100, в массиве _реально появляется 100 элементов_, а при reserve=100 резервируется место под 100 элементов, а длина массива не меняется.

ERROR: S client not available

а...

тоесть length лучше для ресайза не использовать т.к. это к ошибкам приведет?

тоесть length лучше для ресайза не использовать т.к. это к ошибкам приведет?

скорее не к ошибкам, а к тому, что может лишнюю работу делать

это приведет к тому, что реальный размер массива поменяется, приведет это к ошибкам или нет, зависит исключительно от программиста)

угуб спасибо, я проверил. действительно так

А в шарпе массивы так же устроены?

там так же можно их размер менять?

а почему у меня в таск-менеджере ничего не меняется? приложение должно же больше памяти потреблять если зарезирвировано много

GC и так резервирует, попробуй больше резервировать

А в шарпе массивы так же устроены?

массивы там неизменяемой длинны

я пробовал: x.reserve = 10_000_000;

я пробовал: x.reserve = 10_000_000;

а x какой тип данных?

int[] x = [1,2,3,4,5];

ну такое кол-во должно быть заметно

Небольшой вопрос по Горутинам. Те как понимаю вшиты в язык, а тут получается каждая функция должна сама yield вызывать если она хочет работать подобным образом?

B task manager'e разные стобцы есть. Есть commit - сколько запрошено, а есть working set - сколько реально используется...

Да компилятор go по сути сам расставляет yieldы по коду.

На винде таких столбцов не вижу

тоесть аналог го-рутины будет: foo () { // что-то делаем yield(); }

так?

вроде так. в го переключение гоуротины происходит на блокирующем вызове. хотя может и не так)

На блокирующих вызовах и внутри циклов еще

спасибо

а она где выделяется? Типа ОС знает что там нули?

Программа говорит системе: дай гигабайтик. Система у себя виртуальную память размечает, что такие-то адреса данного процесса теперь ему принадлежат и там нолики. При первом реальном обращении к тем страницам они уже маппятся на страницы физической памяти (которые уже в working set входят). Пока страница выделена, но не использовалась, физическая память не расходуется.

Как по ассемблерному листингу понять какие данные в стек, а какие в кучу кладутся? https://d.godbolt.org/ push/pop это стек? Или есть еще какие-то моменты?

по идее, все, что работает с SP/ESP/RSP — это работа со стеком

это если мы говорим про архитектуру x86Ю конечно)

Я что-то не пойму а где тут число 7 в листинге:

подозреваю, нигде)