Ычан: [d | b / bro / gf / hr / l / m / med / mi / mu / o / ph / r / s / sci / tran / tu / tv / x | es / vg | au / tr | a / aa / abe / c / fi / jp / rm / tan / to / vn / vo]
[Назад] [Вся нить] [Последние 50 сообщений]
Ответ в нить
Имя
Animapcha image [@] [?]
Тема   ( ответ в 8273)
Сообщение flower
Файл 
Пароль  (для удаления файлов и сообщений)
Параметры   
  • Прежде чем постить, ознакомьтесь с правилами.
  • Поддерживаются файлы типов 7Z, BZ, BZ2, GIF, GZ, JPG, MO, MP3, MP4, OGG, OGV, PDF, PNG, PSD, RAR, SVG, SWF, TXT, WEBM, XCF, ZIP размером до 5000 кБ.
  • Ныне 3097 unique user posts. Посмотреть каталог
  • Максимальное количество бампов нити: 500
135607610833.gif-(2.35KB, 491×314, Cpp1.gif)
8273
No. 8273    
Привет, ты ведь знаешь много компиляторов c++?
Я хочу наконец-то слезть со своего c++ Builder 6 и перейти на что-нибудь современное. Работаю я с OpenGL-графикой и обработкой огромных массивов данных, а требования у меня примерно такие:
Венда, да. Кроссплатформенность приветствуется, но не обязательна.
Бесплатное и свободное ПО. Продавать программу не собираюсь, но всё равно не хочется когда-нибудь начать париться с лицензиями.
Поддержка 64-бит (хочется спокойно загружать в программу файлы без ограничения на размер).
Желательно наличие конструктора форм. Хотя в крайнем случае те же кнопочки и бегунки проще будет написать на чистом OpenGL'е.

Немного ознакомлен с MS Visual C++ и Qt, но переходить не спешу. Студия пугает привязкой к .net и несвободной лицензией, по поводу Qt не знаю, подходит ли он.
В общем, очень прошу, подскажите мне что-нибудь подходящее, или убедите сделать выбор в пользу Visual Studio или Qt.
Заранее спасибо.

Первый раз в dev, местных традиций не знаю. Если задел чьи-то чувства — прошу прощения.
Развернуть все изображения
No. 8274    
135608171654.jpg-(355.39KB, 1260×1400, 5ce854d98562f99ef5d6a18bac4a165d.jpg)
8274
Если хочешь рисовать формочки для C++, думаю нужно выбрать Qt. У microsoft, afaik, сейчас все gui тулкиты на .NET, а managed c++ - это недоразумение.
Из свободных компиляторов, собирающих Qt, есть g++ и clang. Насколько хорош clang, я не знаю, icc хватает.
No. 8276    
>>8274
Автобусну рыжую мадоку.
QT Builder, наверное, будет идеальным вариантом. Только, то, что ты называешь "компилятор" на самом деле называется Integrated Development Environment.
No. 8277    
>>8276
QT Creator.
http://qt.digia.com/Product/Developer-Tools/
No. 8280    
>>8274
>>8276
>>8277
Спасибо. Значит, всё-таки qt. Попробуем-с.
No. 8282    
135610224432.jpg-(312.08KB, 800×1100, f1da931c3fc779332d7efa0a2ea33975.jpg)
8282
А я плюсану Visual Studio. И Visual Assist к ней. Все-таки стандарт разработки под венду, от ее же производителя. Хотя WinForms и привязан к .NETу и managed коду, практика показала, что довольно легко сделать гуй в управляемом классе, а всю логику вынести в набор неуправляемых, написанных уже классическим способом классов - это еще и приучает использовать шаблон MVC:3

Раз уж речь зашла про OpenGL, то можно вместо системного гуя использовать glfw + CEGui, например, чтобы формочки были красивыми и быстрыми(и кроссплатформенными, кстати).

Стивы, а поясните по QT: там используется свой компилятор, gcc, или микрософтовский? (при разработке под венду, естейственно)

И еще, воспользовавшись тредом, задам вопрос ОПа, только для линукса, так как мало с ним опыта имел - какую IDE посоветуете и почему?
No. 8283    
>>8282
> А я плюсану Visual Studio.
Там уже появилась система сборки?

>там используется свой компилятор, gcc, или микрософтовский?
Можно использовать и mingw и msvc. В обоих случаях в процесс сборки включается некий дополнительный этап кодогенерации.

> какую IDE посоветуете и почему
Из юзабельных есть eclipse и QtCreator. Мне достаточно vim и cmake.
No. 8284    
>>8282
> практика показала, что довольно легко сделать гуй в управляемом классе
Ох уж эти практики. C++ и так один из самых уродских языков, а managed - это вообще выкидыш-мутант. И находятся люди, которые на этом пишут и просят ещё.
No. 8285    
Голосую за Qt.
Qt-няша
No. 8287    
135613394888.png-(698.25KB, 1280×720, shot0260.png)
8287
> Работаю я с OpenGL-графикой и обработкой огромных массивов данных
> наличие конструктора форм
Выкинь из головы этот быдлопринцип привязывать главный алгоритм к гуям, сходи к венеролгу и прям так и скажи, «<имярек> подцепил билдер, что делать?»
> кнопочки и бегунки проще будет написать на чистом OpenGL'е.
Так ты формочки лепишь или огромные массивы данных обрабатываешь, я не пойму?
> В общем, очень прошу, подскажите мне что-нибудь
1. Отдели в своём мозгу компилятор и библиотеки от IDE;
2. gcc @ icc — вот твой выбор (у тебя же не амд?);
3. Забей на поддержку 64 бит. Даже Firefox дропнул поддерживать x86_64 сборки для венды, потому что тот пиздец, что там творится, не поддаётся описанию. По хорошему, чтобы открывать файл, используется вызов к операционной системе, и все языковые fopen() и ей подобные — лишь обёртки над системными вызовами. Соот-но если ось и/или её ФС не поддерживает оперативку и/или файлы на диске объёмом 4 GiB, ты с этим ничего не поделаешь;
4. Qt — жирный неповоротливый фреймворк для рюшечек. Я понимаю, почему ты хочешь взять именно это (сам такой был лет пять-шесть назад), но за то, где ты собираешься его применять, надо бить по щщам.
5. Есть полно других IDE, фреймворков и просто библиотек, начни с малого, я бы советовал попробовать писать интерфейсы на gtk2, не для того, чтоб потом этим зарабатывать, хотя это возможно, а для того, чтобы понять, как оно должно выглядеть без мегабайтов ненужного. А ещё есть WxWidgets и Code::Blocks например;
6. Вообще, никакой IDE не нужно, есть емакс.

>>8283
> Из юзабельных есть eclipse и QtCreator
Ты ещё NetBeans приплети, который жрёт по 700 метров на крохотный проект, падает по два раза в сутки, и при этом не имеет функции автосохранения из коробки.
No. 8288    
135614855636.jpg-(77.12KB, 500×453, tumblr_li8kl7tpjH1qa8ti8o1_500.jpg)
8288
>>8287
> Вообще, никакой IDE не нужно, есть емакс.
> емакс.

А туда уже добавили текстовый редактор?
No. 8289    
135616100421.jpg-(70.92KB, 450×540, 1286369096_kinopoisk_ru-luc-besson-1206812.jpg)
8289
>>8288
No. 8290    
>>8287
>привязывать главный алгоритм к гуям
ОП похоже что-то визуализирует. Как ты собираешься отвязать алгоритм визуализации от гуёв?
> Qt — жирный неповоротливый фреймворк для рюшечек.
ОП собирается использовать OpenGL. Лучшей интеграции с OpenGL нет ни у одного другого тулкита, кроме каких-нибудь CEGUI/MyGUI. Почитай на досуге про QGL.
>есть емакс.
Этот раздутый комбайн в свою очередь не нужен, поскольку есть vim.
>Ты ещё NetBeans приплети
"Женский" аргумент. См. "Двенадцать приемов литературной полемики", пункт 7.
No. 8291    
ОП на связи.
Моя задача — обсчитывать и сравнивать огромные файлы, а также визуализировать результаты в реальном времени. Данные общим объёмом превышают 32-битное ограничение.
Есть решение хранить всё на диске, строить оптимизацию и держать в памяти только то, что нужно для непосредственной обработки, но это и реализовывать будет неудобно, и жёсткий диск захлёбывается. Скорее всего, в таком случае работа в реальном времени невозможна.
Гуи мне определённо нужно, даже если его придётся «рисовать» самому, в окне OpenGL. Не проще ли использовать готовое решение?
Протестировал 32-битный Qt. Выглядит красиво, изящно. Очень многого не знаю, куча времени уйдёт на переучивание (пришлось искать в мануалах даже такие элементарные вещи, как преобразование числа в строку и обратно).
Сделал простой тест — сколько памяти выделяет программа (на 32-битном Qt): результат не отличается от Builder'а. Протестировал и Visual C++ — там раза в 4 меньше и жуткие тормоза. Таким образом не вижу строгой необходимости пока уходить с Билдера, если не найду чего-то объективно лучшего: с лицензиями меня никто трогать не будет, программу я не продаю.
Также обнаружил, что готовой 64-битной Qt под Windows нет, но её можно (!) собрать самому:
http://habrahabr.ru/post/79233/
Повторюсь, что местных традиций не знаю. Если здесь ненавидят этот сайт — прошу не бить.
Это вообще реально? Игра стоит свеч? Или кто-нибудь может предложить мне свежую идею?

Заранее спасибо.
No. 8292    
ОП тролль. Зачем тебе какой-то там гуи тулкит если твоя задача - именно визуализация. Будь мужиком - используй голый openGL и не выпендривайся.
No. 8293    
135620002284.png-(763.55KB, 1280×720, shot0086.png)
8293
>>8290
> ОП похоже что-то визуализирует.
Неочевидно.
> ОП собирается использовать OpenGL.
Если ты вдруг соберёшься прыгать в окно, это ничего не скажет о рациональности твоего поступка.
> поскольку есть vim.
Если на то пошло, ненастраиваемое бибикающее бинарное и ненужно.
> "Женский" аргумент. См. "Двенадцать приемов литературной полемики", пункт 7.
Иначе говоря, защитить Eclipse, Qt Creator и NetBeans ты не можешь. Ок.

>>8291
> а также визуализировать результаты в реальном времени
Ты там трёхмерную карту звёздного неба проецируешь или цифорки в огромном списке гоняешь?
> но это и реализовывать будет неудобно, и жёсткий диск захлёбывается.
Естессно захлёбывается, если ты пытаешься моментально прогнать через него пару гигабайт. Померяй ему среднюю пропускную способность каким-нибудь hdparm и поймёшь сколько реально он может считать в секунду. После подгрузки основного можно догрузить про запас ещё плюс-минус сколько-то для плавности. Хотя если заказчик хочет штоббыстромнетут, требуй от них систему, на которой можно было бы при запуске заталкивать весь каталог в оперативку и в ней уже гонять. Хотя я сомневаюсь, что Оп так сделает.
> Таким образом не вижу строгой необходимости пока уходить с Билдера, если не найду чего-то объективно лучшего
Как пить дать тормоза билдера и культей упираются в I/O, но культи, если они с gcc, можно было хотя бы подточить под машинку-то если это не 486.
No. 8296    
Не могу понять, о чем вы тут трындите, наркоманы. Со старого сибилдера нужно переходить на новый. Собственно, всё.
No. 8298    
135633331419.jpg-(59.70KB, 600×750, motivationalnecromancy.jpg)
8298
>>8296
>Со старого сибилдера нужно переходить на новый.

Датс мах бой! Как говорится, похрен, что девушка не дышит, если она хорошо выглядит - можно трахать.
Борланд уже давно помер, и ембаркадера скорее всего последует его примеру.
No. 8299    
>>8298
> DOS давно помер, и Windows 7 скорее всего последует его примеру. Пишите под линупс.
Логика настоящего программиста.
No. 8300    
Под винду есть несколько С++ компиляторов:
Из часто используемых - MSVC, icc, MinGW
clang под винду пока что не очень жизнеспособен, даже транк.

По поводу 64 бит: У меня не было проблем с MSVC вообще, интел тоже работает, но с ним нужно быть аккуратнее: можно попасться на алиасинг и странные баги с -O2, если ОП знает что это такое. Правда это будет что с 32 битами, что с 64. Про мингв и 64 бита я ничего не знаю.
По поводу привязки студии к .нету - это ложь и провокации. Если тебе дотнет не нужен, то ты его просто не используешь. Если нужен, то используешь.
По поводу системы сборки у мсвц - вообще-то их есть аж 2,5 штуки, если ты не знал.
По Qt - своего компилятора там нет - там есть свой препроцессор.
No. 8301    
135634332638.jpg-(417.64KB, 1111×864, 1477892-lady_death.jpg)
8301
>>8299
>DOS давно помер, и Windows 7 скорее всего последует его примеру

Я даже не буду врать, что мне неприятно тебя расстраивать. Вот, посмотри на картинку с тетенькой раздетой.
( последняя версия винды уже 8, а она "немножко" отличается от привычных окошек )
No. 8302    
>>8300
Не ложь и не провокации. Будешь писать на винапи - полысеешь и ослепнешь.
M$ вроде бы довольно давно намикает, где он видал тех, кто не пишет под .NET.
No. 8308    
>>8302
А кто заставляет писать тебя на винапи?
Есть куча мультиплатформенных фрейморков, MFC тот же. Просто не обязательно лезть в дотнет. А если даже и лезть, то интерфейс куда проще и удобнее писать на C#, благо из дотнета дллки вызываются очень просто и безболезненно.
No. 8309    
>>8300
> вообще-то их есть аж 2,5 штуки, если ты не знал.
С этого места подробнее. Я слышал про аналог make и видел эту xml-ную непереносимую гадость, адаптированную для мышководства. Аналог CMAKE/SCONS, который бы сам находил пути к библиотекам и инструментам и которым можно было бы управлять скриптами там есть?
No. 8310    
>>8309
> аналог make
> xml-ную непереносимую гадость
ну и ещё одна версия оной

вот и 2.5 штуки, ты ж сам их знаешь.
Алсо, первая штука тоже непереносима же.
С библиотеками и прочим в любом случае под виндой придётся страдать, тут делать нечего, увы.
No. 8311    
>>8310
Среди тех жопных затычек, что я перечислил, нет ни одной системы сборки. Значит в студия так и не обзавелась этим необходимым инструментом. Окошки-то хоть красивее стали? И да, что там с c++11?
No. 8319    
>>8311
По поводу автоматического поиска библиотек под виндой - а искать-то их негде. В винде нет /usr/, /usr/local/ и прочего ведь. Как ты в таком хламе будешь искать библиотеки? Для того же cmake эти пути придётся прописывать руками.
Алсо, пара библиотек под виндой собираются мсовской nmake, я сам собирад.

По поводу С++11 - похуже, чем у clang и gcc, но они движутся вперёд. В последнем CTP появились variadic templates. Вообще, по С++11 статусу есть чудная табличка http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport
No. 8321    
>>8319
> По поводу автоматического поиска библиотек под виндой - а искать-то их негде.

Я пользовался такой маргинальщиной как waf, так тот умел находить библиотеки CUDA и Qt, узнавая полный путь к nvcc и moc (при условии, что те прописаны в PATH). Boost, конечно, приходилось руками подключать.
No. 8322    
>>8321
P.S. Ещё он умеет хитрым образом встраивать себя в студию, заменяя тамошнюю систему сборки.
No. 8324    
>>8321
CUDA при установке прописывает себя в системные переменные окружения. Qt по-моему тоже. Так что это всё не считается.

>>8322
А в студии система сборки по-моему вполне выполняет свои цели, если не нужно кросплатформенность. А если нужно, то cmake умеет генерить студийные проекты. Правда я для этого им ни разу не пользовался.
No. 8325    
>>8324
> Так что это всё не считается.
Так система сборки vs и переменные окружения-то не читает, по крайней мере по умолчанию.
No. 8334    
>>8325

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

С другой стороны, я подозреваю, что и в nix системах придется точно так же страдать, если понадобится установить несколько разных версий библиотеки и использовать разные версии в разных проектах. Точно так же придется положить собранные версии где-нибудь в home и руками тыкать билд-систему туда. Я не специалист по cmake, но беглая поиск не показывает, что в find_package можно указать версию - следовательно, надо указывать путь поиска к установленной библиотеке.
Возможно, вышеназванный пример не часто встречается в мелких проектах. Зато в так называемом "энетерпрайз" версии библиотек фиксируются и все пишется и тестируется относительно строго заданного списка. И я всеми руками за то, чтобы прямо указать нужную версию из нужной папки, вместо того, чтобы полагаться на какую-то версию, установленную в системе, которая завтра может обновиться вместе с пачкой всего остального софта в системе.

В своей практике использования visual studio, чтобы не повторять у себя на машине этот процесс настройки местоположения зависимостей много раз, я делал один раз property page с путями к библиотеками, сохранял в отдельный файл foo.props и затем подключал его ко всем необходимым конфигурациям всех нуждающихся проектов. Или даже по файлу на каждую отдельльную библиотеку и ее конфигурацию. Возможно, есть более удобный способ. Мне хватало этого.
Сборка из консоли/скриптов также возможна. devenv /build выручит отца русской демократии. Сам не использовал, но судя по логам студия вызывает то же самое.

Билд-система - штука важная в ide, конечно. Но не самая. Настройка билда пишется один раз. Потом по мере необходимости правится. В больших проектах этим, в идеале, занимается отдельный человек.
И если на настройку билда уходит время, сопостовимое на написание самого проекта - проблема не в ide. Просто выбранный инструмент используется не по назначению. И это не проблема молотка, что им очень сложно пилить.

Я же нахожу более важным в ide удобство работы с кодом, удобство отладки. И я пока что не видел ничего удобнее связки visual studio/visual assist. Более-менее интеллектуальные дополнения, быстрые преходы и поиск использования очень помогают. И, также, я не видел ничего удобнее для визуальной отладки. В студии легко настроить отображение именно того, что нужно и показывать все это вместе.
No. 8343    
>>8325
Я для своего проекта, который зависит от BOOST, MPI и ещё некоторого количества всякой математической фигни делаю зависимости в студии (2010, 2012) через переменные окружения. В смысле, укажите пжалст пути, куда вы поставили MPI, куда для бууста сделали b2 install, ну итд.
Линукс-билд собирается cmake.

> И, также, я не видел ничего удобнее для визуальной отладки. В студии легко настроить отображение именно того, что нужно и показывать все это вместе.
*this
Особенно для С++ отладка в студии лучшая. Для С тоже. Правда надо уметь этой студией пользоваться, большинство фишек отладчика на поверхности не лежат. Настройка визуализации в студии конечно менее гибкая, чем питон в gcc, но ей довольно легко пользоваться. А в 2012 эту штуку даже задокументировали и сделали xml-based конфигурацию.
No. 8344    
>>8334
>Что, в общем то, не удивительно для системы, в которой изначальный способ распространения программ - бинарники

Бинарных дистрибутивов линукса полно. Source-based - меньшинство.

>С другой стороны, я подозреваю, что и в nix системах придется точно так же страдать, если понадобится установить несколько разных версий библиотеки и использовать разные версии в разных проектах.

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

> Настройка билда пишется один раз.
Переношу я свой проект на новый компьютер или распространяю по сети...

> Я же нахожу более важным в ide удобство работы с кодом, удобство отладки. И я пока что не видел ничего удобнее связки visual studio/visual assist. Более-менее интеллектуальные дополнения, быстрые преходы и поиск использования очень помогают. И, также, я не видел ничего удобнее для визуальной отладки. В студии легко настроить отображение именно того, что нужно и показывать все это вместе.

Правильно настроенный и обмазанный плагинами vim не менее удобен (дополнение делается clang'ом, получается не хуже VAX). Отладчиком я почти не пользуюсь (тем более для CUDA он работает через раз). В целом, переход на linux был самым счастливым моментом в моей программистской жизни.
No. 8348    
>>8343
>Особенно для С++ отладка в студии лучшая. Для С тоже
Не соглашусь. В эклипсе к gdb довольно приятная морда, студя после нее кажется жутко неудобной и перегруженной.
No. 8360    
>>8301
Я ЖУТКО извиняюсь, но когда успела выйти Винда версии 8? Последний раз когда я проверял, выходила только какая-то NT 6.2

_быдлокожу в мсвц, рекомендовать ничего не буду_
No. 8361    
>>8360
October 26, 2012 согласно крези-лесбо-ресурсу под названием википедия.
No. 8362    
>>8361
Но это же и есть NT 6.2? При чем тут восьмая версия? Если считать все дробные версии, то их больше восьми наберется, а маркетинговое название... Ну это название, не больше того.
No. 8364    
>>8362
Извини, я сразу не понял, что тебя интересует не "windows 8", а восьмой по счету релиз. Крези-лесбо-непонимание~

Быть может тебе нужна nt 3.51? Она вышла в крези-лесбо-1995-м году
No. 8395    
>>8364
Меня интересует виндовс восьмой версии, упомянутый в посте, на который я сослался, когда спрашивал. Не более того.
No. 8396    
13568937425.jpg-(56.62KB, 449×603, [artyfox &amp; hotFlash] Toradora! - 08 [DVDRip 84.jpg)
8396
>>8395
>Меня интересует виндовс восьмой версии
Но ты же сам сказал, что это nt6.2 и что она тебя как раз не интересует. Я запутался.
No. 8397    
>>8396
Но там не про нт6.2, там про мифическую восьмую версию. И её малые отличия от предыдущих.
No. 8398    
>>8397
Нет, в википедии как раз про nt6.2 (ее кстати еще называют windows 8). Так что ничего мифического в ней нет, ты что-то путаешь.
No. 8399    
Морда сдулась. Я надеялся тебя на больше хватит
No. 8400    
>>8398
Для слепых - цитирую. Для тупых - обесняю.

>последняя версия винды уже 8, а она "немножко" отличается от привычных окошек
Явная импликация того что версия-то уже ОГОГО, а всё ничего не меняется. Хотя по факту между всеми мажорными версиями было достаточно много отличий, а последняя мажорная версия - 6.

Ня.
No. 8401    
>>8400
Да знаю я. Я с тобой заигрывал, а ты взъелся. Фу.
>Ня.
A в итоге-то не ня
No. 8402    
>>8400

Слушай, я дам тебе совет. Если ты не знаешь отличий версии "ядра" от версии "дистрибутива" то не пытайся умничать. Или у тебя дистрибутивы линукса все сплошняком версии 2.x или 3.х? Или может быть весь функционал какой ты используешь тебе дает исключительно "йадро"?

> а всё ничего не меняется

Меняется, только не там где нужно. Как пример: восьмерка дропнула поддержку некоторых d-linkовских железяк, а поддержка сети в ней лучше не стала. "штатными" средствами раздать через нее интернет в домашней локалке до сих пор подвиг.
Виндобыдло такое виндобыдло вобщем.
No. 8415    
>>8402
Если тебе это важно, то скажу, что твой пост я прочитал.
No. 8416    
>>8415
слив защитан
No. 8417    
>>8402
> "штатными" средствами раздать через нее интернет
Ну и кто тут быдло. Может еще про недостатки блокнота с паинтом покукарекаешь?
No. 8418    
135714216898.gif-(1.12MB, 330×248, Popcorn_02_Stephen_Colbert.gif)
8418
No. 8422    
>>8417
Блокнот вообще-то самая пиздатая программа в поставке (вероятно ее сам бил гейтс писал кровью христианских младенцев-девственниц). А вот паинт действительно говно. Там интерфейс не как в фотошопе и слоев нет.
No. 8423    
>>8422
Пайнт в виндовс 7 стал ня и каваии. В нем появилась возможность обрезать по выделению!
No. 8431    
>>8422
> Блокнот вообще-то самая пиздатая программа в поставке (вероятно ее сам бил гейтс писал кровью христианских младенцев-девственниц).
Ты им хоть пользовался? Он же тупо половину файлов не может нормально открыть. То не распознает переводы строк и весь текст в кашу, то не распознает юникод и каждая буква через пробел. Не может в кодировки, в результате любуешься мусором вместо текста. Паинт по сравнению с таким хламом - слепящее совершенство.
No. 8433    
135730539471.jpg-(407.83KB, 1920×1200, 1311747338112.jpg)
8433
Удалить сообщение []
Пароль  
[Mod]