Ну примерно это я и ожидал услышать. Имхо, это настоящий ад)
Вычитав первое предложение этой статьи, я рассчитывал увидеть как подружить Qt Creator + gradle + Java (о которой возможности было заявлено разработчиками)…
Суть моей проблемы в том, что мне приходится использовать ту же Android Studio. IDE которую используют Android-разработчики, клиенты моей библиотеки. И в этом проекте используется gradle. А так же Google Maps SDK — где я переопределяю тайловый провайдер и заполняю его нативной начинкой. Т.е. локальный рендеринг карты. Да сценарий не самый лучший, но не я его инициатор.
Саму библиотеку я разрабатываю под Qt Creator'ом — удобно, если привыкнуть (тот же alt+enter под Windows). И с отладкой в нем проблем нет, если на выходе приложение, а не .so модуль (std::vector вполне читаем).
В итоге получается что на данный момент есть плавающий баг, который повторяется только Java-приложении с .so библиотекой. И разобраться в чем именно проблема не получается.
Вообщем попробую Eclipse. Спасибо, за комментарий.
Позволяет избежать неприятных моментов несоответствия версий нативного и клиентского кода.
Дополнительное удобство в обработке исключений, стоит нам дописать к методу " throw(std::exception)".
Плюс — подготовленные шаблоны для vector, wstring.
И самое главное он очень гибкий инструмент и не только под Java.
Имхо, незаменимый инструмент для кросс-платформенной разработки на основе C/C++.
Так же, если больших картинок много, можно хранить нарезку на сервере и подгружать их в нескольких потоках. Получится TMS-сервис :)
И так же иногда возникает потребность не в JPEG изображениях, а PNG — в виду прозрачности и возможности наложения. Имею ввиду, что в задаче с наложением картинок без сетки не обойтись.
Была задача положить на карту — JPEG изображение размером с 500 метров. Проблема была в том что картинку приходила от пользователя, и нельзя было ее подготовить заранее. Пришлось использовать похожий способ, при помощи GDI+ и MsImg. Затея оказалась неудачной — так как GDI+ умеет работать только в основном потоке. И пользователю приходилось ждать (пусть не долго).
То есть у тайловой сетки простое преимущество — кеширование результата.
Это просто сумасшествие какое-то :)
Наконец-то вывод компилятора можно будет нормально прочесть прямо из консоли.
Может PowerCmd больше не понадобиться даже :)
Решил сам посмотреть, да начальнику показать, только вот в 3 трех демках повылетали ошибки, а одна даже «по-сишнему» упала. А меня очень заинтересовал картографический контрол. Довольно плавно рендерит и получается очень даже симпатично. Аж завидно :)
Но ведь в случае с наследованием — можно обозначить класс __declspec(dllexport) атрибутом, а затем отнаследоваться от него.
Я не спорю, что есть свои ограничения и в таком случае. И в итоге безопасный и главное стабильный P/Invoke совсем не удобен. Написание связующего кода конечно муторно, но не так уж долго.
Но честно говоря проблем с наследованием у меня действительно нет, единственное не удобно конкретизировать класс в шарпной среде.
А так я честно стремился писать костыли на предназначенном для этого CLI, но как то не срослось :) Информации о нем мне показалось мало, и далеко не все получилось… Если посоветуете про CLI книгу или полезную статью буду очень признателен)
В итоге я сейчас просто экспортирую структуру с статическими методами, которые ничего не возвращают и отдают только через указатели. Зато теперь при изменении параметров — меняется и наименование точки входа; в отличии от простых сишных функций.
То есть есть класс ILayer с потомком VectorLayer, то я пишу соответствующее структуры ILayerExport, VectorLayerExport — запечатанные в cpp'шках. Вроде действительно этого хватает.
C++/CLI — не язык, а костыль. На нём не программируют, на нём лепят костыли. :)
C++/CLI — я и не называл языком. И честно говоря совершенно не понимаю зачем нужна подобная «вещь».
Написал на нем одну обертку и понял что обычный P/Invoke проще и удобнее.
Вам 10 000 строк, вообще говоря, для чего?
Это был просто пример, может быть не совсем удачный. Я просто вспомнил случай в жизни когда данных стало резко больше и стандартные контролы стали нещадно тупить. А мысль была что не стандартные вещи делаются тяжело на любом языке.
Если гуй сбоку, то выбор WPF или Qt вообще не стоит, потому что в большинстве случаев удобнее не смешивать разные технологии.
Не знаю как вам, но я лично не понимаю при чем тут язык. Я довольно неплохо владею тем же C#, хорошо знаю платформу .NET… И хорошо знаю проблемы с «умным» сборщиком мусора, который очищает память, когда ему удобнее, а не тогда когда удобно вам. А теперь представим себе задачи по обработке изображения, например с ограничением по памяти, и конечно не забываем про скорость отклика. Вспомним про стандартные тормознутые контролы .NET, такие как DataGridView. Конечно есть альтернатива как контролы DevExpress, которые нормально обработают 10 тысяч строк и не захлебнуться. Конечно можно подумать, что дело в неправильном проектировании самого приложения и не нужно отображать столько строк за раз — но, задумайтесь, не ограничения ли это самой среды? Вам остается либо смириться с этим и что лучше так просто не делать, либо попытаться написать свой контрол… И сложность последнего уже не в языке, хоть вы его будете писать на C#, хоть на C++.
А теперь я скажу чем мне именно нравиться Qt — его гибкостью. На Qt писать GUI так же быстро (если хорошо его знать), как и на C# .NET. Да и WPF — со своими приколами, единственное это порог вхождения.
Напомню что язык должен выбираться от типа и сложности задачи, и не всегда от личных предпочтений. Вспомним что Qt — это не только GUI, и что есть, например, портирование на Python — PyQt.
Так же в защиту всемогущего языка C++, самого гибкого языка. И когда вам будет нужна такая гибкость, окажется что и выбора то и нет. И в приложении, где в центре не GUI и готовые решения, а уникальный алгоритм или производительность — то Qt для пользовательской красивой мордашки вам в помощь.
Я не в коем случае не навязываю, я просто расширяю угол обзора. А такие вещи как C++/CLI или новомодный C++/CX, со своими тонкостями и проблемами — это близко, но не то.
Такого моего субъективное мнение — Qt среди остального C++ мира пожалуй самый «милый» :)
Вычитав первое предложение этой статьи, я рассчитывал увидеть как подружить Qt Creator + gradle + Java (о которой возможности было заявлено разработчиками)…
Суть моей проблемы в том, что мне приходится использовать ту же Android Studio. IDE которую используют Android-разработчики, клиенты моей библиотеки. И в этом проекте используется gradle. А так же Google Maps SDK — где я переопределяю тайловый провайдер и заполняю его нативной начинкой. Т.е. локальный рендеринг карты. Да сценарий не самый лучший, но не я его инициатор.
Саму библиотеку я разрабатываю под Qt Creator'ом — удобно, если привыкнуть (тот же alt+enter под Windows). И с отладкой в нем проблем нет, если на выходе приложение, а не .so модуль (std::vector вполне читаем).
В итоге получается что на данный момент есть плавающий баг, который повторяется только Java-приложении с .so библиотекой. И разобраться в чем именно проблема не получается.
Вообщем попробую Eclipse. Спасибо, за комментарий.
Эти сценарии мне не очень-то помогли:
github.com/mapbox/mapbox-gl-native/wiki/Android-debugging-with-remote-GDB
geekswithblogs.net/raccoon_tim/archive/2011/09/12/working-with-android-on-windows-and-without-cygwin.aspx
comments.gmane.org/gmane.comp.lib.qt.android/3462
Видимо руки кривые… :(
А вы пробовали SWIG?
Позволяет избежать неприятных моментов несоответствия версий нативного и клиентского кода.
Дополнительное удобство в обработке исключений, стоит нам дописать к методу " throw(std::exception)".
Плюс — подготовленные шаблоны для vector, wstring.
И самое главное он очень гибкий инструмент и не только под Java.
Имхо, незаменимый инструмент для кросс-платформенной разработки на основе C/C++.
И так же иногда возникает потребность не в JPEG изображениях, а PNG — в виду прозрачности и возможности наложения. Имею ввиду, что в задаче с наложением картинок без сетки не обойтись.
Была задача положить на карту — JPEG изображение размером с 500 метров. Проблема была в том что картинку приходила от пользователя, и нельзя было ее подготовить заранее. Пришлось использовать похожий способ, при помощи GDI+ и MsImg. Затея оказалась неудачной — так как GDI+ умеет работать только в основном потоке. И пользователю приходилось ждать (пусть не долго).
То есть у тайловой сетки простое преимущество — кеширование результата.
Наконец-то вывод компилятора можно будет нормально прочесть прямо из консоли.
Может PowerCmd больше не понадобиться даже :)
__declspec(dllexport)атрибутом, а затем отнаследоваться от него.Я не спорю, что есть свои ограничения и в таком случае. И в итоге безопасный и главное стабильный P/Invoke совсем не удобен. Написание связующего кода конечно муторно, но не так уж долго.
Но честно говоря проблем с наследованием у меня действительно нет, единственное не удобно конкретизировать класс в шарпной среде.
А так я честно стремился писать костыли на предназначенном для этого CLI, но как то не срослось :) Информации о нем мне показалось мало, и далеко не все получилось… Если посоветуете про CLI книгу или полезную статью буду очень признателен)
В итоге я сейчас просто экспортирую структуру с статическими методами, которые ничего не возвращают и отдают только через указатели. Зато теперь при изменении параметров — меняется и наименование точки входа; в отличии от простых сишных функций.
То есть есть класс ILayer с потомком VectorLayer, то я пишу соответствующее структуры ILayerExport, VectorLayerExport — запечатанные в cpp'шках. Вроде действительно этого хватает.
А так, например GDAL использует SWIG.
C++/CLI — я и не называл языком. И честно говоря совершенно не понимаю зачем нужна подобная «вещь».
Написал на нем одну обертку и понял что обычный P/Invoke проще и удобнее.
Это был просто пример, может быть не совсем удачный. Я просто вспомнил случай в жизни когда данных стало резко больше и стандартные контролы стали нещадно тупить. А мысль была что не стандартные вещи делаются тяжело на любом языке.
Согласен.
А теперь я скажу чем мне именно нравиться Qt — его гибкостью. На Qt писать GUI так же быстро (если хорошо его знать), как и на C# .NET. Да и WPF — со своими приколами, единственное это порог вхождения.
Напомню что язык должен выбираться от типа и сложности задачи, и не всегда от личных предпочтений. Вспомним что Qt — это не только GUI, и что есть, например, портирование на Python — PyQt.
Так же в защиту всемогущего языка C++, самого гибкого языка. И когда вам будет нужна такая гибкость, окажется что и выбора то и нет. И в приложении, где в центре не GUI и готовые решения, а уникальный алгоритм или производительность — то Qt для пользовательской красивой мордашки вам в помощь.
Я не в коем случае не навязываю, я просто расширяю угол обзора. А такие вещи как C++/CLI или новомодный C++/CX, со своими тонкостями и проблемами — это близко, но не то.
Такого моего субъективное мнение — Qt среди остального C++ мира пожалуй самый «милый» :)