Ей богу лучше ба Вальтер Брайт на WASM заморочился, чем потратил кучу лет на попытку интеграцию с С++ сделать

В итоге она нужна оказалось лишь единицам, а сам язык в развитии застрял

кстати, про BetterC, точно помню, что с этим ключом не вызывались static this() для модулей)

Олег, вот тут наверно лучше все же ref использовать? string [] str = ["aa","bb","cc","dd"]; foreach(int i, ref s;str) { ... } ?

ты что вообще хочешь сделать?

да просто сижу пытаюсь понять как эффективнее менять к примеру массив

или элемент в строке

Олег, вот тут наверно лучше все же ref использовать? string [] str = ["aa","bb","cc","dd"]; foreach(int i, ref s;str) { ... } ?

Я в RAII дуб

RAII это что в данном контексте?

RAII это что в данном контексте?

Вот эти ref и подобные

да просто сижу пытаюсь понять как эффективнее менять к примеру массив

Эффективно в плане скорости, красоты или надежности?

понять просто как делать и в каких ситуациях лучше то или иное решение

а разве у GDC нет поддеркки? Или его давно не обновляли?

Короче если сильно хочешь wasm, то можем попробовать пруф концепт из LDC запилить)

просто к примеру у меня данных будет не 1КБ а 100GB

просто к примеру у меня данных будет не 1КБ а 100GB

А оперативки сколько?

да просто сижу пытаюсь понять как эффективнее менять к примеру массив

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

просто к примеру у меня данных будет не 1КБ а 100GB

И сколько времени на обработку алгоритма? Все 100 гигов разом?

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

Я документацию пролистал, ощущение что нужно тупо везде ставить ref и код станет лучше?!

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

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

Попробуй тогда в LDC собирать

Попробуй тогда в LDC собирать

И оптимизации включи

По идее у нас типы (int, string, ...) знаковый тип так?

тогда для них ref нужен

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

почитай про chain, это где-то в std.algorithm, или std.range.

Кстати, мы тут тему с Eto Demerel обсуждали уже, но никто не видел хороших статей по тому как парсеры писать? Именно статей для дураков где все с самых элементарых примеров разжевывается прям по буквам

Кстати, мы тут тему с Eto Demerel обсуждали уже, но никто не видел хороших статей по тому как парсеры писать? Именно статей для дураков где все с самых элементарых примеров разжевывается прям по буквам

Лучше готовый парсер генератор под Д найти

Кстати, мы тут тему с Eto Demerel обсуждали уже, но никто не видел хороших статей по тому как парсеры писать? Именно статей для дураков где все с самых элементарых примеров разжевывается прям по буквам

я видел только книги.

Мне бы просто основу понять, чтобы это для меня не было черным ящиком

Я могу в личку тебе рассказать

давай)

В книжках оно сложнее чем на практике)

тогда для них ref нужен

что бы это значило? в любом случаи a ~ b создаст новый массив, вне зависимости от того, что там в нем лежит - экземпляры классов или же int'ы

а если не a ~ b а замена символа?

это как?

в строках замена не прокатит, они immutable(char), их кастовать к char[] надо)

ну типа replace(...)

а с числами?

какие ты читал книги про D?

У меня все хуже %) я по Ди даже книги писал %)

Тока это не значит, что я язык адекватно понимаю

так какая задача-то?

поменять определенный элемент в массиве?)

ну вот допустим да. И понять как это эффективнее сделать и когда всякие ref не будут никакого толка давать

самый эффективный способ foo[i] = bar;

ф ref - это просто передача по ссылке)

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

т.е. смысла в ref не будет

ну, т.е. если тебе в цикле foreach нужно менять элементы массива по каким-то признакам, то нужен ref, иначе переменная внутри цикла не будет "ссылаться" на элемент массива

символ в строке в foreach поменять не получится, потому что он immutable char по умолчанию

по сути string это алиас immutable(char)[]

так это я понял, а с другими типами? миссив int к примеру?

по сути string это алиас immutable(char)[]

чего ты понял? что если есть char[] то можно поменять?

что строку менять нельзя т.к. она неизменна

и любое изменение строки это создание новой копии строки

бля, а почему она не изменяема?

потому что она immutable(char)[]

так это я понял, а с другими типами? миссив int к примеру?

какие еще вопросы по поводу int[]?

массив char и int вроде бы разные или тоже самое?

разные. но вопрос был не именно про char а про immutable

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

тебе нужно почитать про immutable.

"immutable data, could actually placed in read-only sections of memory, and hence, any attempts to modify the data it will fail."

"immutable data, could actually placed in read-only sections of memory, and hence, any attempts to modify the data it will fail."

Ну и что это? ты по этому предложению все понял? а что если мы в конструкторе будет менять поля что immutable?

и вот тебе еще...

в строках замена не прокатит, они immutable(char), их кастовать к char[] надо)

я обычно так делаю: auto get(T)(socket s, T struct) { union buffer { ubyte[T.sizeof] b; T v; } buffer buf; socket.receive(buf.b); return buf.v; }

Попробовал этот хак вчера, сработало прям идеально

И никаких проблем с выравниваниями или порядком байт. Структура заполняется верно.

ERROR: S client not available

Я только стартовый пакет читал переменной длины

ну, порядок байтов в слове обычно оговаривается на уровне архитектуры или протокола

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

я свои streams написал, когда нужно было руками разбирать формат png, потому что в формате и в x86 совместимых архитектурах endianness разная)

я свои streams написал, когда нужно было руками разбирать формат png, потому что в формате и в x86 совместимых архитектурах endianness разная)

в std.bitmanip много удобного кода для этого, ты его использовал или сам делал?

сам сделал)

по сути там только чтение/запись int, short и long надо было сделать

а float и double?

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

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

в socks порт и ip отправляются в network byte order, т.е. в big endian, надо на это внимание обращать)

Я везде делаю debug writeln, так что наверно поймаю это если что будет не так.

закон мерфи же...

закон мерфи же...

Ась?

что может случиться, обязательно случится.

Я везде делаю debug writeln, так что наверно поймаю это если что будет не так.

ну типа - обязательно не поймает, когда что-то будет не так.

Лазве литтл эндиан не касается только порядка байт, не касая порядок бит?

Тогда обработка через обычные байт массивы ничего не сломает

ну а когда он эти байты десериализует, то что тогда, какими они будут?

... иму же прийдет какаято непонятная херня, а не то что он хотел.

Ну погоди погоди

Если на обоих концах его же код

То переворачивать не нужно

Там ведь тоже неправильно будет

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

По моему это вообще апи сокетов итак переворачивает. Ниразу ничего крутить не приходилось

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

По моему это вообще апи сокетов итак переворачивает. Ниразу ничего крутить не приходилось

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

вот на этапе передачи пакета авторизации нужно номер порта и айпи передавать в формате big-endian

сначала старший байт, потом младший

сокеты сами ничего не переворачивают)

сначала старший байт, потом младший

Ну раз байты то какие проблемы