Фриланс? Как ты будешь писать софт в неродной ОС? Софт, который работает только под wine, никому не нужен.

Можно компилировать с помощью mingw и тестировать под вайном. Но виртуалка надёжнее (и может быть проще).

Можно потестить под виндой (виртуалка, или на крайняк, на нетбук поставить). Но постоянно ее юзать не в кайф

На данный момент от дуалбута можно убежать, только если писать под iphone/android. Но под iphone пишут только из под макоси. Так что можно взять в ручки NDK, одновременно освоить java, ну и предлагать свои услуги андроид-разработчика.

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

Хех, спасибо!

А почему не Qt?

Только это будет тестирование вайна, а не софта.

Можно потестить под виндой (виртуалка, или на крайняк, на нетбук поставить). Но постоянно ее юзать не в кайф

Доо, сильно ты потестишь, если там не живешь постоянно и не запускаешь там постоянно прогу. Только не рассказывай, что будешь «хорошо тестить» и т.д. - это даже не смешно.

убежал с Windows
фриланс, поэтому придется делать все на своем ПК

ССЗБ. Если дуалбута не хошь, собери VirtualBox из исходников под свой проц и поставь в него максимально чистый вантуз (если не критично, ставь XP). Иначе любая полноценная IDE в виртуалке будет неистово тормозить. И никакого антивируса.

Только это будет тестирование вайна, а не софта.

Ну, если программа работает под вайном, и специально не было сделано так, чтобы она не работала под windows, то в windows программа скорее всего работать будет.

WinApi
для реализации GUI

Как там живётся в девяностых?

По теме: Qt + виртуалка.

«Скорее всего» не устроит заказчика

Уж извините, особенно не в теме создания GUI, пишу пока только алгоритмы + консоль.

К сожалению, в среде фриланса не столь популярен QT, чтобы жить только этим, но за идею большое спасибо!

Ну я так работаю. Чего тут сверхъестественного?

Все собираю с помощью gcc. GUI на Qt + стопка опенсорсовых библиотек. Но тут момент - мне всякие специфические виндовые библиотеки (к примеру DirectShow) не нужны. Иначе, без вариантов - только винда, только студия!

Тестирование на нативной винде - другого пути нет!

А вот дебажить большую часть багов, можно и помощью wine.

Спасибо за хороший коммент!

Разрабатывать нужно в целевой платформе (с оговоркой, что это не какой-то эмбеддед), т.ч. ставь виртуалку и не выэтосамое.

Мой совет: Писать GUI на Qt, основное тестирование проводить в нормальной ОС. Раз в неделю полное тестирование в говноос.

И обязательно завести себе тестера с виндовсонли.

Пиши на Qt, тестируй под линуксом, в виртуалке держи венду и время от времени проверяй под ней.

Единственный момент — лучше пиши под 32 бита, под 64 легко написать кривой непортабельный код, если ты не гуру с++.

Спасибо! Решил все же QT + виртуалка, редко - полный тест на оффтопе...

Осиль Qt и кросс0-компиляцию. </thread>

Забей на Qt и пиши на чистом WinAPI - это проще и быстрее, заодно освоишь доступ ко всем вендовым фичам. Да и заказчик, получив от тебя экзэшник в пару десятков килобайт вместо двух сот метров, с большей вероятностью придёт еще раз. Чисто гуёвый WinAPI должен нормально отрабатывать под вайном плюс можно задействовать «нативные dll» - так что базовый интерфейс можно слабать и протестить под линуксом, с потрохами системы работать придётся уже на реальной ОС.

Какие есть варианты?

Забыть что такое WinAPI и юзать исключительно кроссплатформенные либы. Тестить на линуксе а для заказчиков компилировать и отдавать экзешник.

Очень правильный коммент...

... Для работы с оффтопом. Всецело поддерживаю! Только добавлю малость от себя.

Во-первых, Qt и «кросс-платформенность» заказчику как-то по барабану. Ему важен размер исполняемого кода, его отношение к ресурсам системы. Почему-то Qt-филы считают что только их код будет исполняться в системе. И, типа, все ресурсы компа пойдут только на их код. Полная фигня! Заказчик, как правило, хочет на одной машине в стиле оффтопа и играть и править документы и еще Бог знает что ему там в голову взбредет. Как следствие, ни когда нельзя быть уверенным в том, что ресурсов хватит.

Во-вторых, LamerOk прав. Для оффтопа гуевую часть лучше делать на WinAPI. Причем, пофиг 32 или 64. WinAPI одинаково работает в обоих случаях. В принципе, выбор языка здесь не критичен — что С, что С++ хороши одинаково. Но вот сборку я бы рекомендовал делать в MinGW. Само собой что под wine можно протестировать гуевую часть, здесь LamerOk тоже прав. Но вот по поводу «потрохов» системы нужно уточнить. Что именно подразумевается под «потрохами»? Если работа с каким-то хитровыкруженным железом через USB, то хватит вайна (HAL там в принципе поддерживается, но вайн надо донастраивать на конкретную версию оффтопа). Если какие-то трюки с «безопасностью», то лучше бы нативный оффтоп.

Ну и само собой, что в MinGW может пойти и нативный Linux код. Например, в свое время без правок удавалось получить рабочую версию софта (точнее части софта), использующую epoll(). Хотя, надо заметить, что соотв. реализация epoll() для оффтопа, входящая в набор MinGW основана на Windows Socket Architecture (WSA), так что... все будет несколько «весело» в итоге, но тут уже дело выбора — переносить софт или писать отдельный вариант для оффтопа. Эта возможность есть.

Иначе любая полноценная IDE в виртуалке будет неистово тормозить

O_o У вас пентиум 4?

пентиум 4?

Шо? По-моему, здесь просто кто-то слоупок и ему пофиг на скорость работы.

Спасибо! Но делать сложное GUI на WinApi весьма незаурядное занятие :)

Да вроде на нормальном железе и без запар с пересборкой все не тормозит.

«Нормальное железо» - это 8 гигов рамы и 4-хъядерный процессор? Ну-ну.

Ну да, не для нищебродов.

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

А на хера ты собрался заниматься тем, в чем не компетентен? Как будто мало работы без всякой гуйни.

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

Вот только простаивает эта топовая конфигурация слишком долго. Не всё ж такое грузное...

Вот только простаивает эта топовая конфигурация слишком долго.

Не распарсил

Не всё ж такое грузное...

Виртуалки по определению грузные. А серьезным разработчикам обычно их надо более одной.

Возможно Вы и правы...

... но в почти любом случае незаурядного гуёвого интерфейса его в любом случае будет хлопотно реализовать (что в GTK, что в Qt, что в WinAPI). /* Кстати, да, чем проще, тем лучше. :) */ Но в любом случае, главное... не шугать юзера своей гуйнёй, простите, своим... гуём. :) Самое вредное — когда мало того, что юзер должен напрягать остатки своего межушного ганглия при работе с софтиной, так она ещё и ресурсы жрёт как свинья помои. Ставить рантайм Qt ради... одной софтины? Нет уж, увольте. Мне проще найти (или написать) аналог. Собственно, тогда-то и рождаются легенды про тормоза некоего софта. Поверьте на слово, но если известно что юзер будет пользоваться GNOME, то первое что я сделаю — забью на Qt. Ну, для WinAPI тоже самое верно.

Гы-гы-гы...

... Некогда мой мир перевернулся. :) Это было когда я увидел сырцы нетбаса. На Дельпях. :)))

Кстати, да, Вы правы — либо пишем говнософт и пущщаем его на некоем «супержелезе», либо пишем нормальный софт и тогда требования к системе будут значительно скромнее. Да и затраты на профилирование/оптимизацию несколько пониже будут. В итоге.

Не распарсил

Большинство софта жрёт, как птичка.

Виртуалки по определению грузные.

Только с Виндой >NT5 и Хакинтошем >10.3. Остальное ещё куда ни шло. А, ну ещё Ондроед (если ARM).

Большинство софта жрёт, как птичка.

И что? Конфигурация-то выбирается под пиковую нагрузку.

 Только с Виндой >NT5 и Хакинтошем >10.3.

Любые, если у тебя десяток снапшотов, которые ты скриптами откатывашеь по нескольку раз в час.

Остальное ещё куда ни шло. А, ну ещё Ондроед (если ARM).

Для одной только сборки Андроида нужно 16Gb минимум, если чо.

Да и затраты на профилирование/оптимизацию несколько пониже будут. В итоге.

Кстати, и для всяких там valgrind и gprof тоже железо нужно весьма нехилое.

Повторяю еще раз - на железе для разработки экономить будет только дебил.

Виртуалка как бы требовательный софт по определению. Иногда проще купить нормальный комп, чем красноглазить.

Виртуалку нельзя заменить выделенным компьютером. У тебя не будет тех же возможностей отладки, не будет снапшотов, не будет автоматизируемого тестирования.

Конфигурация-то выбирается под пиковую нагрузку.

Для пика есть своп. Если постоянно работать на пике, то это уже не пик.

которые ты скриптами откатывашеь

Но зачем?

Для одной только сборки Андроида нужно 16Gb минимум, если чо.

Да шо вы говорите. Разве что за n-е время. За сутки - хватит и одного.

Для пика есть своп.

Ты тупой? Допустим, собираешь ты срених таких размеров проект в debug. Для компиляции, даже с -j8 (или сколько там у тебя ядер) хватает 2Gb памяти. А вот линкер (даже если это gold) сожрет все 6 и не подавится. Если у тебя они есть, то компиляция займет минуты. Если линкер пойдет по свопу шариться, то можешь и час-другой прокуковать.

Да шо вы говорите. Разве что за n-е время. За сутки - хватит и одного.

Диванные теоретеги такие диванные! Школота - вон с ЛОРа!!!

Виртуалка как бы требовательный софт по определению.

Ну, я бы не сказал. Виртуалка - компьютер в компьютере, так что для неё (при хорошей оптимизации) нужен просто в два раза более мощный компьютер для достижения той же производительности. Разумеется, если она в одно и то же время открыта только одна. Если человек работает с 8-ю виртуалками кряду... я не представляю, что он такое может разрабатывать.

Виртуалку нельзя заменить выделенным компьютером. У тебя не будет тех же возможностей отладки, не будет снапшотов, не будет автоматизируемого тестирования.

Под красноглазием я имел в виду другое, а именно сборку виртуалки под _свой_ процессор, чтобы она БЫСТРЕЕ РАБОТАЛА ОЛОЛО. Я вовсе не призываю заменять виртуалку компом

Если человек работает с 8-ю виртуалками кряду... я не представляю, что он такое может разрабатывать.

Вполне, какой-нибудь сервачок на ксеоне, на котором крутится много виртуалок для нескольких разработчиков.

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

Ровно до тех пор, пока тебе не понадобится заниматься отладкой и/или профилированием.

Если человек работает с 8-ю виртуалками кряду... я не представляю, что он такое может разрабатывать.

А, ну я так и подумал, что школоло мамкиного борща объелось и вылезло потеоретизировать.

Вот когда займешься сам реальной разработкой, за которую деньги платят, тогда и возвращайся.

срених таких размеров

А конкретнее?

Если линкер пойдет по свопу шариться, то можешь и час-другой прокуковать.

Разуй глаза, есть SSD.

Школота - вон с ЛОРа!!!

Гоу чинить детектор.

Школоло, лишние 8Gb памяти стоят дешевле, чем своп на SSD.

Ровно до тех пор, пока тебе не понадобится заниматься отладкой и/или профилированием.

Если софт достаточно модульный (а не компилится в один огромный бинарник), серьёзных задержек не возникает.

А, ну я так и подумал

Значит, тебе лучше сегодня много не думать.

Вот когда займешься сам реальной разработкой, за которую деньги платят, тогда и возвращайся.

А НЕогромные проекты ты реальной разработкой уже не считаешь?