Тебе надо хранить список соединений (в твоём случае он длиной 1) и всем желающим давать к нему доступ через залочивание-разлочивание

это называется "пул"

Ну я бы делал не одно...

Хотябы несколько

Но все зависит от ожидаемой нагрузки

мне пока как проще т.к. эти вопросы я честно плохо уже понимаю...

Тогда делай одно)))

А у нас нет никаких интерфейсов для структур? Надо всегда писать в шаблоне проверку на наличие определенных методов?

Юзай класс

static this() это аналог синглтона будет? или в чем разница его и ... ?

А у тебя многотредовое приложение или какое?

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

Ну если в один то и синглтона впринципе достаточно, а если в несколько то только пул

я так и не понял принципиальную разницу синглтона и static this

вроде же оно одно и тоже делает

Ну грубо говоря да

Но синглтон еще сам следит за тем чтобы база была инициализирована, и делает это если она еще не.

а static this это не сможет?

А с static this тебе надо будет где-то в начале вручную базу инициализировать, и это может затеряться среди другого кода, или ты потом случайно удалишь и т.д.

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

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

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

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

Лучше сразу делать Пул

Пусть из одного соединения, но пул

Потом меньше переделовать нужно будет

Вообще да, пул с одним соединением внешне почти ничем не отличается от синглтона :)

твой код в любом случае будет дергать метод ->getConnection() который будет возвращать в класс свободное рабочее подключение.

А у нас нет никаких интерфейсов для структур? Надо всегда писать в шаблоне проверку на наличие определенных методов?

именно так

В чем выигрыш или профит структур перед классами?

по rvalue быстро передаются

на самом деле не только это

не надо держать ничего лишнего, а каждый класс по умолчанию наследуется от object

по умолчанию объект структуры алоцируется в стеке

по умолчанию объект структуры алоцируется в стеке

this

но объекты класса тоже можно алоцировать в стеке

через scope

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

Кстати аллоцировать их на стеке я не пробовал, интересная тема. В этом случае gc особо и не требуется?

получается, что так

В чем выигрыш или профит структур перед классами?

http://stackoverflow.com/questions/10965577/usage-preference-between-a-struct-and-a-class-in-d-language ответ по теме

Читал это, но советы спорные если судить о картине в целом

Reason #3: If you have a type with a lot of data members, then you're probably going to want a reference type (to avoid expensive copying),

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

согласен, сомнительный довод

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

структуру тоже по ссылке можно передавать

классы и структуры идеологически разделены: классы это ООП, структуры это просто данные

Вообще если класс создать на стеке, думаю это самый крутой вариант. Потому что так-то классы гораздо удобнее структур.

классы медленней структур

любой метод в классе виртуальный, любой метод в структуре финальный

виртуальный метод -> поиск в таблице

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

Вот в моем случае у socks5 протоколоа есть несколько пакетов, с помощью которых устанавливается соединение. При этом каждый пакет имеет первый байт 0x05, и должен контролировать целостность этого поля. И еще есть всего пара правил по чтению этого пакета из сокета. Было бы удобно засунуть всю эту логику в базовый класс а все пакеты отнаследовать от него. Но из-за лагов пришлось делать для каждого пакета структуру, и копипастить туда логику чтения и проверки.

Немного спасли миксины.

тут вопрос производительности

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

С другой стороны, на каждое соединение таких пакетов создается всего 5-6 штук, это в принципе не смертельно. прокся изначально не рассчитана чтобы десятки тысяч коннектов держать.

про выделение памяти на стеке: scope вроде deprecated

allocator как-нибудь для этого надо юзать теперь по стилю

https://wiki.dlang.org/Memory_Management#Allocating_Class_Instances_On_The_Stack

да, написано, что планируется удалить

пишут использовать scoped

https://dlang.org/deprecate.html#scope%20for%20allocating%20classes%20on%20the%20stack

да, да

и там же написано использовать scoped

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

ERROR: S client not available

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

типа слишком много на scope повешано (можно как атрибут аргумента функции, можно для guard statement, можно классы на стеке)?

можем стукнуть на форум)

типа

ахренели)

Не, классы на стеке глюкавыми были

норовили копироваться

новый cfte движок уже в dmd или нет?

Как я понимаю он в мастере, если ошибаюсь поправьте

Const позволяет меняться значению выше его передачи в список аргументов функции, immutable вообще не меняется, хоть в ПЗУ прошивай

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

Да. И это не фигня, это очень полезно

к примеру?

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

тогда и private - фигня

*сарказм*

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

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

мол ты обязуешься не менять значение, а он обязуется проверять это

а если const в аргументах - это обещание функции не менять значение (если по ссылке передано)

с модификаторами доступа аналогично

хотя мне лень придумывать пример

короче это сугубо для программиста?

ну и мифическая оптимизация компилятора

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

даже в C++ компилятор может нехило оптимизировать с const, а уж в D подавно

короче это сугубо для программиста?

тут всё для программиста. если готов этим манкировать переходи смело на brainfuck )

делать проверку на наличие методов стоит в объявлении шаблонов? void mod(T)(T a) if (hasMember!(T, "len")) { writeln(a.len); }

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

а смысл? ошибка компиляции будет при обращении к несуществующему методу

void mod(T)(T a) if (is(typeof(a.foo(int.init, string.init))) { a.foo(5, "hello"); }

эмм

Иногда можно делать, чтобы показать пользователю шаблона чего в него передавать вообще