На самом деле, это должно быть возможно.
Для WinXP через GINA, для Vista и более поздних, через механизм Credential Providers
Конечно, это не так тривиально.
Вроде бы, софт logmein такое умеет.
Относительно кода, мне бы хотелось порекомендовать автору несколько вещей:
— Взять нормальный компилятор с поддержкой более новых стандартов. Например, бесплатную MSVS 2015, если так хочется именно Windows и продукты от MS.
Это позволит не городить велосипеды для работы со временем и потоками. Велосипеды тут плохи тем, что они врядли лучше кода в STL, а стороннему человеку вовсе не будут нужны.
— Почитать про RAII
Сюда же отнесу использование std::string/std::vector вместо ручного strdup + free.
— Именовать переменные согласно их назначения, профит очевиден.
В чем баг?
В очереди хранятся сырые указатели |Event*|
Затем оттуда достается указатель и делается pop_front()
Пока не сделают delete event, все будет в порядке, нужно будет просто вовремя удалить объект.
Я не знаю, что конкретно Вы имеете ввиду под JetCat API, у меня всего пара минут была на поглядеть.
Но `git grep blob` показал, что блобы таки используются в коде внутри JetCat.
Вот и вопрос — можно ли быть уверенным, что никто там не забыл дернуть вручную purge()?
Вместо того, чтобы отказываться по идейным соображениям от инструментов вроде умных указателей, можно было бы просто взять профайлер. Я уверен на 99%, что он покажет места типа этого, а не вызов инлайнового дестурктора умного указателя. Сколько раз и зачем там делается копия строк?
Нельзя было исходным блобом обойтись, расширить Base64 чтобы он мог работать с типом blob?
А тут точно все хорошо? В самом конце на ровном месте делается реаллокация + копия строки на операторе + (в худшем случае).
Поверьте, корректная и быстрая программа — не антонимы. И не обязательно для этого использовать ручное управление ресурсами.
Это ладно, лучше поправьте передачу nullptr в closedir()
Там много таких мест, где не проверяется указатель _dir.
Иначе может крешиться не только в тестовом коде.
Я Вам рекомендую просто собраться с ASAN\TSAN и найти кучу всего совершенно бесплатно.
А тесты стоит написать хотя бы ради себя же, начать с самых примитивных вещей.
Потому что если нет доверия базовому слою, то как с ним работать?
Ну так в том и смысл RAII, что ответственность с головы разработчика по освобождению ресурсов переносится на компилятор\стандартную библиотеку, у которых степень доверия гораздо выше.
А как иначе понимать, у кого нужно дергать purge() а у кого нет?
blob initial(100500);
blob copy1(initial);
blob copy2(copy1);
// Что тут делать?
Вы хотели дешевое копирование блобов, я понимаю.
Но разгребать потом вручную, где и что освобождать — не хочется.
А затем там DIR* dir == nullptr отдается в closedir(), чего делать не следует.
Сколько там еще таких подводных камней, никому не известно.
Тестов же нету от слова совсем.
Atom, как я понимаю, строится поверх Chromium, с какими-то своими патчами, судя по https://github.com/atom/libchromiumcontent
А основной код Atom написан на JS и Coffee Script.
Так что там внутри почти полноценный браузер.
Там же написано, когда это бывает полезно:
Иначе приходится писать код вроде
Вместо
Например, в C# есть похожая штука:
null-coalescing operator
Для WinXP через GINA, для Vista и более поздних, через механизм Credential Providers
Конечно, это не так тривиально.
Вроде бы, софт logmein такое умеет.
— Взять нормальный компилятор с поддержкой более новых стандартов. Например, бесплатную MSVS 2015, если так хочется именно Windows и продукты от MS.
Это позволит не городить велосипеды для работы со временем и потоками. Велосипеды тут плохи тем, что они врядли лучше кода в STL, а стороннему человеку вовсе не будут нужны.
— Почитать про RAII
Сюда же отнесу использование std::string/std::vector вместо ручного strdup + free.
— Именовать переменные согласно их назначения, профит очевиден.
Насколько проще было бы именовать
И комментарий не нужен, и код читать намного проще.
— Выложить код на github, чтобы не постить такие простыни кода.
Да, еще вопрос — зачем нужен динамический массив в классе t_buf_t?
Ведь там используется всегда только 2 последних сохраненных значения времени?
В очереди хранятся сырые указатели |Event*|
Затем оттуда достается указатель и делается pop_front()
Пока не сделают delete event, все будет в порядке, нужно будет просто вовремя удалить объект.
Но `git grep blob` показал, что блобы таки используются в коде внутри JetCat.
Вот и вопрос — можно ли быть уверенным, что никто там не забыл дернуть вручную purge()?
Вместо того, чтобы отказываться по идейным соображениям от инструментов вроде умных указателей, можно было бы просто взять профайлер. Я уверен на 99%, что он покажет места типа этого, а не вызов инлайнового дестурктора умного указателя. Сколько раз и зачем там делается копия строк?
Нельзя было исходным блобом обойтись, расширить Base64 чтобы он мог работать с типом blob?
А тут точно все хорошо? В самом конце на ровном месте делается реаллокация + копия строки на операторе + (в худшем случае).
Поверьте, корректная и быстрая программа — не антонимы. И не обязательно для этого использовать ручное управление ресурсами.
Там много таких мест, где не проверяется указатель _dir.
Иначе может крешиться не только в тестовом коде.
А тесты стоит написать хотя бы ради себя же, начать с самых примитивных вещей.
Потому что если нет доверия базовому слою, то как с ним работать?
А как иначе понимать, у кого нужно дергать purge() а у кого нет?
Вы хотели дешевое копирование блобов, я понимаю.
Но разгребать потом вручную, где и что освобождать — не хочется.
А затем там DIR* dir == nullptr отдается в closedir(), чего делать не следует.
Сколько там еще таких подводных камней, никому не известно.
Тестов же нету от слова совсем.
Здесь вот утечка памяти.
А что там с блобами происходит, вообще непонятно: там есть аллокации, а кто память освобождать будет — непонятно.
Итого — RAII в полной мере нет, тестов нет, баги есть. Использовать не стоит, по моему.
А основной код Atom написан на JS и Coffee Script.
Так что там внутри почти полноценный браузер.