crossplatform.ru

Здравствуйте, гость ( Вход | Регистрация )


  Ответ в Адекватная замена для MS STL deque?
Введите ваше имя
Подтвердите код

Введите в поле код из 6 символов, отображенных в виде изображения. Если вы не можете прочитать код с изображения, нажмите на изображение для генерации нового кода.
 

Опции сообщения
 Включить смайлы?
Иконки сообщения
(Опционально)
                                
                                
  [ Без иконки ]
 


Последние 10 сообщений [ в обратном порядке ]
Iron Bug Дата 11.10.2010, 13:21
  Аццкая жесть или как под вендой заставить STLport выводить в консоль русские буквы (ну или какие-либо, которые в коде присустствуют) в UTF-8 (убила целый день, чтобы просечь, как это сделать!). Суть была в том, чтобы не переписывать кучу проектов под STLport iostreams.

Частично стащено отсюда, поправлены ошибки и выдернута часть только для венды (для линя и так всё работает, без особого выпендрёжа). Честно говоря, вдаваться в тонкости и разбираться во всех хитросплетениях локалей (а это самое моё ненавистное место в программах!) мне не хотелось. Это решение маленькое, возможно, не самое оптимальное, но оно РАБОТАЕТ.

Раскрывающийся текст
#include <Windows.h>
#include <iostream>
#include <locale>
#include <set>
#include <stdexcept>
#include <stdio.h>

using namespace std;

void configure_locale() {
    //Decoding of wchar in output only happens in unsynced mode.  
    ios::sync_with_stdio(false);
    //Platform dependent locale name building. Needed only for output encoding.
    char localeString[200];

    const int bufferLength=100;
    char buffer[bufferLength];
    // Obtaining user language
    long rc=GetLocaleInfo(GetUserDefaultLCID(), LOCALE_SISO639LANGNAME, (LPWSTR)buffer, bufferLength);
    
    //Checking for errors. Error codes taken from MSDN. Neither of them happened earlier.
    if (!rc) {
        switch (GetLastError()) {
        case ERROR_INSUFFICIENT_BUFFER:
            throw runtime_error("Insufficient buffer size while retrieving language info");
        case ERROR_INVALID_FLAGS:
            throw runtime_error("Invalid flags while retrieving language info");
        case ERROR_INVALID_PARAMETER:
            throw runtime_error("Invalid parameter while retrieving language info");
        default:
            throw runtime_error("Unknown error while retrieving language info");
        }
    }
    // Obtaining codepage. In sltport we may also use a string "OCP" instead of value returned by GetConsoleOutputCP().
    long cpInt=GetConsoleOutputCP();
    sprintf_s(localeString,100,"%ws.%d",buffer,cpInt);

    //A new short locale name is built. We can use it to init encoding conversions.
    typedef codecvt<wchar_t, char, mbstate_t> Code;
    Code * code=new codecvt_byname<wchar_t, char, mbstate_t>(localeString);
    //Resetiing global locale object.
    locale::global(locale(locale(localeString), code));
    //We should imbue new locale in iostreams.
    typedef set<wostream::_Basic_ios  *> Streams;
    Streams streams;
    streams.insert(&wcout);
    streams.insert(&wcerr);
    streams.insert(&wclog);
    streams.insert(&wcin);
    for (Streams::iterator i=streams.begin(); i!=streams.end(); i++) {
        if (!(*i))
            continue;
        (*i)->imbue(locale());
        (*i)->rdbuf()->pubimbue(locale());
    }
}

Используется просто вызовом
_wsetlocale(LC_ALL,L"russian");
configure_locale();

перед началом работы. Собирается с опциями использования юникода.
Вывод стандартный:
wcout << L"Русский текст";
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 нужными нам параметрами. Например, для полной сборки буста это будет такая строка:
bjam stdlib=stlport --toolset=msvc-8.0 --build-dir="папка, где будут храниться временные файлы во время сборки" --build-type=complete "путь, куда буст будет складывать готовые файлы"

Обратите внимание, добавлена опция stdlib=stlport - это и есть указание использовать наш STLport.
Запускаем bjam и идём отдыхать: собирается он долго и нудно. Чтобы было быстрее, можете добавить в строку опцию -jN, где N - количество ядер CPU у вас на компе - тогда он будет распараллеливать процесс сборки. Можете запустить bjam --help и посмотреть другие параметры: например, можно указать, куда конкретно складывать заголовки и библиотеки, и прочие такие полезные опции.

4. Собираем сам STLport:
4.1. Открываем консоль (cmd). Запускаем установку переменных окружения MSVC 2005. Если студия установлена в стандартном варианте, с 32-битной платформой, то это будет выглядеть так:
"С:\Program Files\Microsoft Visual Studio 8\VC\bin\vcvars32.bat"

4.2. Далее НЕ ВЫХОДЯ из консоли, перемещаемcя в ней к нашей папке с STL (cd c:/src/STLport-5.2.1) и в этой папке выполняем следующую команду:
configure msvc8 --with-static-rtl

Я собирала со статической линковкой стандартных библиотек. Можете использовать динамическую, заменив опцию на --with-dynamic-rtl.
4.3. НЕ ВЫХОДЯ из консоли, переходим в каталог c:/src/STLport-5.2.1/build/lib и запускаем там команду
nmake /fmsvc.mak install

Ждём, когда скомпилится. Детально про сборку и возможности проверки собранного 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, 11:42) *
Блин. Где собрать? Как подключить? Внешне отличаться он не будет?

ну, пока не знаю. поставила собираться. после обеда буду колупать, как его подключать к своей софтине.
хотя там ещё не все опции мне пока понятны. пока что собираю простейший вариант с динамической линковкой. потом буду ковырять дальше, если потребуется.
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
 
Цитата(Iron Bug @ 6.10.2010, 23:16) *
собственно, раз там всё равно баги, я планирую помаленьку перейти на опенсорцный STL и не парить себе моск. так оно надёжнее и ещё минус одна зависимость от мелкософта, который я терпеть не могу :)

Я немного чайник в этом. Тема крайне заинтересовала (есть проект, жутко страдающий из-за низкой эффективности). Пара вопросов: как именно перейти с MS STL на Open-Source STL? Чем они в плане возможностей будут отличаться в контексте данной проблемы?
Алексей1153 Дата 6.10.2010, 22:34
 
Цитата(Iron Bug @ 7.10.2010, 1:16) *
и ещё минус одна зависимость от мелкософта,

та ну, неспортивно :D

шутка.
Iron Bug Дата 6.10.2010, 22:16
  дебаг значения не имеет. масштаб мельче. смотри мелкие изменения на каждой итерации. смысл в том, что в конце каждого цикла память не возвращается в исходное состояние (как теоретически должно происходить, ибо вектор уничтожается), а наоборот растёт, пока не достигнет какого-то непонятного предела, затем падает до начального состояния и снова по кругу.
это тестовая программка, данных мало, поток один. а вот если её нагрузить данными (засунуть вместо int какую-нибудь структурку или класс), да запустить пару-тройку потоков в параллели - тогда эффект будет сильно заметен.
когда много потоков начинают работать с векторами (даже мелкими), создаётся ощущение, что у проги течёт память. собственно, я так и нашла эту "фичу": у меня у софтины память нарастала и нарастала. я насмерть билась, пытаясь найти мнимую утечку памяти. а потом заметила, что когда прога доходит до определённого предела, она "схлапывается" и снова начинает расти. начала копать, нашла статьи и выяснила, что это вектор гадит.

Цитата(Алексей1153 @ 6.10.2010, 21:27) *
просто об этом надо заранее думать, вот и всё. Резервировать же можно кусками

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

собственно, раз там всё равно баги, я планирую помаленьку перейти на опенсорцный STL и не парить себе моск. так оно надёжнее и ещё минус одна зависимость от мелкософта, который я терпеть не могу :)
Просмотр темы полностью (откроется в новом окне)
RSS Текстовая версия Сейчас: 29.3.2024, 8:54