в деструктор. и зачем scope(exit)?

чтобы соединение закрывать

просто я не хочу создавать отдельный метод: void finalize() // finalization of connection { conn.close(); } и потом вызывать его.

в деструкторе это и сделай. ~this() { conn.close(); }

Либо в какой-то другой момент закрой, после того как conn точно больше не нужен. Тут тебе виднее.

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

если ты создаёшь в конструкторе и удаляешь в деструкторе, то conn у тебя будет соединён ровно столько, сколько жив GeoDataBase. А я подозреваю, что это тебе и надо

void dbdata(HTTPServerRequest req, HTTPServerResponse res) // process rasters and { GeoDataBase gdb = new GeoDataBase(config); // } Получается что экземпляр gdb живет ровно столько сколько функция dbdata верно?

Просто я думаю над тем как потом пул подключений создать с БД

void dbdata(HTTPServerRequest req, HTTPServerResponse res) // process rasters and { GeoDataBase gdb = new GeoDataBase(config); // } Получается что экземпляр gdb живет ровно столько сколько функция dbdata верно?

Нет, GC может прийти сколь угодно позже. Поэтому и может быть полезен scope(exit). Ещё вроде бы было ключевое слово scope, если не путаю, при объявлении переменной.

Это внутри конструкторов scope(exit) для полей не то, для этого там деструктор

в dbdata можно написать scope(exit) destroy(gdb)

это повысить шансы на утилизацию gdb при первом проходе?

Олег, а не мог бы ответить на вот этот вопрос: Не приводит ли такой код к лишней аллокации памяти? jsonfromstruct = jsonfromstruct.replaceLast(,,``);

@DmitryBubnenkov могу предложить посмотреть адрес переменной до и после проведения операции. Если разный, следовательно новая переменная — копия.

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

тоесть вариант явной пометки это реально хорошая практика?

И как адреса переменных смотреть? Можно как-то без дебаггера это сделать?

writeln(&var);

о пасибо. После добавления: scope(exit) destroy(gdb) в момент прерывания приложения по ctrl + с выпало: ption.InvalidMemoryOperationError@src\core\exception.d(693): Invalid memory operation оно может быть связано?

нет. поправка. ошибка вылезает вот тут: ~this() { conn.close(); // finalization connection } если в деструкторе вызывать финализацию коннекта

если не вызывать то ctrl + с обрабатывается нормально

Так может надо обрабатывать что-то вроде INTERRUPT

Или уже есть обработчик?

неа, я даже не знаю что это такое и как обрабатывать

я предлагаю 2 варианта поискать как обрабатывать сигнал INTERRUPT. Или делать проверочку объекта conn

какую проверку?

ну как? if(conn !is null)

если коннект существует?

то можно сделать conn.close();

а так ошибка из-за чего вылезает?

пытаюсь закрыть то что уже закрыто?

полагаю, что пытаетесь обратить к тому, чего уже нет

http://www.everfall.com/paste/id.php?5qgjkf1z9f01 вот мой код

в каком моменте коннект может закрывать то?

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

та же байда

тогда надо дебажить(

я тут подумал — все же закрывать коннект в деструкторе это не праивльно, щас еще раз почитаю что мне там на форуме отписали

"Never run important finalization in a class destructor! The GC is not obliged to run the destructors, so you may end up with your objects destroyed but the connections still open. For this kind of important things, you have to do them manually."

+1

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

"Never run important finalization in a class destructor! The GC is not obliged to run the destructors, so you may end up with your objects destroyed but the connections still open. For this kind of important things, you have to do them manually."

not obliged? фигасе. это по спецификации или просто по багу так? неужели правда ноль гарантий?

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

Что по сути так и есть :) Ну впринципе закрыть коннект надо явно в явно вызываемом методе, а вот финализировать что-то там можно ив деструкторе

Вообще странно. Код написан, а будет ли он выполняться, никто не знает. Чревато не только незакрытыми соединениями, но и несброшенными в файлы буферами, что ещё серьёзнее. Неужто правда всё так плохо?

Макс, это вот тут ответ http://forum.dlang.org/thread/vkuvpzbczsyglfnnmygi@forum.dlang.org

Хотя там пишут люди, которые думают, что коннект в деструкторе закрывать надо: "but closing the connection to the DB is up to you. So do that in the destructor"

Я никак в толк не могу взять. деструктор в какой момент вызывается? Когда функция до конца доходит?

деструктор к функциям точно отношения не имеет, он с жизнью объекта связан

ну тобишь объекта

Вообще странно. Код написан, а будет ли он выполняться, никто не знает. Чревато не только незакрытыми соединениями, но и несброшенными в файлы буферами, что ещё серьёзнее. Неужто правда всё так плохо?

Ну выполняться то он точно будет, только вот когда конкретно - неизвестно. То есть классическое eventual consistency

То есть если объект в процессе живет неделю, то и деструктор может неделю не выполняться, пока объект не почистит кто-то

Instead you use a function, destroy(object), which calls the destructor where you can free resources that are not GC memory. The destructor will be caused again during GC collection of the objects own memory. This is explained in "The D Programming Language".

http://stackoverflow.com/questions/4589114/when-to-delete-in-d

То есть если хочешь чтобы все ресурсы у объекта освободились прямо сейчас, сделай destroy()

но закрытие коннекта это же не освобождение объекта

Ну да, поэтому и не надо закрытие конекта пихать в деструктор

А вообще как JSON можно склеивать?

~ подходит?

Json j1 = Json.emptyObject; j1["aa"] = 1; // { "aa": 1 } Json j2 = Json.emptyObject; j1["bb"] = 2; // { "bb": 2 } Нужно: { "aa": 1 }, { "bb": 2 }

просто сейчас сделал через значек ~ но на консоль только первый вывелся, щас конечно перепроверю все, но...

{ "aa": 1 }, { "bb": 2 } - это разве корректный json ?

Тогда уж [{ "aa": 1 }, { "bb": 2 }]

засунь два объекта в массив и попробуй это сконвертировать в json

а в массив как засунуть, кроме как добивки руками [ и ] и потом парсинга идей нет

а в массив как засунуть, кроме как добивки руками [ и ] и потом парсинга идей нет

создать ещё один json и потом добавить в него два эти объекта

ERROR: S client not available

Ну выполняться то он точно будет, только вот когда конкретно - неизвестно. То есть классическое eventual consistency

А, ну главное что «точно будет». Так-то общие минусы подхода с GC мне понятны.

Так, а как лучше всего проверить, прилетел ли JSON или было просто обращение к урлу. Просто ситуация такая. Есть урл /data на него json данные кидаются. если просто к нему обратиться, то ошибка 500 вылетает. Думаю как получше обработать ее

такой вариант норм? if (result.type == Json.Type.undefined)

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

значи что-то не то

можно как-то проверить навроде: if (req.json is Json) ?

В http://vibed.org/api/vibe.http.server/HTTPServerRequest я не вижу методов которые позволили бы понять, что именно прилетело

@DmitryBubnenkov так а через writeln нельзя посмотреть тело запроса?

Не помню точно, но вроде пустая строка была

Смотри, я с vibe.d не работал, но немного разбираюсь в HTTP и в Django. В запросе задаются заголовки, среди которых указывает тип данных запроса. Заголовок называется Content-Type. И если в теле json, то у этого заголовка должно быть значение application/json. Если в vibe.d нет метода для определения типа данных запроса, то стоит поискать метод для получения HTTP заголовков. Он-то уж наверняка должен быть.

+1 проверяй по Content-Type http://vibed.org/api/vibe.http.common/HTTPRequest.contentType

?

тут мелькала либа какая-то для json, в чём её соль?

вроде stdx.json

std.json как std.xml чем-то плох и нуждается в замене?

где-то видел, что std.json долгий

У vibe.d вроде свой JSON, но я не знаю, почему

Ну вроде так с любой сериализацией "на все случаи жизни".

У dub тоже свой, но там, кажется, тупо ради висячих запятых :)

разве у dub свой, а не из vibe.d?

http://code.dlang.org/packages/std_data_json

кандидат в std из vibe.d

разве у dub свой, а не из vibe.d?

Ну не знаю, лежит в их исходниках: https://github.com/dlang/dub/blob/master/source/dub/internal/vibecompat/data/json.d Но я глубоко не глядел на самом деле.

Ааааа! Любопытно! version (Have_vibe_d) public import vibe.data.json; else:

хм

Значит ли это, что vibe.d тоже толерантен к висячим запятым, как и dub.json? Или это значит, что если собирать dub с Have_vibe_d (а когда и для чего так собирают, кстати?), то он перестанет быть толерантным? Или это значит, что я мало чего вообще понимаю?

Наверное, это просто скопированный кусок vibe.d в дабе.

а кто-нибудь встречал реализацию сериализации/десериализации без JSONValue?

чтобы, например, mixin'ом строилась функция сериализации в json-строку

и чтобы парсинг строки сразу в структуру шёл

то есть без шаблонов?