просто хотел проверить ввел ли пользовать в качестве аргумента командной строки 0 или нет.

А как проверить было ли установлено значение у переменной? int x; if(x is null) что-то ругается incompatible types for ((x) == (null)): 'int' and 'typeof(null)'

Nullable юзай

погоди, это как?

в std.typecons шаблон. судя по примерам, подойдет

а можешь пример показать? А то что то не пойму как юзать

ну вот например Nullable!int x; assert(x.isNull); x = 42; writeln(x); int y = 42; assert(x == y);

спасибо, а этот модуль std.typecons он вообще для чего предназначен? Я его суть не совсем понимаю

ну вот для этого и предназначен) Nullable и всякие разные полезные штуки. tuple например, еще чего там...

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

Сравнивал Го и Ди

vibe.d

Так Ди хорошо течёт....

Лефолтный пример

*дефолтный

А так на равне

Но Вайб прожорлив по памяти, + течёт :(

Так Ди хорошо течёт....

А ты сборку мусора вызвал или смотрел как память кушается?

У меня уползало до 700 лишних метров (потом останавливался), пока эту волшебную строчку не добавил, в итоге прога ела 40 мб (с гномом)

Я просто взял предлагаемый скелетон для вайб

И скомпилировал его

Потом ab -c 200 -n 100000

И так несколько раз запускал

В итоге каждый запуск растет

А там всего то hello world!!!!

мне кажется так и должно быть

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

а так там политика достаточно жидкая: пока "нормально всё" — выделять

В итоге каждый запуск растет

В D сборщик запускается только когда память заканчивается, в отличие от го, где тот работает нонстоп. Так что либо дёргай руками, либо забей.

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

Вообще-то это не верное утверждение. Так как фреймворк не должен течь.

А он течёт. Даже в таком приложении, где нет бизнес логики

В D сборщик запускается только когда память заканчивается, в отличие от го, где тот работает нонстоп. Так что либо дёргай руками, либо забей.

Это тоже не корректно. Если на компе запущено 2 приложения, допустим, и первое сожрало почти все, а после какого-то момента более активнее начинает работать второе, а первое простаивает, но при этом сожрало много памяти, то оно не и не отпустит, так как и не знает, что эту память нужно освободить, т.к. в ней нуждается другое приложение

Это тоже не корректно. Если на компе запущено 2 приложения, допустим, и первое сожрало почти все, а после какого-то момента более активнее начинает работать второе, а первое простаивает, но при этом сожрало много памяти, то оно не и не отпустит, так как и не знает, что эту память нужно освободить, т.к. в ней нуждается другое приложение

с какой точки зрения не корректно? да и вроде не так всё просто. приложение может запустить сборщик "принудительно" по сигналу (SIGUSR1 или SIGUSR2 не помню), поэтому система или внешнее контролирующее приложение может сказать, что "хватит жрать"

В D сборщик запускается только когда память заканчивается, в отличие от го, где тот работает нонстоп. Так что либо дёргай руками, либо забей.

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

и кстати его настраивать ещё можно

Может и можно

Но не должен скелетонный пример течь!

А он течет

да блин, с чего ты взял?)

И безбожно течет

проверять валгиндом бесполезно

он будет показывать выделения, а сборку нет

Я вижу, что приложение жрет много памяти

и термин "утечка памяти" всё-таки подразумевает, что ты не можешь её высвободить и она занимает место, здесь ты можешь высвободить

А точно такой же пример 1 в 1 на ГО не течёт... :(

кароч ок, пусть течёт)

от прямоты рук в целом всё зависит, а vibe не эталон в этом плане

и термин "утечка памяти" всё-таки подразумевает, что ты не можешь её высвободить и она занимает место, здесь ты можешь высвободить

https://ru.m.wikipedia.org/wiki/%D0%A3%D1%82%D0%B5%D1%87%D0%BA%D0%B0_%D0%BF%D0%B0%D0%BC%D1%8F%D1%82%D0%B8

Читаем

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

Да

И?

если тебе срочно, то вызови сборку руками

сборщик считает, что ещё не время

Вовремя!

проблема в понимании отсутствия проблемы

а что значит вовремя?

как только так сразу?

Ты сказал, что это не утечка, я тебе показал, что это именно утечка

я по прежнему считаю что это не утечка

потому что "вовремя" для тебя не является эталоном "вовремя" для других

Ну можешь, конечно, считать...

https://github.com/rejectedsoftware/vibe.d/issues/924

потому что "вовремя" для тебя не является эталоном "вовремя" для других

Мда...

от прямоты рук в целом всё зависит, а vibe не эталон в этом плане

прочитал?

И к чему это?

моё личное мнение, что vibe это дерьмо и ставить его как лицо языка нельзя

ERROR: S client not available

дерьмо потому что подход к разработке такой

У меня кривые руки, что я запустил пример от самого фреймворка и он течёт? О.о

ты до конца прочитал?

Да

от прямоты рук в целом всё зависит, А VIBE НЕ ЭТАЛОН В ЭТОМ ПЛАНЕ

а претензия к алгоритму сборки

Это не притензия к сборщику

А констатация факта утечки...

тогда я тебя не понял

сорян

Руками вызывать сборщик - дороговато...

в каком смысле дороговато?

В прямом

а как тогда не дороговато?

Это блокирующее действие

а по другому не блокирующее?

Удалять руками за собой

остановка мира в го?

руками тоже можно, но мы возращаемся к С++ в этом случае

Удалять объекты, которые создаёшь...

ну да

Не совсем

удаляешь как попользовался

прям как в С++

любой сборщик несёт те или иные накладные расходы или проблемы

Это нормально, если ты знаешь, что объект тебе более не нужен - удали его

в чём тезис? никто не спорит что это эффективно с точки зрения производительности

но вот накладных расходов просто жесть сколько от этого

А в фреймворке такое грубое принебрижение памятью - это недопустимо

но вот накладных расходов просто жесть сколько от этого

Какие?

человеко-часы разработки/отладки

Ну не знаю...