Или собираться сваливать на Марс.

это уже давно пора )

Вы еще скажите, что у D вышел стабильный компилятор, а code.dlang.io перестал падать

)))

Вы еще скажите, что у D вышел стабильный компилятор, а code.dlang.io перестал падать

хорошая шутка :)

Уважаемые dlang-программеры! Прошу совета. У меня в коде есть некоторое кол-во глобальных переменных типа dictionary, хочу их вынести в отдельный модуль. Проблема в том, что часть этих глобальных переменных из них получается из других переменных с помощью некоторых операций (циклов), вроде перемены пары {ключ:значение} -> {значение:ключ}. Как это вынести в отдельный модуль, если голый цикл в модуле (вне тела функции или структуры) не компилируется? Можно попробовать загнать в структуру, но this() с пустыми скобками нельзя перегрузить, а с параметрами как-то неестественно — нет там никаких параметров, просто некоторые данные, которые нужно смотреть и в фас, и в профиль. Как это делается in D way? Возможно какой-то вариант static foreach? Буду благодарен за совет или ссылку на пример.

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

static this() для модуля не годится?

если единожды, то либо static this(), либо CTFE, если данные известны на этапе компиляции

static this() для модуля не годится?

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

тогда я сделал бы это черес CTFE

Я только начинаю осваивать D. Ситуация как у собаки: всё понимаю, сказать не могу. :)

https://p0nce.github.io/d-idioms/#Precomputed-tables-at-compile-time-through-CTFE примерно, как описано тут

https://p0nce.github.io/d-idioms/#Precomputed-tables-at-compile-time-through-CTFE примерно, как описано тут

Спасибо, посмотрю!

Уважаемые dlang-программеры! Прошу совета. У меня в коде есть некоторое кол-во глобальных переменных типа dictionary, хочу их вынести в отдельный модуль. Проблема в том, что часть этих глобальных переменных из них получается из других переменных с помощью некоторых операций (циклов), вроде перемены пары {ключ:значение} -> {значение:ключ}. Как это вынести в отдельный модуль, если голый цикл в модуле (вне тела функции или структуры) не компилируется? Можно попробовать загнать в структуру, но this() с пустыми скобками нельзя перегрузить, а с параметрами как-то неестественно — нет там никаких параметров, просто некоторые данные, которые нужно смотреть и в фас, и в профиль. Как это делается in D way? Возможно какой-то вариант static foreach? Буду благодарен за совет или ссылку на пример.

Вообще в коде не должно быть глобальных переменных. Это не зависит от языка. Их наличие ясно сигнализирует об архитектурных ошибках. Соответственно, начать лучше с того, что бы продумать как от них избавиться

Слишком категорично сказано.

В большинстве случаев скорее так и есть, но не во всех.

В большинстве случаев скорее так и есть, но не во всех.

Ну конечно. Но чаще всего именно так. Должны быть веские причины что бы их оставить. Синглтон, кстати тоже плохой альтернативой может быть.

Уважаемые dlang-программеры! Прошу совета. У меня в коде есть некоторое кол-во глобальных переменных типа dictionary, хочу их вынести в отдельный модуль. Проблема в том, что часть этих глобальных переменных из них получается из других переменных с помощью некоторых операций (циклов), вроде перемены пары {ключ:значение} -> {значение:ключ}. Как это вынести в отдельный модуль, если голый цикл в модуле (вне тела функции или структуры) не компилируется? Можно попробовать загнать в структуру, но this() с пустыми скобками нельзя перегрузить, а с параметрами как-то неестественно — нет там никаких параметров, просто некоторые данные, которые нужно смотреть и в фас, и в профиль. Как это делается in D way? Возможно какой-то вариант static foreach? Буду благодарен за совет или ссылку на пример.

Напиши кейсы использования глобальных переменных. Попробую предложить варианты обхода без них

Я глобалами обычно только разные константы делаю.

Константы тоже лучше оборачивать в какую нибудь структуру options и через конструктор передавать.

я так понял, речь идет о каких-то константных данных, которые вытекают из каких-то других константных данных)

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

Константы тоже лучше оборачивать в какую нибудь структуру options и через конструктор передавать.

Зачем? Чем это лучше?

Впрочем я понял, речь об определенных константах

Опции для создания объектов и т.д.

Но бывают просто некие общие иммутабельные данные расшаренные между множеством объектов

Вообще в коде не должно быть глобальных переменных. Это не зависит от языка. Их наличие ясно сигнализирует об архитектурных ошибках. Соответственно, начать лучше с того, что бы продумать как от них избавиться

Не должно быть, но бывают, к сожалению. Александреску, как-то рассказывал, как они (когда он ещё работал в Facebook-e) нашли баг в gcc: тот валился, если число глобальных переменных в коде было больше 2^15.

Просто желательно не злоупотреблять глобальными переменными, особенно shared / __gshared

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

история с прошлой работы на цпп. почти каждый класс в хэдере имел екстерн инстанса. из за этой херни почти все модули зависели друг от друга, и компиляция занимала по 15 минут. это так здорово создавая новый проект на основе тех исходников с уверенностью инклюдить ВСЕ. кстати это был военный проект) наши налоги в надежных руках, какбе

Вот этот словарь хочу сделать глобальным неизменным CTFE: static immutable uint[7][char] ssrIdGnss = [ 'G' : [1057,1058,1059,1060,1061,1062,2065], 'R' : [1063,1064,1065,1066,1067,1068, 0], 'E' : [1240,1241,1242,1243,1244,1245,2067], 'J' : [1246,1247,1248,1249,1250,1251,2068], 'C' : [1258,1259,1260,1261,1262,1263,2070] ]; Но dmd выдаёт: D:\SRC\D_lang\SSR>dmd -m64 ssr.d ssr.d(218): Error: non-constant expression ['G':[1057u, 1058u, 1059u, 1060u, 1061u, 1062u, 2065u], 'R':[1063u, 1064u, 1065u, 1066u, 1067u, 1068u, 67u], 'J':[1246u, 1247u, 1248u, 1249u, 1250u, 1251u, 2068u], 'C':[1258u, 1259u, 1260u, 1261u, 1262u, 1263u, 2070u]]

Значения в словаре зафиксированы, меняться не будут.

Далее в коде идёт некоторая манипуляция с ними и на основе этого словаря (ssrIdGnss) создаётся ещё несколько, такого же типа, константные, заданные раз и на всегда.

Ну сообщение достаточно однозначное - в immutable данные вставляешь мутабельные массивы

Вот этот словарь хочу сделать глобальным неизменным CTFE: static immutable uint[7][char] ssrIdGnss = [ 'G' : [1057,1058,1059,1060,1061,1062,2065], 'R' : [1063,1064,1065,1066,1067,1068, 0], 'E' : [1240,1241,1242,1243,1244,1245,2067], 'J' : [1246,1247,1248,1249,1250,1251,2068], 'C' : [1258,1259,1260,1261,1262,1263,2070] ]; Но dmd выдаёт: D:\SRC\D_lang\SSR>dmd -m64 ssr.d ssr.d(218): Error: non-constant expression ['G':[1057u, 1058u, 1059u, 1060u, 1061u, 1062u, 2065u], 'R':[1063u, 1064u, 1065u, 1066u, 1067u, 1068u, 67u], 'J':[1246u, 1247u, 1248u, 1249u, 1250u, 1251u, 2068u], 'C':[1258u, 1259u, 1260u, 1261u, 1262u, 1263u, 2070u]]

вместо static immutable пробовал enum?

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

Если массив совсем статический, то зачем его делать массивом? По нему итерироваться надо?

Сделай 5 статических подмассивов.

uint[7] ssrIdGnssG = [1057,1058,1059,1060,1061,1062,2065];

Спасибо, попробую предложенные варианты.

да, кстати, ассоциативные массивы, получается только через static this() инициализировать можно?

https://forum.dlang.org/thread/suvgfdsgyuynpmdmdjfz@forum.dlang.org?page=1 сам спросил, сам ответил: да)

Вот этот словарь хочу сделать глобальным неизменным CTFE: static immutable uint[7][char] ssrIdGnss = [ 'G' : [1057,1058,1059,1060,1061,1062,2065], 'R' : [1063,1064,1065,1066,1067,1068, 0], 'E' : [1240,1241,1242,1243,1244,1245,2067], 'J' : [1246,1247,1248,1249,1250,1251,2068], 'C' : [1258,1259,1260,1261,1262,1263,2070] ]; Но dmd выдаёт: D:\SRC\D_lang\SSR>dmd -m64 ssr.d ssr.d(218): Error: non-constant expression ['G':[1057u, 1058u, 1059u, 1060u, 1061u, 1062u, 2065u], 'R':[1063u, 1064u, 1065u, 1066u, 1067u, 1068u, 67u], 'J':[1246u, 1247u, 1248u, 1249u, 1250u, 1251u, 2068u], 'C':[1258u, 1259u, 1260u, 1261u, 1262u, 1263u, 2070u]]

Так вот делай и все будет работать: static immutable uint[7][char] ssrIdGnss; shared static this() { ssrIdGnss = [ 'G': [1057,1058,1059,1060,1061,1062,2065], 'R': [1063,1064,1065,1066,1067,1068, 0], 'E': [1240,1241,1242,1243,1244,1245,2067], 'J': [1246,1247,1248,1249,1250,1251,2068], 'C': [1258,1259,1260,1261,1262,1263,2070] ]; }

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

будет, плохо через enum

да, кстати, ассоциативные массивы, получается только через static this() инициализировать можно?

Увы, да. ИМХО, косяк компилятора. Должен разрешать подобное делать

Увы, да. ИМХО, косяк компилятора. Должен разрешать подобное делать

Хотя, может я и не прав. Все-таки ассоциативный массив слишком сложная структура, чтобы быть куском константно инициализированной памяти.

Ну да там же используется хешмап для того чтобы хранить ключи, небось что-то аллоцируется. Просто так не построишь

Это надо статический субрантайм придумывать :) И мета-мета-программирование

Так вот делай и все будет работать: static immutable uint[7][char] ssrIdGnss; shared static this() { ssrIdGnss = [ 'G': [1057,1058,1059,1060,1061,1062,2065], 'R': [1063,1064,1065,1066,1067,1068, 0], 'E': [1240,1241,1242,1243,1244,1245,2067], 'J': [1246,1247,1248,1249,1250,1251,2068], 'C': [1258,1259,1260,1261,1262,1263,2070] ]; }

Спасибо, Евгений!

Спорно. По крайней мере для LDC

Оно вроде работает, только из другого (использующего) модуля не видно: ssr.d(402): Error: undefined identifier ssrIdGnss;

Имя модуля и имя файла должны совпадать?

Получаю какие-то ругательства линкера:

ssr.obj : warning LNK4217: локально определенный символ _D4gnss9headLenIdxHkAk импортирован в функцию _Dmain gnss.obj : warning LNK4049: импортирован локально определенный символ

Оказывается public надо ставить

Оказывается public надо ставить

зачем? И да, имя модуля и файла должно совпадать

зачем? И да, имя модуля и файла должно совпадать

А зачем тогда module?

А зачем тогда module?

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

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

Последняя с конца?

Хм да? А вроде бы нет

скажем module super.puper.hello; означает, что файл hello.d лежит в папке super/puper

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

И что нам это даёт?

И что нам это даёт?

ничего кроме головной боли

Если оно так, то оно удобно и однозначно

ERROR: S client not available

Всегда можно легко найти код модуля в файловой системе

Всегда можно легко найти код модуля в файловой системе

иногда это мешает

но в целом пофиг

Ну да может, но в целом то удобство и ясность это хорошо

можно директиву module не указывать

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

может я что-то не до конца понимаю в этой системе

Ясно это, конечно, хорошо, но вообще такая модульная система посылает нафиг файлы с именем с точкой

Ясно это, конечно, хорошо, но вообще такая модульная система посылает нафиг файлы с именем с точкой

да

и файлы с минусом в имени

но в целом особо не мешает

Now, you *can* possibly name the module differently using a module statement, but this is highly discouraged. If you do this, the only way another module can import your differently-named module is if you pass the file on the command line.

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

Странное правило

Странное правило

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

но в целом особо не мешает

Не мешает, но все равно я считаю, что require чем-то лучше такого

откуда именно require?

Из JS, я имел ввиду

Эм разве JS поддерживает модули?

require там вроде просто функция подгружающая модуль, причем в рантайме

Эм разве JS поддерживает модули?

Как часть стандарта - нет, в стандарте есть import, но который толком незаимплементирован.

require там вроде просто функция подгружающая модуль, причем в рантайме

Верно. Но у меня стойкое убеждение, что require смотрится куда более продуманым и органичным в JS, чем эти модули в D

В D, кстати, можно вызвать функцию без импорта?

Ну можно весь модуль импортировать и тогда да

Тогда это уже с импортом будет

можно типа import module.module : function;

если не охота все импортировать

только смысл не понятен)

чего экономить. чтобы ide не тормозила?

Ну когда импортов на 2 страницы текста, в каждом из которых нам нужна одна функция...

Можно делать сборки из этих импортов и объединять их в public import

Например создаешь модуль importall.d и там импортируешь 200 токенов через public import. А во всем остальном коде делаешь import importall