- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
BOOL CIniFile::LoadIniFile()
{
CString csBuff;
CFile oIniFile;
if (oIniFile.Open(csIniFileName, CFile::modeRead))
{
ULONGLONG lenReal = oIniFile.GetLength();
DWORD dwLen = (DWORD) lenReal;
if (lenReal > UINT_MAX)
{
dwLen = UINT_MAX;
TRACE("ERROR: CIniFile::LoadIniFile(); CFIle::GetLength() > UINT_MAX\n;");
ASSERT(0);
}
if (!dwLen)
return FALSE;
boost::scoped_array <char> cBuffer(new char[dwLen]);
oIniFile.Read(cBuffer.get(), dwLen);
LoadIniFromBuffer(cBuffer.get(), dwLen);
oIniFile.Close();
if (GetCountRecords())
return TRUE;
}
return FALSE;
}
boost::scoped_array... nuff said =(
Follow us!
> lenReal
> dwLen
"len" идёт то как префикс, то как постфикс.
Хотя, может быть это эффект того, что над кодом работал не один человек...
про scoped_array гугл подсказал, а про program_options нет
Не нужен. Use std::vector, Luke! Познай силу тёмной стороны.
Конечно, об извратах типа подключения к проекту целого буста ради одного scoped_array я сейчас не говорю. Но уж если подключать ради чего-то другого, то грех не пользоваться.
и при обновлении или старте нового проекта настройка вашего рабочего места программиста начинается с переустановки винды?
Переустановка винды здесь ни при чём, просто некоторые особенности некоторых сорс-контролов + время от времени необходимость работать из разных мест (из дома, например).
Буст, впрочем, давно руки тянутся обрезать до минимально необходимой части, благо средства есть. Рано или поздно дотянутся.
когда буст используется в 100% проектов, его не нужно держать рядом с проектом
вы же не держите рядом с проектом в сурс-контроле VC/include, правда?
а то ведь тоже может так случиться, что дома стоит другая версия студии ;)
насчет breaking changes - я на работе его пользую где-то с версии 1.37, да, бывали случаи, но очень не критичные (один раз хедер надо иначе было включить, один раз дописать #define перед включением, один программист полюбил писать boost::system::system_category вместо get_system_category() - и спасибо что в какой то версии это выпилили наконец, ошибка ведь) - случаев очень немного было за 4 года, это не создает непреодолимых проблем
и на практике регулярный переход с 1.37 до 1.49 (иногда, быть может, с пропуском через 1-2) за эти годы ни разу не сломал ни один проект, ни один важный проект, во время их работы в поле
тестирование то понятное дело без нареканий
поэтому держать рядом с каждым проектом зоопарк всех версий буста - это всё от лени "да он тут чото ругается теперь, нунах" и страха "а ну как всё сломается, а я крайний"
не сломается
Нас это пока устраивает и регулярно себя оправдывает. Другая версия студии - плохой пример. Последнее, что помню из засад при обновлении буста - новая версия filesystem, замена вызовов path::string() на path::generic_string() по всему коду и ещё несколько прелестей, которые уже успел забыть. Хотя от этой конкретной либы нам вообще давно пора избавиться (пользовались только ради удобной работы с путями, а либа упорно затачивается на совсем другое).
Ну и вообще-то мы не "зоопарк всех версий" держим, а одну конкретную, с которой компилировали. Когда требуется выдать компилируемый код наружу (для портирования, или просто издателю для порядка), это делается простым копированием "как есть" (с обрезанием разве что объектных файлов или ещё чего-нибудь явно ненужного) и упаковкой. Когда нужно посадить на проект нового программиста - он просто забирает всё из перфорса и радуется жизни.
Может быть, в каких-то конкретных ситуациях это и "не нужно", но в нашей это работает и нам удобно. Практическую пользу от того, чтобы делать именно так, я вижу. От того, чтобы так не делать - разве что экономия места на серверах (не моя проблема, если честно).
>> один раз дописать #define перед включением
fixed
(c)
Между тем, уже 1.49. Честно говоря, не проверял - сдержали слово?
она станет deprecated только когда С++11 с копипащеной реализацией filesystem v2 предложит std::filesystem
в общем эту проблему в 1.46 или когда там появился v3 я решил именно так и это решение до сих пор отлично работает
что будет в 1.50 - не знаю, думаю, останется по-старому
В домашнем проекте я эту проблему решил кардинально - выбросил надоевший filesystem и написал несколько своих функций, которые делают то и только то, что мне было от него нужно, именно таким способом, который меня для моих задач полностью устраивает.
в filesystem не только склеивание путей, там еще и итерирование по директории, копирование и удаление файлов, размер файлов
и когда всё это надо делать кроссплатформенно, свой велосипед оказывается в проигрышном положении
именно про это я и говорю, если у вас один проект, использующий буст, то разницы, конечно, никакой
а когда ежеквартально выпуск очередных версий 4-5 проектов (продолжающихся несколько лет), и для каждого из них клеить именно ту версию буста, с которой он зарождался (особенно если проекту года 3 уже) - вот как раз прямой путь к зоопарку
особенно если эти проекты начинают в определенный момент шарить общие dll между собой, чтобы не дублировать некую функциональность
Двух одновременно на одном фреймворке обычно не делаем. Точнее, попытались как-то раз, но закончилось это заморозкой одного из проектов, т.к. из-за распыления команды страдали оба (с зависимостями это никак не связано). Вот сейчас один выпустили, второй размораживаем, так что опять всё вполне самостоятельно и ничего не шарится.
Не знаю, может, это был багфикс или значительное улучшение, но, думаю, многие согласятся, что подобные сюрпризы - далеко не всегда приятны.
Гугли возможность "внешние зависимости" своей системы контроля версий.
Имхо 3rd'party либы должны лежать отдельно от проекта (если вы их конечно не допиливаете).