Gingercat

Также ковырял в свое время Xamarin, но так и не понял - на кой черт мне писать на шарпе, если по сути пишешь на яве - проще тогда сразу яву использовать. А про Qt - как только дело доходит до чего либо более серьезного, чем окошки с кнопками, начинаются костыли. Опять же - лично мое, сугубо субъективное мнение, основанное на уровне, достаточном для написания нескольких графических фильтров - возможно и не прав. А вот что совсем опечалило - поддержка CSS. По сути, это чертовски удобно, для тех, кто знает CSS. Ага, щас - CSS  то обрезанный по самое немогу - на кой черт заявлять про поддержку).
 
А вот цена для Rad Studio - да, кусючая. Чего бы не говорили, мол "если проект не принесет нескольких десятков тыщ уе, то на кой он нужен", для рядового пользователя, который пытается чего то сделать - неподъемно.

Доброго времени суток. Навеяно постом SergeIT.
Несмотря на кучу недостатков, по большей части связанных именно с с++ (удобство работы в студии, отсутствие нормального дополнения и тд), на данный момент абракадабра вне конкуренции по скорости и простоте работы. Не могу сказать про кроссплатформенность, а вот разработка под десктоп - да. Безусловно, C# под десктоп здорово, но когда критична скорость обработки - сами понимаете. Так уж сложилось, что я привязан к различным видам обработки графики. Так вот - чего бы там не говорили про оптимизацию кода (лишние вызовы в ассемблере и тд), на данный момент из коробки, быстрее всего Rad Studio. Конечно, мне далеко даже до среднего уровня с++, но все же. 
 
Работа в Visual Studio с битмапами еще тот геморой (одно заполнение структуры bitmap))) При использовании нативных! BitBlt, Dib-секций и еще множества различных способов, скорость обработки ниже, чем при использовании обертки TBitmap. Полный разбор fullHd картинки  в Visual Studio занимает от 7 до 14 мс, при этом в студии 3 - 6. Проверенно тоннами тестов.
 
Конечно, можно сказать - OpenCv. Да, пока вы решаете стандартные задачи по обработке. Как только шаг в сторону - начинаешь понимать, что проще самому писать, нежели пользоваться готовым.
 
Ну и про Qt. Очень удобно - чтобы не говорили. Но есть несколько но: 1 - хвост библиотек (статичная сборка возможна, но там далеко не все гладко). 2 - жесточайшее навязывание своих стандартов - это уже не с а сQt. Не знаю, как дела с кроссплатформенностью - не пробовал. По скорости на посередине. При этом, использование нативных функций винды (именно без костылей) карается (понятно, кроссплатформенность). Однако, либо пользоваться bitmapom нативным (тогда какой смысл вообще в Qt, если все нужно выписывать ручками), либо... bitBlt не возможен (как и множество другого) - вырезали, остается использование довольно медленного QImage, с кучей оговорок.
 
В Rad Studio - пожалуйте: нужно - дернул из GDI функцию, нужно - из среды, нужен кусок ассемблера - пожалуйста. Про ассемблер в Qt умолчу)))
 
Вот и выходит, что Rad Studio на данный момент, по сути лучшая. Прошу не судить строго (далеко не профессионал в плюсах), но опыт кой какой имеется. Так что пущай развиваются))

Доброго времени суток. Навеяно постом SergeIT.
Несмотря на кучу недостатков, по большей части связанных именно с с++ (удобство работы в студии, отсутствие нормального дополнения и тд), на данный момент абракадабра вне конкуренции по скорости и простоте работы. Не могу сказать про кроссплатформенность, а вот разработка под десктоп - да. Безусловно, C# под десктоп здорово, но когда критична скорость обработки - сами понимаете. Так уж сложилось, что я привязан к различным видам обработки графики. Так вот - чего бы там не говорили про оптимизацию кода (лишние вызовы в ассемблере и тд), на данный момент из коробки, быстрее всего Rad Studio. Конечно, мне далеко даже до среднего уровня с++, но все же. 
 
Работа в Visual Studio с битмапами еще тот геморой (одно заполнение структуры bitmap))) При использовании нативных! BitBlt, Dib-секций и еще множества различных способов, скорость обработки ниже, чем при использовании обертки TBitmap. Полный разбор fullHd картинки  в Visual Studio занимает от 7 до 14 мс, при этом в студии 3 - 6. Проверенно тоннами тестов.
 
Конечно, можно сказать - OpenCv. Да, пока вы решаете стандартные задачи по обработке. Как только шаг в сторону - начинаешь понимать, что проще самому писать, нежели пользоваться готовым.
 
Ну и про Qt. Очень удобно - чтобы не говорили. Но есть несколько но: 1 - хвост библиотек (статичная сборка возможна, но там далеко не все гладко). 2 - жесточайшее навязывание своих стандартов - это уже не с а сQt. Не знаю, как дела с кроссплатформенностью - не пробовал. По скорости на посередине. При этом, использование нативных функций винды (именно без костылей) карается (понятно, кроссплатформенность). Однако, либо пользоваться bitmapom нативным (тогда какой смысл вообще в Qt, если все нужно выписывать ручками), либо... bitBlt не возможен (как и множество другого) - вырезали, остается использование довольно медленного QImage, с кучей оговорок.
 
В Rad Studio - пожалуйте: нужно - дернул из GDI функцию, нужно - из среды, нужен кусок ассемблера - пожалуйста. Про ассемблер в Qt умолчу)))
 
Вот и выходит, что Rad Studio на данный момент, по сути лучшая. Прошу не судить строго (далеко не профессионал в плюсах), но опыт кой какой имеется. Так что пущай развиваются))

Также ковырял в свое время Xamarin, но так и не понял - на кой черт мне писать на шарпе, если по сути пишешь на яве - проще тогда сразу яву использовать. А про Qt - как только дело доходит до чего либо более серьезного, чем окошки с кнопками, начинаются костыли. Опять же - лично мое, сугубо субъективное мнение, основанное на уровне, достаточном для написания нескольких графических фильтров - возможно и не прав. А вот что совсем опечалило - поддержка CSS. По сути, это чертовски удобно, для тех, кто знает CSS. Ага, щас - CSS  то обрезанный по самое немогу - на кой черт заявлять про поддержку).
 
А вот цена для Rad Studio - да, кусючая. Чего бы не говорили, мол "если проект не принесет нескольких десятков тыщ уе, то на кой он нужен", для рядового пользователя, который пытается чего то сделать - неподъемно.

Вы меня простите, Господа. Но позвольте высказать мнение человека нового в Object Pascal, из .NET пришедшего.
Тьфу-тьфу, дай им всем Бог в Embarcadero доброго здоровья и процветания. Оглянитесь вокруг, ничего ж и близкого нет, даже отдаленно напоминающего того, к чему пришли в Embarcadero за последние годы с кроссплатформенностью! Уму не постижимо.
Взять Java (хоть к теме напрямую не относится) - на Android идет сырец-порт JavaFX, сервисы и плюшки - за деньги в частном порядке.
Xamarin видели? Хотите поднять настроение - погуглите. Выглядит это так: MAMA MILA RAMU... С# по Java (что-то дико нелепое). Если человек знает что такое Activity, зачем ему C#? Или Java менее элегантней (учитывая полное родство). MONO - мычание из преисподней, GUI нет фактически. Да вот возьмите хотя бы Unity 3D. Как-то на конференции человек оттуда проговорился: Вы ведь не знаете - мы 90% времени правим баги платформозависимые, чтобы у Вас почти все работало. У Microsoft судороги предсмертные в части всего, что не Windows 10. Почитать куда их бросает каждый месяц - жуть. Кто-то испрашивал по поводу поддержки Windows Phone в одном из топиков. Да даже если бы технически это было возможно, то они ж меняют API каждые полгода на него: то Windows Phone Silverlight, то HTML5, то DirectX C++ (взамен XNA Windows Phone 7)... Поддержка разработчиков ушла в StackOverflow, MSDN скоро рекламу начнет размещать о таблетках для мужчин.
Ну, кто еще остался?
Qt? Это не моя тема. Мне трудно думать про указатели, когда надо думать про логику. Увы, не дано... Не владею темой.
Так что пока нас не слишком много в сравнении с Китаем, есть шанс, что быстро ответят на заданный вопрос... Скоро эта халява закончится...

на qt есть qml javascript подобный и на нем писать можно приложения. 
хамарин ставил но уперся в то что он платный и написать для пробы что то для андроида нельзя.
 
да абракадабра которая уже не абракадабра нравится и мне. мне не нравится что такую среду не плохую все время перепродают то туда то сюда и не известно что будет завтра. выйдет ли новая версия или закопают и всех разгонят. плюс упор на ентерпрайз и цены. 

Доброго времени суток. Навеяно постом SergeIT.
Несмотря на кучу недостатков, по большей части связанных именно с с++ (удобство работы в студии, отсутствие нормального дополнения и тд), на данный момент абракадабра вне конкуренции по скорости и простоте работы. Не могу сказать про кроссплатформенность, а вот разработка под десктоп - да. Безусловно, C# под десктоп здорово, но когда критична скорость обработки - сами понимаете. Так уж сложилось, что я привязан к различным видам обработки графики. Так вот - чего бы там не говорили про оптимизацию кода (лишние вызовы в ассемблере и тд), на данный момент из коробки, быстрее всего Rad Studio. Конечно, мне далеко даже до среднего уровня с++, но все же. 
 
Работа в Visual Studio с битмапами еще тот геморой (одно заполнение структуры bitmap))) При использовании нативных! BitBlt, Dib-секций и еще множества различных способов, скорость обработки ниже, чем при использовании обертки TBitmap. Полный разбор fullHd картинки  в Visual Studio занимает от 7 до 14 мс, при этом в студии 3 - 6. Проверенно тоннами тестов.
 
Конечно, можно сказать - OpenCv. Да, пока вы решаете стандартные задачи по обработке. Как только шаг в сторону - начинаешь понимать, что проще самому писать, нежели пользоваться готовым.
 
Ну и про Qt. Очень удобно - чтобы не говорили. Но есть несколько но: 1 - хвост библиотек (статичная сборка возможна, но там далеко не все гладко). 2 - жесточайшее навязывание своих стандартов - это уже не с а сQt. Не знаю, как дела с кроссплатформенностью - не пробовал. По скорости на посередине. При этом, использование нативных функций винды (именно без костылей) карается (понятно, кроссплатформенность). Однако, либо пользоваться bitmapom нативным (тогда какой смысл вообще в Qt, если все нужно выписывать ручками), либо... bitBlt не возможен (как и множество другого) - вырезали, остается использование довольно медленного QImage, с кучей оговорок.
 
В Rad Studio - пожалуйте: нужно - дернул из GDI функцию, нужно - из среды, нужен кусок ассемблера - пожалуйста. Про ассемблер в Qt умолчу)))
 
Вот и выходит, что Rad Studio на данный момент, по сути лучшая. Прошу не судить строго (далеко не профессионал в плюсах), но опыт кой какой имеется. Так что пущай развиваются))

Доброго времени суток. Навеяно постом SergeIT.
Несмотря на кучу недостатков, по большей части связанных именно с с++ (удобство работы в студии, отсутствие нормального дополнения и тд), на данный момент абракадабра вне конкуренции по скорости и простоте работы. Не могу сказать про кроссплатформенность, а вот разработка под десктоп - да. Безусловно, C# под десктоп здорово, но когда критична скорость обработки - сами понимаете. Так уж сложилось, что я привязан к различным видам обработки графики. Так вот - чего бы там не говорили про оптимизацию кода (лишние вызовы в ассемблере и тд), на данный момент из коробки, быстрее всего Rad Studio. Конечно, мне далеко даже до среднего уровня с++, но все же. 
 
Работа в Visual Studio с битмапами еще тот геморой (одно заполнение структуры bitmap))) При использовании нативных! BitBlt, Dib-секций и еще множества различных способов, скорость обработки ниже, чем при использовании обертки TBitmap. Полный разбор fullHd картинки  в Visual Studio занимает от 7 до 14 мс, при этом в студии 3 - 6. Проверенно тоннами тестов.
 
Конечно, можно сказать - OpenCv. Да, пока вы решаете стандартные задачи по обработке. Как только шаг в сторону - начинаешь понимать, что проще самому писать, нежели пользоваться готовым.
 
Ну и про Qt. Очень удобно - чтобы не говорили. Но есть несколько но: 1 - хвост библиотек (статичная сборка возможна, но там далеко не все гладко). 2 - жесточайшее навязывание своих стандартов - это уже не с а сQt. Не знаю, как дела с кроссплатформенностью - не пробовал. По скорости на посередине. При этом, использование нативных функций винды (именно без костылей) карается (понятно, кроссплатформенность). Однако, либо пользоваться bitmapom нативным (тогда какой смысл вообще в Qt, если все нужно выписывать ручками), либо... bitBlt не возможен (как и множество другого) - вырезали, остается использование довольно медленного QImage, с кучей оговорок.
 
В Rad Studio - пожалуйте: нужно - дернул из GDI функцию, нужно - из среды, нужен кусок ассемблера - пожалуйста. Про ассемблер в Qt умолчу)))
 
Вот и выходит, что Rad Studio на данный момент, по сути лучшая. Прошу не судить строго (далеко не профессионал в плюсах), но опыт кой какой имеется. Так что пущай развиваются))

Доброго времени суток. Навеяно постом SergeIT.
Несмотря на кучу недостатков, по большей части связанных именно с с++ (удобство работы в студии, отсутствие нормального дополнения и тд), на данный момент абракадабра вне конкуренции по скорости и простоте работы. Не могу сказать про кроссплатформенность, а вот разработка под десктоп - да. Безусловно, C# под десктоп здорово, но когда критична скорость обработки - сами понимаете. Так уж сложилось, что я привязан к различным видам обработки графики. Так вот - чего бы там не говорили про оптимизацию кода (лишние вызовы в ассемблере и тд), на данный момент из коробки, быстрее всего Rad Studio. Конечно, мне далеко даже до среднего уровня с++, но все же. 
 
Работа в Visual Studio с битмапами еще тот геморой (одно заполнение структуры bitmap))) При использовании нативных! BitBlt, Dib-секций и еще множества различных способов, скорость обработки ниже, чем при использовании обертки TBitmap. Полный разбор fullHd картинки  в Visual Studio занимает от 7 до 14 мс, при этом в студии 3 - 6. Проверенно тоннами тестов.
 
Конечно, можно сказать - OpenCv. Да, пока вы решаете стандартные задачи по обработке. Как только шаг в сторону - начинаешь понимать, что проще самому писать, нежели пользоваться готовым.
 
Ну и про Qt. Очень удобно - чтобы не говорили. Но есть несколько но: 1 - хвост библиотек (статичная сборка возможна, но там далеко не все гладко). 2 - жесточайшее навязывание своих стандартов - это уже не с а сQt. Не знаю, как дела с кроссплатформенностью - не пробовал. По скорости на посередине. При этом, использование нативных функций винды (именно без костылей) карается (понятно, кроссплатформенность). Однако, либо пользоваться bitmapom нативным (тогда какой смысл вообще в Qt, если все нужно выписывать ручками), либо... bitBlt не возможен (как и множество другого) - вырезали, остается использование довольно медленного QImage, с кучей оговорок.
 
В Rad Studio - пожалуйте: нужно - дернул из GDI функцию, нужно - из среды, нужен кусок ассемблера - пожалуйста. Про ассемблер в Qt умолчу)))
 
Вот и выходит, что Rad Studio на данный момент, по сути лучшая. Прошу не судить строго (далеко не профессионал в плюсах), но опыт кой какой имеется. Так что пущай развиваются))

Для Вашей задачи подойдет indy ftp клиент-сервер плюс к ним indy ssl handlerы. Нужно будет найти "OpenSSL-Win32" и разобраться как в ней создавать собственные сертификаты. Далее указать в handler серверу и клиенту в SSLOptions файлы сертификатов и ключей и все, vulgaris защищенное ftp соединение. При создании сертификатов указывается время действия вплоть до секунд. Можно выдавать его на месяц к примеру, через месяц точно по времени ssl соединения не будет и клиент будет стучаться за новым сертификатом, ну или не будет...

Сделать общение с сервером по SSL и выдавать сертификаты ограниченные по времени к примеру раз в год, так проще и с этим сделать ничего не смогут.
Проще будет ломать бинарный код и анализировать память приложения. Бинарники тоже шифруют или жмут, от школьников помогает. 
Как вариант Sentinel Hasp, или Hasp Net ключи, я на винде использовал, и 1с такими закрывается.

Не за что - у меня работало, надеюсь и вас заработает)))

Не за что - у меня работало, надеюсь и вас заработает)))

#pragma hdrstop #pragma argsused #include <conio.h> #include <iostream> using namespace std; int _tmain(int argc, _TCHAR* argv[]) { int i = 0; int n = 0; float s = 0; float x[100]; cout << "enter the size of array - " ; cin >>n; cout << "size = " << n << endl; for(i = 1; i <= n; i++) { cout << "x<" << i << "> - "; cin >> x[i]; s = s + x[i]; x[i] = s / i; } cout << "\n--- result ---\n" << endl; cout.setf(std::ios::fixed); cout.precision(3); // три знака после запятой, ибо WriteLn('|', x[i]:5:2, '|'); не совсем понимаю for(i = 1; i <= n; i++) { cout << "x<" << i << "> = "<< x[i] << endl; } getch(); return 0; } Доброго дня. Это не в коем случае не "идеальный" код, а просто перевод вашего, да и с консолью не совсем дружу))) Если нужно - оберну в проверку исключений, но сам почти никогда не пользуюсь - лучше лишний раз проверить данные при вводе, и сказать пытливому юзверю про ошибку, чем генерировать исключения))
 
Здесь без проверок, ибо у вас их также нет.

#pragma hdrstop #pragma argsused #include <conio.h> #include <iostream> using namespace std; int _tmain(int argc, _TCHAR* argv[]) { int i = 0; int n = 0; float s = 0; float x[100]; cout << "enter the size of array - " ; cin >>n; cout << "size = " << n << endl; for(i = 1; i <= n; i++) { cout << "x<" << i << "> - "; cin >> x[i]; s = s + x[i]; x[i] = s / i; } cout << "\n--- result ---\n" << endl; cout.setf(std::ios::fixed); cout.precision(3); // три знака после запятой, ибо WriteLn('|', x[i]:5:2, '|'); не совсем понимаю for(i = 1; i <= n; i++) { cout << "x<" << i << "> = "<< x[i] << endl; } getch(); return 0; } Доброго дня. Это не в коем случае не "идеальный" код, а просто перевод вашего, да и с консолью не совсем дружу))) Если нужно - оберну в проверку исключений, но сам почти никогда не пользуюсь - лучше лишний раз проверить данные при вводе, и сказать пытливому юзверю про ошибку, чем генерировать исключения))
 
Здесь без проверок, ибо у вас их также нет.

Если я правильно понял, то на рабочем столе еще появляется не сворачиваемая отрисовка вашей формы, которая очень напрягает память и скорость работы самой среды, такая фигня в XE8, избавляюсь от неё следующим образом:
Открыть Delphi, перед открытием вашего проекта создать новый проект MultiDeviceProject, зайти в меню View -> Multi-Device Preview -> в нем кнопочка Select Views to Preview (hint) отключить все превьюхи и закрыть проект не сохраняя, открыть ваш проект и все ок. 
После перезапуска повторяю данные телодвижения, хз как сохранить.

Доброго дня. Совсем позабыл про существование данного топика, а ведь нужен - дабы видели люди, что другие люди иногда творят.
 
Собственно - Kitchen calculator: конвертер величин и температур; таблица калорий; пересчет температур, и простенький таймер.
 
Ссылка - Kitchen calculator
 
Написан на с++ в Appmethod.

Хм - видимо нужно прекращать разговор - я не пойму чего вы хотите. Волшебной кнопки - написать программу не существует. С чего вы взяли, что VS неудобная? С чего взяли,            что большинство программ написаны  В, ЕЩЕ РАЗ ПОДЧЕРКНУ - В, а не на (НА языке пишут В среде разработки) - кто вам выдал, под страхом смерти, такую секретную информацию)))) Писать можно и в нотепаде - это лишь вопрос удобства и не более.
 
Большинство программ пишутся на плюсах и си (хотя, как я подозреваю, понятие - программа - у нас разные), и поверьте - далеко не в VS (есть более достойные и бесплатные кандидаты).

Так исправить С++ мне кажется можно простым путем. Надо чтобы Embarcadero написало реально ОДНО приложение на С++ Builder и чтобы строк в нем было не менее 500. Почему 500, потому, что например С++ Builder XE7 просто начинал вываливаться после такого кол-ва строк.
Нету, как я понимаю, сейчас в природе приложения для Андроида написанного на С++ Builder. Вот отсюда и проблемы. Если бы Embarcadero написало реально ОДНО приложение, увидев проблемы которые есть на поверхности, то это было реанимировало С++ среду.

Update 1 ничем не помог пациенту под названием С++ Builder.
Проект полностью рабочий в С++ Builder XE7 полностью становиться не рабочим в XE8.
1. Пропали надписи на кнопках. Однако в инспекторе объектов у этих двух кнопках надписи есть. На дополнительной форме тоже пропали все надписи на кнопках. Баг.
2. Запускаем проект. Пропало содержимое ListView1! Поворачиваю устройство на 90 градусов и данные в ListView1 появляются. В С++ Builder XE7 проблем нет. Баг ХЕ8.
3. Идем дальше. Перезапускаем проект. После запуска начинаю поворачивать устройство назад вперед на 90 градусов. После каждого поворота форма постепенно вытягивается и в конечном итоге вылазит за экран. В С++ Builder XE7 форма просто при поворотах логично упирается в края экрана, а не медленно нарастает. Баг ХЕ8. Не работают привязки.
4. Перезапускаем проект. Поворачиваем устройство чтобы появились данные в ListView1 (баг из пункта 2). Нажимаем на ListView1. Появляется форма. Пропал тулбар с кнопками на этой форме. Чтобы его увидеть, надо снова крутануть устройство. Баг.
5. Идем в IDE. Щелкаем в инспекторе объектов двойным щелчком на названии события формы FormShow. Студия начинает кричать, что событие не определено, хотя в коде событие есть и нормально работает в предыдущей версии RAD XE7. IDE не видит своего события! Студия не видит половину своих событий в инспекторе объектов. Работать становиться просто не возможно. Баг IDE.
 
Пока кто нибудь из разработчик embarcadero не напишет самостоятельно проект хоты бы на строк 500 в С++ Builder XE8, то столкнувшись со всеми проблемами, возможно удаться embarcadero реанимировать С++ Builder.
Сейчас С++ Builder XE8 Up1 не является средой для разработки под Андроид.

Обидно другое. Я ничего не имею против новых багов в новой версии. Не понятно, почему все что работало на предыдйщей версии просто умирает в новой версии.
Тогда начинаешь надеяться на апдейты как на манну небесную, а на выходе кукиш с маслом...

По счастью или нет, также пользуюсь плюсами. Полностью подтверждаю - это что-то, с чем-то. Свои баги перечислять не буду - подолбавшись плюнул, но вот беда с привязкой, а также с FormShow - идентична. А еще в 8-ке ругнулось на отсутствие Androidapi.JNI.GraphicsContentViewText честно говоря, и разбираться не стал.

Перефразирую Ярослава: "Все контролы, которые вы кидаете в TCustomScrollBox находятся в дополнительном промежуточном контроле TScrollContent."
 
т.е. Padding для VerticalScrollBox можно задать так:
VertScrollBox1.Content.Padding.Top := 5;

Попробуйте так myNotification->AlertBody =L"Привет!";

Unsigned в данном случае означает, что пакет не подписан. Т.е. без подписи KeyStore.