Программирование на C++ под Windows в Linux

сервачок

Так то сервачок. Мы сейчас о ПК говорим.

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

Вот только занимают куда больше места (физически).

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

Откалибровал, прогнал заново - все равно вижу нищебродствующую школоту.

Откалибровал, прогнал заново - все равно вижу нищебродствующую школоту.

Значит, он у тебя устарел.

Что, нынче не только школота «зарабатывает» разработкой hello, world-ов на нетбуках?

... Ну, положим да... На железе экономить сильно не имеет смысла. Но и решать проблемы говнокодеров криворуко-скрипторылых железом тоже не стоит.

В принципе, человеку, осилившему «Tao of the UNIX programming» должно быть достаточно известно и о модульности программного обеспечения и о том, как модули должны связываться и как они должны меж собой общаться (да-да-да, средства IPC) и о том, почему «большие проекты» долго в таком... «большом» виде не живут. Их, как правило, переписывают, используя модульность. Если софт построен по такому принципу, то компиляция и установка отдельных модулей (autotools в помощь) не требует каких-то неэпических затрат по времени. Ну и в общем и целом отладка/профилирование модульного софта не требует каких-то офигевающих ресурсов от железа.

Собственно, именно по этой причине в Linux/UNIX всегда старались отделить графический front-end от собственно рабочего софта (рекомендую посмотреть на nmap и transmission и графические нахлобучки к ним). С оффтопом все по-плоше, там такое разделение провести куда сложнее. По-этому и приходится извращаться с чем-то «легковесным» (как ни крути, а нативные средства самые легковесные, чтобы ни утверждали поклонники кросс-платформенных решений), а не тянуть в систему что ни попадя.

Qt 4 выручит тебя.

Тогда уж Mono.

Их, как правило, переписывают, используя модульность.

Ну, перепиши, для начала, WebKit. «Используя модульность». Время пошло.

Есть системы объективно сложные.

Кроме того, есть ведь еще и LTO. Для получения выгод от которого нужно много-много памяти. А еще есть профессиональные системы статического анализа кода, которым тоже много ресурсов требуется.

... кстати, сударь, почти угадали. :))) Сейчас «перепеваю» на основе dillo и gtk (в пень wxWindows, у меня GNOME 3) свой такой недобраузерок для оперативного поиска информации. Причем, использую именно gtk на всю голову, например, GIO вместо BSD sockets. Работа идет по остаточному принципу, да и выносить на обсуждение в стиле «нинужна» не охота. Так что, глядишь, пердячим паром, по-маленьку, по-тихоньку да и доделаю. Или не доделаю, ибо задач и так до задницы и выше...

Причина тут проста — сколько процентов из возможностей WebKit используется в повседневной работе? Ноль целых, хрен десятых? Что, подавляющее большинство сайтов используют WebGL? Canvas? На тех сайтах, где это используется, технической информации для меня нет. Ну вот и получается что бесспорная «объективная сложность» проекта просто на хрен не нужна.

Для систем статического анализа кода не так много памяти и нужно. Регулярно пользуюсь splint/rats. Просто, обрабатывать надо не весь проект от и до, а куски. Написали кусок, проверили, пишем/проверяем другой. И все будет хорошо. :)))

Для систем статического анализа кода не так много памяти и нужно.

Нужно. Много. Попробуй coverity.

Регулярно пользуюсь splint/rats.

Это не системы статического анализа кода. Это какое-то позорище.

Просто, обрабатывать надо не весь проект от и до, а куски.

Это так же бесполезно, как unit-тесты. Важно анализировать поведение системы в целом.

Пример схемы работы:

Для тестов ставь виртуалку (виртуалбокс) с вендой. Туда ставь cygwin с sshd и средствами разработки . Это все тебе позволит автоматизировать тесты. То есть набрал make xxx / my_test_script - оно залезло на венду, там скомпиляло, там же потестило - вернуло результаты. Для работы обычно хватает вайна, ну или даже просто линукса.

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

Для некоторых программистов и программ это все просто не подходит.

Ну, перепиши, для начала, WebKit. «Используя модульность». Время пошло.

А он уже модульный. Лейаутилка отдельно, движок js отдельно, интеграция с тулкитом отдельно.