В документации по std::istream есть такая специализация этого istream:

istream& operator>> (istream& ( *pf )(istream&));

Но при попытке вывести поток в указатель на функцию с такой сигнатурой конпелятор ошибается и ругается. ЧЯДНТ? Правильно ли я вообще понимаю эту специализацию для operator >> ?

В документации говорится о наличии у qi::lexeme какого-то pre-skipping, но что это такое, и как оно выглядит, я так и не понял. Если кто знает — подскажите.

А какое фокусное расстояние, например, у Акопяна (который Амаяк)? Больше ли оно фокусного расстояния Копперфильда (который Дэвид)? Если да, то насколько? Как мне измерить моё фокусное расстояние? Есть ли методики по его увеличению?

Чтоб тот редактор был с подсветкой семантики. А то всё синтаксис, да синтаксис. Кто что посоветует?

Если проходить boost::fusion::for_each-ем по boost::fusion::vector<type_0,type_1,..,type_N>, то каким отношением (типов) будет связан передаваемый (в функтор for_each-а) объект с исходным вектором?

Как можно/нужно читать из файлового потока двоичные данные (например, double), используя итераторы? При попытке специализировать istreambuf_iterator тем-же double компилятор ругается на невозможность специализировать им char_traits. Как поступить в данном случае? Изобретать более другой итератор, или специализировать char_traits для double?

В примере из руководства для boost::proto что может обозначать/выполнять код

proto::terminal<placeholder<0> >::type const _1 = {{}};

Есть ли возможность получить значение, возвращаемое функцией, привязанной к потоку boost-а? Если да, то как это сделать. В документации об этом не нашёл.

[url=http://multiki.arjlover.net]Вот он[/url]

Думаю, многим захочется что-нить оттуда скачать.

Потребовалось прицепить сигналы/слоты из boost-а к классу, у которого перегружен operator (). Пример может выглядеть так:

#include <iostream>
#include <boost/bind.hpp>
#include <boost/signals2.hpp>
//----------------------------------------------------------
typedef boost::signals2::signal<void (void)> VoidSignal;
typedef VoidSignal::slot_type VoidSlot;
struct Listener
{
 void operator () (void)
 { std::cerr<<"operator () (void)"<<std::endl; }
 void operator () (int value)
 { std::cerr<<"operator () (int)"<<std::endl; }
};
//----------------------------------------------------------
int main(int argc,char** argv)
{
 Listener listener;
 VoidSignal sig;
 sig.connect(VoidSlot(&Listener::operator (),&listener));
 /* Если у класса удалить operator () (int), то предыдущая строка компилируется */
 sig();
 sig.disconnect(boost::bind(&Listener::operator (),&listener));
 /* И здесь та же проблема */
 sig();
 return 0;
}

Что нужно подставить в первые параметры ViodSlot и bind при наличии нескольких operator () ?

Есть файл, достаточно большой, чтобы не возникало желание затолкать его в выделяемую память (new char[100500]), порядка нескольких сотен мегабайт. Как средствами плюсового stdlib (ну, на крайний случай, можно привлечь и boost) вырезать кусок из этого файла по указанным fpos_t? Результат, понятное дело, должен быть записан на место исходного файла.

Из первого вопроса логично вытекает и второй: а как вообще организуется работа текстовых редакторов, оперирующих большими и очень большими файлами? Как там делают вырезание, вставку, перемещение кусков текста? Есть литература для почитать? Или исходник какой не сильно здоровый, чтоб можно было в пару дней разобраться с его функционированием?

Собссно, subj. Читая документацию по boost::thread понимаю, что при создании экземпляра потока с передачей ему функции в конструктор, он сразу начнёт её исполнять. Мне это поведение слегка неудобно. Надо отложить запуск функции до заданной точки выполнения. Пока единственное, что придумалось, выглядит вот так:

#include <boost/thread/thread.hpp>
//-----------------------------------------------------
void thread_function(void)
{
 // Что-то делаем
 return;
}
//-----------------------------------------------------

class class_name
{
private:
 boost::thread th;
public:
 class_name(void)
 {
  // Здесь что-то выполняется до запуска потока
  th=boost::thread(thread_function); // Здесь должен стартовать поток
  // Может быть, что-то ещё надо сделать
  return;
 }
};

Решение так себе получается, не очень красиво. У потоков системы (что Linux, что Windows) есть параметр «создать спящим». Но в boost::thread я такого не нашёл. Или я неправильно понимаю вообще задумку boost-овских потоков? Кто что посоветует?

В процессе обживания Fedora 13 у Gnome-овских приложений обнаружилась мерзопакостная особенность: элементы выпадающего списка сворачиваются обратно, если не удерживать ПКМ на них. Я же больше привык к тому, что при щелчке по выпадающему списку он остаётся висеть без необходимости удержания его кнопкой мыши.

Есть ли настройки DE, или ещё чего нить, возвращающие «старый» режим функционирования? Если есть, то где их искать?

Смотрю на boost::MPI. Ничего не понимаю. Вот они дают пример

template <class F, class X>
struct twice
{
 typedef typename F::template apply<X>::type once;    // f(x)
 typedef typename F::template apply<once>::type type; // f(f(x))
};

Версия boost-а — 1.43.0, собираю под виндоузом, bjam-у задаю конфигурацию minimal. Создаются библиотеки libboost_date_time-mgw44-mt-1_43.a и libboost_date_time-mgw44-mt-d-1_43.a, но при попытке собрать пример, наподобие

#include <string>
#include <iostream>
#include <boost/date_time/gregorian/gregorian.hpp>
#include <boost/date_time/posix_time/posix_time.hpp>
//---------------------------------------------------------------------
int main(int argc,char** argv)
{
 boost::gregorian::date now(boost::gregorian::day_clock::local_day());
 std::cout<<boost::gregorian::to_iso_string(now)<<std::endl;
 return 0;
}

линкер ругается на 'undefined reference to `boost::gregorian::greg_month::as_short_string() const". В интернетах куча советов по этому поводу, но ни один не помог. Самое обидное, что на codepad.org этот пример всё же заводится. Значит, решение есть? Кто сталкивался, подскажите, что можно сделать для исправления ситуации?

Смотрю на описание member_types-ов std::map, и вижу там при объявлении std::map<Key,T> следующее:

mapped_type = T

value_type = std::pair<const Key,T>

Мне одному кажется, что по хорошему должно быть вовсе value_type = T и, соответственно, mapped_type = std::pair<const Key,T>? В чём логика нынешней структуры std::map?

Приложение должно работать как на винде, так и в линуксе. Поэтому настройки хранятся в ini-файле. При попытке записать изменённые настройки обратно в файл, кириллические и многие «служебные» (в том числе и пробел) символы записываются в виде их кодов, а не символьного представления. Попытки установить QTextCodec для экземпляра QSettings результата не приносят. Сталкивался ли кто с подобной проблемой, и есть ли варианты её решения?

Есть ли какие решения для генерации (по возможности автоматической) CMakeLists.txt из autotools-овских файлов конфигурации? Если есть, то киньте ссылки на них, пожалуйста.

Программа построена следующим образом: «пускалка» загружает в себя разделяемые библиотеки, и предоставляет им функции, в том числе и создания/удаления GUI-объектов. Если пытаться вызвать эти функции из потоков (QThread), в debug-сборке выкидывает ошибку runtime (src/corelib/thread/qthread_%OS%.cpp) на следующей строке:

void *QThreadPrivate::start(void *arg)
{
    // Symbian Open C supports neither thread cancellation nor cleanup_push.
#ifndef Q_OS_SYMBIAN
    pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL);
    pthread_cleanup_push(QThreadPrivate::finish, arg);
#endif

    QThread *thr = reinterpret_cast<QThread *>(arg);
    QThreadData *data = QThreadData::get2(thr);// !!! Здесь, в get2, ошибка runtime !!!

Если же собирать в release, то ограничивается сообщением в консоли.

Вопрос: есть ли возможность задавить это поведение, или как обойти его?

В самодельный класс инкапсулирован std::stringstream. Хочется, чтобы к данному классу можно было применять все манипуляторы. Но вот с параметризующими манипуляторами (std::setioflags, std::setbase, std::setfill, std::setprecision, std::setw) у меня выходит непонимание.

Как пример: std::setw вот здесь имеет какой-то странный возвращаемый параметр smanip. Покопавшись в исходниках iostream выяснил, что это — вообще какая-то структура с произвольным именем (у GCC своё, у MSVS своё).

Как организовать передачу таких манипуляторов std::stringstream-у?