Есть несколько разнородных вакансий: производство, программирование, электроника/схемотехника

В общем мне пишите, если сами интересуетесь подробностями или есть знакомые, которые интересуются

На dlang.org! Там раздел с мощным посещением на эту тему

Если касаться ди

Ребят, никто в мск работу не ищет?

на D?!

Территориально Зеленоград?

на D?!

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

Территориально Зеленоград?

территориально мосрентген

кузнецкий мост?

юг за мкадом 5км

Т.е это в 5 минутах езды от меня :)

Я правильно понимаю, что LDC скоро отвяжется от 64-битного линкера MS https://github.com/ldc-developers/ldc/issues/2028

Это хорошо или плохо?

по идее хорошо — для 64 бит студия на Window нужна не будет

Я правильно понимаю, что LDC скоро отвяжется от 64-битного линкера MS https://github.com/ldc-developers/ldc/issues/2028

очень печально, что у них достаточно медленно разработка идёт

так что этот issue может долго висеть, пока кто-нибудь не решит, что можно потратить пару дней на него

Кстати, в std_string есть две функции разбития строк: lineSplitter и splitLines как я понимаю разница только в том, что одна приводит к аллокации, другая нет. Вопрос. Зачем нужно две тогда вообще. И каким макаром работает та которая не приводит к аллокации?

слайсы возвращает?

S[] splitLines auto lineSplitter

и в array есть [] split()

не говоря уже о сплиттерах в std.algorithm

вот как раз про splitter http://dlang.org/blog/2017/05/24/faster-command-line-tools-in-d/. splitter - ленивый, split аллоцирует сразу всё

ну хорошо, допустим два это нормально, но их же как я понимаю 4 если не больше. Есть ли в этом смысл? Просто может проще их как deprecated сделать?

string.lineSplitter - видимо там свои тонкости, связанные с utf8 например. так что, больше сплиттеров, хороших и разных

есть у нас некий appender над статическими массивами в std?

видимо нету

кто-нибудь плотно использовал Appender?

тот что в std.array

Олег, я на SO про него спрашивал в контексте аллокации недавно. Щас постараюсь ссылку найти

Хотя с Appender всё ок, есть вопросы к RefAppender

Так, я с нова к БД вернулся. К теме как быть если коннекшен нужен в нескольких местах. А если мне класс просто статическим сделать?

Класс чего?

класс в котором создается подключение к БД

сделай, почему бы и нет)

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

да примерно те же

микрософт называет этот подход Ambient context, проблемы в большинстве случаев те же, что и у единого сервис-локатора, только нигде не надо таскать с собой ссылку на класс сервис-локатора

Так, я с нова к БД вернулся. К теме как быть если коннекшен нужен в нескольких местах. А если мне класс просто статическим сделать?

Уже ведь разобрались что тебе это не нужно?

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

@ahdenchik там в итоге каждый свое советовал. Вариантов много было. А в чем профит тогда сингл-тона если есть статический класс?

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

особенно, когда в языке есть статические конструкторы)

синглтон в виде объекта имеет смысл делать, когда он инициализируется с какими-то параметрами (конструктор вызывается с параметрами), а потом должен быть один на все время выполнения программы

@ahdenchik там в итоге каждый свое советовал. Вариантов много было. А в чем профит тогда сингл-тона если есть статический класс?

Забудь про синглтоны, они вообще не нужны (пример: дисплей)

когда то был 1 монитор и всё было ок, а потом оказалось что их может быть 10

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

и его смогут дёргать все желающие

https://github.com/DSoftOut/pgator у нас оно сделано так, можешь подсмореть

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

@ahdenchik там в каком месте смотреть?

щаа

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

тоесть статический класс в итоге?

ошибся с софтиной, вот https://github.com/denizzzka/vibe.d.db.postgresql

прямо в примере смотри

зачем статический?

смотрю...

типа shared PostgresClient client; создает переменную доступную для всех и дальше ею и пользуемся?

ага

а при многопоточном доступе глюков не будет?

можешь это и юзать, кстати - оно к vibe.d относится улсовно

не должно быть

тогда по логике и конфиг нужно shared делать он же один для всех

и еще кучу других вещей, которые глобально должны быть видны

Поэтому и сделан один класс. Писать рамшаренное сложно

Расшаренное

в плане сложно?

Shared очень вирусная штука

ERROR: S client not available

Тянет за собой много всего

к примеру?

к примеру?

если что-то shared, то всё что внутри должно быть либо защищено синхронизацией, либо тоже shared

коннект к БД нужно как-то защищать?

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

@ahdenchik получается что shared static this() { } можно только один раз объявлять\инициализировать?

Как данную ошибку исправить?

вместо new писать new shared

чтобы создать именно shared объект

блин

исправил, появилась ошибка: `database.d(46,20): Error: none of the overloads of '__ctor' are callable using a shared object, candidates are: mysql-native-1.0.0\mysql-native\source\mysql\pool.d(80,3): mysql.pool.MySQLPool.this(string host, string user, string password, string database, ushort port = cast(ushort)3306u, uint maxConcurrent = 4294967295u, SvrCapFlags capFlags = cast(SvrCapFlags)33293u)`

ну в ошибке то всё написанно

нет конструктора, который бы создавал shared объект

т.е. либа работать не будет?

ты, конечно, можешь просто кастануть

но не факт, что другие методы есть synchronized или shared

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

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

да

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

либы в которых этого нет они как называются? однопоточные?

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

да хз как они называются))))

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

но в D есть система типов

и следовательно ты просто так не сможешь такой код использовать в многопоточном стиле

в целом можно намутить обёртку с синхронизацией

но это тоже работа

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

может быть и удастся собрать, но многопоточное приложение без синхронизации это полный ад

Кстати, драйвер Postgres почему-то заработал просто с new без new shared