мои 5 копеек:

- согласен с тем, что Qt в нынешнем post-Nokia состоянии просуществует года 3, а вот дальше уже большой вопрос, но не умрет ни в коем случае
- считаю, что для Qt лучшим вариантом выжить была бы интеграция... в Андроид, хотя понимаю, что это почти нереально, любительские самоделки всерьез не принимаю
- последней надеждой является, безусловно, форк, а тут уже зависит - кто возьмется, и с какими целями и ресурсами, у коммерческого Qt более 3500 клиентов, причем это преимущественно крупные и богатые компании, кто-то из них может не захотеть терять основу и потенциальный доход, и перехватит эстафету, правда вот при этом самая вкусная LGPL может исчезнуть

спс, написал...

Давно хочется, чтобы в редакторе можно было сворачивать скобки препроцессора #if-#ifdef/#else/#endif

Где лучше написать feature request? В bugreports.qt.nokia.com вроде только багрепорты, а запросов, особенно на доработки Кретора, не могу никак найти.

тфу блин, locale/setlocale... я уже и забыл про них давно...

да, setlocale( LC_NUMERIC, "C" );

вылечило, стала использоваться точка

но это странно, поскольку в системной локали точно указана точка, а по умолчанию в приложении localeconv()->decimal_point содержит ",", и все поля настроены на русский, как если бы приложение использовало не системную локаль

не может ли Qt устанавливать локаль приложения по-своему? может при инициализации Qt правильнее сказать, чтобы он ставил системную локаль? я с этим в Qt еще не полностью разобрался, подскажите, кто знает хорошо

Честно говоря, не совсем понятно, где об этом стоит посоветоваться, решил лучше здесь. Формат вещественных - это вроде как тоже "локализация". Проблема скорее всего не чисто Qt, очевидно stdlib, однако она возникла при переносе Qt-приложения, здесь наверняка больше опытных в этом людей, значит здесь больше вероятность найти правильное решение.

Некая библиотека была написана на С (!++), изначально (достаточно давно) и разрабатывалась в Linux Debian, потом перенесена в WinXP, сейчас обратно. Приложение использует эту библиотеку, отлаживаю его в Kubuntu 10.10 уже с использованием Qt. Обнаружил такой неожиданный эффект - перестали распознаваться вещественные числа. И формироваться соответственно тоже. Для преобразований в библиотеке используются давно отлаженные нижние функции, они вызывают sptintf() и atof(). Раньше все работало, в Debian без фокусов все преобразовывалось туда-сюда. В Windows тоже проблем не возникало. Разделитель целой и дробной частей - точка, функции из стандартных библиотек ее всегда понимали. Причем, в Windows не зависимо от того, какая локализация и формат вещественных установлен в системе. В Debian локализация была русская, разделители по-умолчанию (наверно, сейчас уже не проверить). В Kubuntu сейчас тоже русская локализация, в системной локали специально установлен разделитель "точка". Но функции stdlib почему-то лепят и понимают... запятую.

И че-то пока как-то не понятно, что с этим делать... Использовать какие-то другие библиотечные функции нельзя - нижний уровень опирается только на стандартные библиотечные средства, это идеологически обоснованно, поскольку библиотека используется в разных проектах, на разных платформах. Можно, конечно, накатать собственные ftoa и atof, хотя это не так тривиально, как может показаться (когда-то очень давно писал ftoa, c тех пор решил, что лучше буду всегда пользоваться библиотечными).

Или это баг сборки конкретной stdlib/stdio? В Win сборка и отладка производятся с использованием mingw, а не MS библиотек. И с mingw все работает правильно! Может кто-нибудь сказать, что происходит в разных версиях Linux? Почему системная локаль не влияет на формат вещественных чисел в стандартной библиотеке?

спасибо всем за ответы, сейчас сборка с Qt 2010.05 в Lin и Win, соотвественно, QtCreator последний, переходить на MSVC не хочется, желательно иметь гомогенную отладку в обеих ОС

не понятно только, как правильно баг-репорт сделать, чтобы "там" смогли воспроизвести, это еще повозиться самому надо, чтобы на простом примере оно также падало - а на такую работу время еще надо найти

кстати, когда делалась отладка в первых QtCreator в Win, он без проблем работал, ничего не падало

Средний по размерам проект содержит С и С++ код, делается давно. До сих пор такого глюка не наблюдалось, проект создавался в Qt 4.5, перенесен из Windows в Linux. В Kubuntu 10.10 собирается с использованием Qt 2010.05, работает, нормально отлаживается в Qt Creator. Сейчас установил такой же Qt 2010.05 в WinXP, перенес проект, он собирается, работает. Отладка запускается, на контрольной точке становится. Но при попытке открыть на просмотр содержимое какой-либо С-структуры, gdb слетает. Те же самые действия в Linux - все нормально работает, структуру показывает. В отличие от Linux версии при установке в Win я включил post-mortem debugging, может здесь что-то не так? Как его отключить без переустановки? Никогда им не пользовался, хотел попробовать для ознакомления.

Если не поможет, писать bug report? На что - на gdb или на QtCreator for Win?

В WinXP использовал QtCreator какой-то старой версии 1.х, весны 2010 - все без проблем работало, при изменении <>.ui файла вызывался uic и генерил файл ui_<>.h - проект перенесен в Linux, используется QtCreator 2.0.1. uic почему-то не вызывается, пришлось его руками вызвать из командной строки. Добавить его в Этапы Сборки не проблема, но имхо так не должно быть. qmake вызывал принудительно - ничто не влияет. Что не так? Почему в Makefile нет вызова uic? Ответа в Сети не нашел.

а черт... и правда есть, другой программист main() писал больше года назад... спс, вопрос снят

библиотека тут совершенно ни при чем, ее функции используются потом, надо для этого сформировать строку в текущем системном 8-и битном эквиваленте unicode-представления, поскольку работать она умеет только с 8-и битными символами

toLocal8Bit, согласно документации, возвращает строку в 8-и битной кодировке, в чистом Linux это, по идее, должна быть koi8-r - а в виртуальной машине похоже это 1251...

завтра проверю на Kubuntu 10.10 на обычной машине, правда там памяти очень мало, компиляция медленная из-за свопинга

результат совпадает с вариантом


во всех этих случаях получаю одинаковую строку, являющуюся char-представлением Unicode строки

для библиотеки нужны char, а не wchar

но если VMWare ни при чем - то откуда появляются символы в кодировке 1251, почему при конвертировании с этим кодеком текст правильный??

но софт должен работать и в win, без изменений - а там работает toLocal8Bit(), хотя можно конечно, условной трансляцией...

наверно FAQ-овый вопрос, если обсуждалось, просьба ткнуть, поиском не нашел

для ввода строки в приложении используется QLineEdit, строка вводится, получена QString

потом надо преобразовать в С-строку, поскольку используется библиотека, написанная на С, для этого сделано так (S это полученная в редакторе QString):


в win все работает,

приложение портируется в lin, но в чистой системе пока некогда проверить, делалось в VMWare Player на XP, в KUbuntu 10.10

оказалось, что после преобразования toLocal8Bit() полученный массив содержит испорченный текст, как при открытии в lin UTF-8 текста, созданного в win

если же сделать так:


то массив ba и соответственно строка s получаются в эмуляторе читабельные

я так понимаю, 1251 кодировка вылазит из-за того, что это все происходит в эмуляторе, работающем в windows, если нет, то поправьте

очевидно, что привязывать к конкретной национальной кодировке нет смысла - во-1ых, в lin должно быть все нормально (завтра только смогу проверить), во-2ых программа может использоваться и с другими национальными кодировками

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

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

да и вообще это сбивает с толку

да просто если строке присвоить - в ней уже нет ./  

то есть, баг таки есть, но в другом месте