Здравствуйте, гость ( Вход | Регистрация )
Iron Bug | Дата 11.10.2010, 13:21 |
Аццкая жесть или как под вендой заставить STLport выводить в консоль русские буквы (ну или какие-либо, которые в коде присустствуют) в UTF-8 (убила целый день, чтобы просечь, как это сделать!). Суть была в том, чтобы не переписывать кучу проектов под STLport iostreams. Частично стащено отсюда, поправлены ошибки и выдернута часть только для венды (для линя и так всё работает, без особого выпендрёжа). Честно говоря, вдаваться в тонкости и разбираться во всех хитросплетениях локалей (а это самое моё ненавистное место в программах!) мне не хотелось. Это решение маленькое, возможно, не самое оптимальное, но оно РАБОТАЕТ. Раскрывающийся текст
Используется просто вызовом
перед началом работы. Собирается с опциями использования юникода. Вывод стандартный:
|
|
Iron Bug | Дата 8.10.2010, 9:50 |
В общем, под вендой у меня всё заработало. Есть некоторые тонкости, которые сразу просечь трудновато. Во-первых, практически вся конфигурация STLport фактически задаётся в файле STLport-x.x.x/stlport/stl/config/user_condig.h. Во-вторых, чтобы эта настройка через файл подействовала, надо обязательно пересобрать STLport с опцией clean: Цитата nmake /fmsvc.mak clean install Без clean он тупо переименовывает библиотеки и в итоге получается бардак. Со статической/динамической линковкой я разобралась, но это дофига информации. Вроде там всё логично, но весьма трудно для изложения в единой связке и долго. Поэтому если будут какие вопросы - пишите сюда, попробую ответить. |
|
Iron Bug | Дата 7.10.2010, 15:52 |
Чуть поторопилась я с вариантом сборки STLport c бустом: он не собирается с ходу с новыми бустами. Однако, это не мешает собирать буст с самим STLport и писать проги с использованием STLport и boost. Сам STLport из буста юзает только type_traits, это не критичная фича. Так, сбоку бантик. В новых бустах там не много изменилось: пару заголовков переместили. Может, попозже напишу патч для STL, чтобы он собирался с новым бустом, если будет время. Инструкцию чуть подправила по этому поводу, в остальном вроде всё правильно. Только что собрала другую версию буста с STL. Сейчас буду пересобирать и проверять свои глобальные проекты, которые активно юзают разные фичи STL. А я тем временем собрала то же самое под линём, с gcc. Скорее из любопытства, чем по необходимости. Пока ещё не проверяла компиляцию с проектами, но буст уже собрался. Надо сказать, что в венде эту связку собрать - это ещё цветочки! Под линём косяков с нестковкой буста и STLport было больше, а документации практически нет. Если эта химия заработает и кому-то понадобится вдруг - могу накатать аналогичную телегу и для линя. Хотя это геморно весьма: там стопицот мелких настроек там и тут. Но если заработает - я погоняю тесты на скорость. Про венду в инете пишут, что с STLPort проги быстрее робят. Надо проверить и под линюксом, ради интереса. |
|
Iron Bug | Дата 7.10.2010, 13:15 |
Ура! Я собрала STLport с бустом под студией 2005. Пишу маленькую инструкцию: Сборка STLport + Boost компилятором MSVC 2005 (я собирала с версиями STLport 5.2.1, Boost 1.44.0, MSVS 2005 SP1) 1. Качаем последнюю версию буста тут. Разворачиваем куда-либо. Допустим, пускай это будет папка c:/src/boost_1_44_0. Оттуда же качаем уже собранный bjam и помещаем bjam.exe в корневую папку с бустом (вообще, он поставляется прямо с бустом и можно его самостоятельно собрать, запустив bootstrap в корневом каталоге буста). 2. Качаем последнюю версию STLport тут. Разворачиваем куда-либо. Допустим, пускай это будет папка c:/src/STLport-5.2.1. 3. Собираем буст с заголовками STLPort: 3.1. В каталоге c:/src/boost_1_44_0/tools/build/v2 правим файл user-config.jam. Добавляем строку с указанием расположения заголовочных файлов STLport: Цитата using stlport : 5.2.1 : с:/src/STLPort-5.2.1/stlport ; Пробел перед завершающим символом ";" обязателен! (блок code убивает пробелы - так что вставляю в quote) (Буст добавляет букву p к именам библиотек, которая означает, что данная сборка собрала с STLport. Так что сборка безопасна, если у вас собраны другие варианты библиотеки). 3.2. Из корневого каталога буста (там уже лежит bjam.exe) запускаем bjam c нужными нам параметрами. Например, для полной сборки буста это будет такая строка: Обратите внимание, добавлена опция stdlib=stlport - это и есть указание использовать наш STLport. Запускаем bjam и идём отдыхать: собирается он долго и нудно. Чтобы было быстрее, можете добавить в строку опцию -jN, где N - количество ядер CPU у вас на компе - тогда он будет распараллеливать процесс сборки. Можете запустить bjam --help и посмотреть другие параметры: например, можно указать, куда конкретно складывать заголовки и библиотеки, и прочие такие полезные опции. 4. Собираем сам STLport: 4.1. Открываем консоль (cmd). Запускаем установку переменных окружения MSVC 2005. Если студия установлена в стандартном варианте, с 32-битной платформой, то это будет выглядеть так: 4.2. Далее НЕ ВЫХОДЯ из консоли, перемещаемcя в ней к нашей папке с STL (cd c:/src/STLport-5.2.1) и в этой папке выполняем следующую команду:
Я собирала со статической линковкой стандартных библиотек. Можете использовать динамическую, заменив опцию на --with-dynamic-rtl. 4.3. НЕ ВЫХОДЯ из консоли, переходим в каталог c:/src/STLport-5.2.1/build/lib и запускаем там команду
Ждём, когда скомпилится. Детально про сборку и возможности проверки собранного STLport можно почитать в файле c:/src/STLport-5.2.1/doc/README.msvc (правда, там опечатка с указанием опции компилятора - он задаётся без префикса -c). 5. Открываем студию и прописываем в студии пути для нашего STL: меню Tools->Options. Настройка VC++ Directories: Platform: Win32, Show directories for: Include files - добавить ПЕРЕД всеми стандартными путями путь c:/src/STLport-5.2.1/stlport Platform: Win32, Show directories for: Library files - добавить ПЕРЕД всеми стандартными путями путь c:/src/STLport-5.2.1/lib Собственно, всё. Код править не нужно, насколько я понимаю. У меня deque заработал без проблем. Просто перекомпиляция. P.S. Теоретически, можно собирать и без буста. P.P.S. Если вдруг кто-то захочет собрать и что-то вдруг не будет собираться - сообщайте. Я могла что-то упустить, хотя вроде бы всё написала и порядок не перепутала. |
|
Iron Bug | Дата 7.10.2010, 9:52 |
Блин. Где собрать? Как подключить? Внешне отличаться он не будет? ну, пока не знаю. поставила собираться. после обеда буду колупать, как его подключать к своей софтине. хотя там ещё не все опции мне пока понятны. пока что собираю простейший вариант с динамической линковкой. потом буду ковырять дальше, если потребуется. |
|
AD | Дата 7.10.2010, 8:42 |
Блин. Где собрать? Как подключить? Внешне отличаться он не будет? |
|
Iron Bug | Дата 7.10.2010, 8:40 |
я пока не утверждала, что опенсорцный STL эффективнее (хотя скорее всего так оно и есть). но если в MS STL жёсткие баги, то использовать его просто нельзя. тут не до эффективности, когда прога валится с access violation. сейчас вот как раз пытаюсь собрать один STL. |
|
AD | Дата 7.10.2010, 7:59 |
собственно, раз там всё равно баги, я планирую помаленьку перейти на опенсорцный STL и не парить себе моск. так оно надёжнее и ещё минус одна зависимость от мелкософта, который я терпеть не могу Я немного чайник в этом. Тема крайне заинтересовала (есть проект, жутко страдающий из-за низкой эффективности). Пара вопросов: как именно перейти с MS STL на Open-Source STL? Чем они в плане возможностей будут отличаться в контексте данной проблемы? |
|
Алексей1153 | Дата 6.10.2010, 22:34 |
и ещё минус одна зависимость от мелкософта, та ну, неспортивно шутка. |
|
Iron Bug | Дата 6.10.2010, 22:16 |
дебаг значения не имеет. масштаб мельче. смотри мелкие изменения на каждой итерации. смысл в том, что в конце каждого цикла память не возвращается в исходное состояние (как теоретически должно происходить, ибо вектор уничтожается), а наоборот растёт, пока не достигнет какого-то непонятного предела, затем падает до начального состояния и снова по кругу. это тестовая программка, данных мало, поток один. а вот если её нагрузить данными (засунуть вместо int какую-нибудь структурку или класс), да запустить пару-тройку потоков в параллели - тогда эффект будет сильно заметен. когда много потоков начинают работать с векторами (даже мелкими), создаётся ощущение, что у проги течёт память. собственно, я так и нашла эту "фичу": у меня у софтины память нарастала и нарастала. я насмерть билась, пытаясь найти мнимую утечку памяти. а потом заметила, что когда прога доходит до определённого предела, она "схлапывается" и снова начинает расти. начала копать, нашла статьи и выяснила, что это вектор гадит. просто об этом надо заранее думать, вот и всё. Резервировать же можно кусками а резервировать кусками не выходит - у меня никогда не известно, какой буфер накопится до момента, когда проснётся сливающий данные поток. это зависит от того, что будет выплёвывать хард и как будет нагружен проц. так что там заранее ничего нельзя предсказать. пишут несколько потоков, сливает один. при таком раскладе заранее планировать ничего невозможно. можно было бы кое-где заменить deque на queue, но в остальных случаях мне ещё нужны итераторы. а тут queue уже не проканает. собственно, раз там всё равно баги, я планирую помаленьку перейти на опенсорцный STL и не парить себе моск. так оно надёжнее и ещё минус одна зависимость от мелкософта, который я терпеть не могу |
|
Просмотр темы полностью (откроется в новом окне) | |
Текстовая версия | Сейчас: 29.3.2024, 19:03 |