Здравствуйте, GreyMan, Вы писали:

GM>Буст версии 1.47 биндит функцию с соглашением __cdecl, но спотыкается на __stdcall
GM>И самое интересное:
GM>В указанном примере ошибки появляются, когда выполняется бинд обоих функций.
GM>Если закоменнтить одну из строк, ошибок нет.
GM>При этом, MS VC в случае с примерами на структурах, генерирует два разных типа. И преспокойно компилирует.

поузнаю в списках рассылки.

Еще более минималистиный пример, имхо, откуда ноги растут:
[ccode]
template<class F> struct Struct {
Struct (){};//необходимо явно объявить конструктор.
//без объявления ошибка не возникает
};
int main()
{
Struct<void __stdcall(*)()> cs;//1
Struct<void __cdecl(*)()> cc;//2
// обе строки должны находится в одном файле.
// если в разных — то ошибки не наблюдается
}
[ccode]
Сообщение об ошибке уже приводил:
Error: symbol `__ZN6StructIPFvvEEC1Ev' is already defined|
Словно что-то не различает конструктора двух разных типов.

Здравствуйте, GreyMan, Вы писали:

GM>Сообщение об ошибке уже приводил:
GM>Error: symbol `__ZN6StructIPFvvEEC1Ev' is already defined|
GM>Словно что-то не различает конструктора двух разных типов.
Не пробовали переименовать переменные? В старых версиях помню были какие-то внутренние клучевые слова, которые gcc по своему усмотрению пользовал.

Здравствуйте, Vain, Вы писали:

V>Здравствуйте, GreyMan, Вы писали:

GM>>Сообщение об ошибке уже приводил:
GM>>Error: symbol `__ZN6StructIPFvvEEC1Ev' is already defined|
GM>>Словно что-то не различает конструктора двух разных типов.
V>Не пробовали переименовать переменные? В старых версиях помню были какие-то внутренние клучевые слова, которые gcc по своему усмотрению пользовал.
Неет, имена тут не имеют отношения:

void myfoo(void(__cdecl*)()){}
void myfoo(void(__stdcall*)()){}
int main(){}

Эта ошибка вылетает даже в таком случае.
Но ведь для Винды это вполне легальная перегрузка же?

Здравствуйте, GreyMan, Вы писали:

GM>Но ведь для Винды это вполне легальная перегрузка же?
а я хз. никогда не использовал ни __cdecl ни __stdcall.
нужно соответствующую тему создать.

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, GreyMan, Вы писали:

GM>>Но ведь для Винды это вполне легальная перегрузка же?
X>а я хз. никогда не использовал ни __cdecl ни __stdcall.
X>нужно соответствующую тему создать.
VС различает такое дело. (Хотя было бы странно, если бы не различал))
Но при этом несовместимость типов по соглашению об вызовах mingw поддерживает, и присвоить не тот указатель не выйдет.
Собственно, все это не проблема, но вдруг кому-то приспичит использовать с функторами функции из DLL, которые имеют полное право иметь не то соглашение об вызовах, которое в данном компиляторе по умолчанию?))

Здравствуйте, GreyMan, Вы писали:

GM>VС различает такое дело. (Хотя было бы странно, если бы не различал))
GM>Но при этом несовместимость типов по соглашению об вызовах mingw поддерживает, и присвоить не тот указатель не выйдет.
GM>Собственно, все это не проблема, но вдруг кому-то приспичит использовать с функторами функции из DLL, которые имеют полное право иметь не то соглашение об вызовах, которое в данном компиляторе по умолчанию?))

узнаю у разрабов.
спасибо что сообщили о таком поведении.

просьба.

покажи плиз вывод команды 'gcc -v', и полный вывод сообщения компилятора об описанной ошибке. у меня сейчас нет доступа к венде.
спасибо.

Отослал в личку.

таки да, разрабы подтвердили что это windows specific баг G++.

объяснение звучит так:

The reason why g++ isn't able to distiguish between
calling-conventions for C++-function names is caused by the fact that
g++ doesn't use the calling-convention within mangled C++-name.
VC does this and so you have indeed two different signatures.

оформил баг-репорт.
жду подтверждения.

были пересобраны все сборки версии 4.7.2 с суффиксом 'rev1', в связи с двумя(1, 2) добавленными патчами для make, и в связи с появлением в проекте пайтона собственной сборки.

думаю, через несколько недель тестов, будет релиз 0.4.0.

в качестве подготовки к релизу 4.8.0, были собраны сборки с использованием dwarf/sjlj/seh. (dwarf только 32бита, seh только 64бита)
найти их вы можете в поддереве testing: http://sourceforge.net/projects/mingwbuilds/files/host-windows/testing/4.8.0/

такой вопрос возник.
есть желание производить сборки так, чтоб минимально необходимый минимум по архитектуре проца, был nocona. кто на каких архитектурах работает?
был найден человек, который использует mingw-builds на каком-то p4, на котором сборка собранная для nocona не хотела работать. появилась ошибка типа "неизвестная инструкция".

спасибо.

такой вопрос возник.
есть желание производить сборки так, чтоб минимально необходимый минимум по архитектуре проца, был nocona. кто на каких архитектурах работает?
был найден человек, который использует mingw-builds на каком-то p4, на котором сборка собранная для nocona не хотела работать. появилась ошибка типа "неизвестная инструкция".

спасибо.

На http://www.cyberforum.ru вы обещали начать "формировать пакеты для разработчиков состоящие из компилятора(mingw), IDE(QtCreator/CodeBlock/Dev-C++/wxDev-cpp), и некоторого набора предкомпилированных библиотек(boost, Wx, Qt, OpenSsl, и еще каких-то.. понять бы что в спросе...). пакеты не будут требовать установки/настройки. распаковал — используй."
Или я совсем ослеп, или Вы решили уйти от этой практики или еще что, но на Вашей основной странице http://sourceforge.net/projects/mingwbuilds
я не найду НИ таких пакетов готовых, НИ мануала: а как поставить Ваш mingw с учетом необходимых MSYS, "предкомпилированных библиотек(boost, Wx, Qt...."
и какой-нить IDE.

Можно узнать что делается по этому поводу?

Здравствуйте, Аноним, Вы писали:
А>Или я совсем ослеп, или Вы решили уйти от этой практики или еще что, но на Вашей основной странице http://sourceforge.net/projects/mingwbuilds
А>я не найду НИ таких пакетов готовых, НИ мануала: а как поставить Ваш mingw с учетом необходимых MSYS, "предкомпилированных библиотек(boost, Wx, Qt...."
А>и какой-нить IDE.

А>Можно узнать что делается по этому поводу?
очень много времени ушло на то, чтоб сделать MinGW-builds лучшими из доступных сборок MinGW. я на самом деле не предполагал, что на это может потребоваться почти целый год.

касательно вопроса: менеджер пакетов уже написал. основной функционал работает. проблема в том, что менеджер пакетов написан на bash, и в MSYS, он нереально медленно работает.
и нормального тестирования все еще не производилось..

в общем, обещанное почти выполнено, приватно.
возможно, через несколько месяцев будем выдвигать это дело в публичное пользование/тестирование.

плюс в догонку хочу понять, что такое "sjlj" и "dwarf". Причем последнее есть только для 32-битной версии пакета.

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, Аноним, Вы писали:
А>>Или я совсем ослеп, или Вы решили уйти от этой практики или еще что, но на Вашей основной странице http://sourceforge.net/projects/mingwbuilds
А>>я не найду НИ таких пакетов готовых, НИ мануала: а как поставить Ваш mingw с учетом необходимых MSYS, "предкомпилированных библиотек(boost, Wx, Qt...."
А>>и какой-нить IDE.

А>>Можно узнать что делается по этому поводу?
X>очень много времени ушло на то, чтоб сделать MinGW-builds лучшими из доступных сборок MinGW. я на самом деле не предполагал, что на это может потребоваться почти целый год.

X>касательно вопроса: менеджер пакетов уже написал. основной функционал работает. проблема в том, что менеджер пакетов написан на bash, и в MSYS, он нереально медленно работает.
X>и нормального тестирования все еще не производилось..

X>в общем, обещанное почти выполнено, приватно.
X>возможно, через несколько месяцев будем выдвигать это дело в публичное пользование/тестирование.

Чтож — очень приятно видеть, что дело двигается, особенно с учетом того, что Ваш пакет признан Qt сообществом как основной.
Ну ок — пакеты — будут готовы позже. Подождем, хотя очень трудно ждать))
НО как насчет хотя бы мануала — как установить ручками то, что Вы в недалеком будущем сможете поставлять в виде пакетов?
Типа вот первый шаг — качаем то-се. Потом второй шаг — ставим-добавляем-исправляем.... И т.д.
И чтоб все шаги завершались фразой (и реальной ситуацией) "и вот теперь у вас на диске находится полная версия среды разработки, основанная на mingw и выбранной вами IDE."

Здравствуйте, Аноним, Вы писали:

А>плюс в догонку хочу понять, что такое "sjlj" и "dwarf".
в гугле полно подобной информации.
вот первое что нагуглилось: http://llvm.org/docs/ExceptionHandling.html#id7

A>Причем последнее есть только для 32-битной версии пакета.
потому, что поддержку DWARF для мингв-x86_64 не портировали.

Здравствуйте, Аноним, Вы писали:

А>НО как насчет хотя бы мануала — как установить ручками то, что Вы в недалеком будущем сможете поставлять в виде пакетов?
наверное будет мануал.
как придет время писать его, я свяжусь с Вами, надеясь на помощь. контакты оставьте.