Станислав Макаров

Oxoron ну что тут сказать навскидку...
Я всегда считал .net допиленной java-платформой. Не то, чтобы в дотнете прям нереальные невероятные новшества, но все же некоторые вещи были обдуманы еще раз. Например, очень важным считаю разделение на reference и value типы. Правда, ИМХО, MS не довела идею до победного конца (слишком много технических вопросов нужно учитывать при выборе struct vs class), но все равно шаг очень правильный.
Плюс, считаю важным отсутствие корреляции между логическим структурированием библиотек (по неймспейсам) и физическим (по сборкам). На каждом уровне должны приниматься отдельные решения насчет того, что куда класть.
Еще одним преимуществом (нивелированным на данный момент) была изначальная ориентация .net на мультиязычную поддержку. Сейчас конечно JVM-языков навалом, но раньше это все-таки смотрелось киллер-фичей .net. Особенно поддержка "склеивающих" языков, таких как C++/CLI, которые позволяли интегрировать уже существующие компоненты с .net-приложениями. Дотнет изначально не был платформой в себе, разработчикам давали массу инструментов для интеграцией с COM и native-кодом. Ну и само собой managed-языки в приличном количестве, вон F# уже довольно давно подтянулся как официально (!!) поддерживаемый.

А вообще конечно изначальным преимуществом .net были именно языки. Я думаю даже самые ярые джависты со мной согласятся, что с момента выпуска C#, язык Java развивается догоняющим образом. Можно опять сказать, что есть Scala, но тогда нужно учесть, что C# изначально был визитной карточкой платформы с момента ее появления. Ну и самое главное - инструменты. В мире Java достаточно хороших IDE, но уровень взаимоподдержки Студии и .net насколько мне известно пока не достигнут.

И тут мы выходим на стандартное основное преимущество решений от MS - максимальная "готовность" и интеграция продуктов. К сожалению последние года 3 в Джаву не совался, но знакомые не раз говорили, что с отсутствием знаний об обеих платформах им гораздо легче было поднять hello-world веб-сайт (!) на asp.net в студии, нежели на том же Spring. Так или иначе, это фактор.

Теперь библиотеки. Конечно, в мире джава их огромное количество. Я думаю и сегодня их значительно больше, чем в дотнет. Две либы в моем текущем проекте - NHibernate и NetTopologySuite - это порты с джавовских либ. Джава рулит на сервере. Про..аная Майкрософтом настоящая кроссплатформенность .net не давала ему потеснить джаву. Сейчас конечно это усиленно исправляется - в дотнете уже наступило перерождение после массовых релизов в open-source, переделанного asp.net, и появления DNX. По сути теперь .net официально поддерживается на *nix - системах. Это конечно надо было сделать намного раньше, но и сейчас этому рады.
NuGet прекрасно справляется со своими задачами, более тесная интеграция в билд-процесс в DNX только улучшит процесс взаимодействия с ним.

Ну и последнее - разработка UI. Все что есть в Java-мире (JavaFX, Java3D, Swing) это совсем не то. Windows Forms был отличным аналогом Дельфийских компонентов для UI, WPF в свое время вышиб немало дверей своим появлением. Если б он еще и развивался как подобает... Да, конечно, на джавовских технологиях вы напишите кроссплатформенную вещь, но она будет одинаково чужеродно смотреться и на винде, и в линуксовых desktop-средах. А людям в enterprise не особо нужна кроссплатформенность в UI - им намного важнее аккуратный привычный интерфейс, в том числе на Винде. Сейчас WPF может потеснить только современный Qt. Выбирая сегодня UI для десктопа, я бы выбирал между WPF и Qt, про джаву бы даже не подумал (да, я считаю что сегодня далеко не все можно и нужно пихать в браузер на тормозной JS. Весь новомодный неповоротливый софт, написанный с использованием Atom-а, меня удручает).
ПРАВКА: посмотрел последние демки по JavaFX. В общем-то неплохо, осталось только дождаться хорошего роста коммьюнити и надеяться что не будет проблем с производительностью в сложных приложениях.

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

P.S. Да, тут кстати пишут что игродельство на C# достигло серьезного уровня. Я 3d делал и делаю на C++, поэтому тут пусть кто-нибудь другой прокомментирует.

Что такое NuGet?

Менеджер пакетов, изначально ориентированный на .Net, но в данный момент и с некоторой поддержкой нативных библиотек под Винду.

Дружит ли он с SharpDevelop?

Он достаточно самостоятелен, SharpDevelop давно не открывал, возможно нужно будет пользоваться командной строкой.

Где найти информацию по нему?

На оф. сайте и в нормальных книгах по .Net.

как добавить в solution/ project библиотеку без использования NuGet?

Add Reference и выбирайте нужную сборку, все так раньше и делали.

В английском я не силен.

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

0.14812561761131
0.057436987123556

0.148125617611310
0.057436987123556

Не?

А вообще что мешает сгенерить целое число и поделить его на INT_MAX? или на максимальное число, которое может быть сгенерено? Как раз получите интервал [0; 1)

Программа должна запускаться дебаггером уровня ядра и отлавливать исключения в ядре. Поглядите, как это SoftICE умел делать.

1) поиметь более свежую версию программы, которая больше не пытается писать в Program Files, и уж тем более в папку Винды (т.е. настройки, конфиги, сэйвы, скриншоты - все это должно быть в папке пользователя, а не по месту установки приложения);
2) поставить программу в отдельный каталог, на который у вас (как пользователя в Винде) будут права. Т.е. сами создаете папку (напр., Programs, или Games) и ставите туда, по идее т.к. папка ваша, Винда не будет виртуализировать ее. У меня и весь Стим и WoW стоит в Games, поэтому проблем нет (WoW до сих пор сохраняет скрины в папку игры, в отличие от D3 например);

Вообще это известная проблема со старыми приложениями. Кстати, у вас стимовская контра? Да, кстати, брандмауэр тут совершенно не при чем, все зависит от файловой системы.

recursi0n доброй ночи. Пожалуйста, прочтите мой ответ на аналогичный вопрос: ClassName::functionName или objectName.functionName? , наверняка что-то почерпнете для себя.

Как задать массив, в который можно записать и целые и вещественные числа?
boost::variant<int, double>

Только сначала убедитесь, что вы понимаете, что делаете и чего хотите.

Олег Цилюрик

C++ типизированный язык, и в массиве могут быть элементы только одного типа;

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

"Нормально ли создавать в каждом классе куча экземпляров других классов?", "Не режет ли потом данная программа по производительности ПК с такими количеством уровнями классов?"

А вы поймите, что если вас беспокоит приведеннный вами код, вам надо не о сколько о классах думать, и не о производительности, сколько о функциях и методах. Зелим Бельтоев уже хорошо намекнул вам об этом, я скажу еще раз словами: то, что ОБЪЕКТОВ много и между ними сложные связи - это НОРМАЛЬНО. Самое главное, что у вы должны уметь ограничивать - сложность и объем связей в КОНКРЕТНОМ участке кода. Пока вы понимаете, ЧТО у вас написано в конкретном методе, и КАК это себя ведет (причем, это понимание не расходится с рельностью) - вы все делаете правильно. Это важнейший критерий. Производительность это тоже фактор, но я даже не могу себе представить, насколько сложную структуру классов нужно изобрести, чтобы она реально мешала тому же CLR исполнять код. Реально узкие места по пр-ти возникают в алгоритмах с высокой алгоритмической сложностью, таких мест обычно мало (если они вообще есть, в бизнес-приложениях в 99% случаев все упирается в IO, или в необходимость побольше кэшировать на клиенте), и они целенаправленно оптимизируются.

Жесть полная.

class iClass {
public:
void method1();
virtual method2();
}

Это не абстрактный класс, у абстрактного должно быть недоопределенное поведение, т.е. хотя бы один pure-virtual метод. У вас есть виртуальный метод, но для него ожидается релазация. Если бы iClass был бы абстрактным, то код
new iClass();
никак бы не скомпилился

Как правильно создать экземпляр класса myClass через интерфейс iClass и использовать у этого экземпляра method3()?

Правильно - никак, задача поставлена некорректно. Если у вас есть некоторый интерфейс, работать нужно через него. Если вам нужно создавать экземпляры различных классов-реализаций, вы должны писать new КонкретныйКласс(), а потом уже при желании, приводить к типу интерфейса. Если вам нужен method3, то вам НЕ НУЖЕН iClass, вам нужен myClass, т.к. именно В НЕМ есть method3.

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

Инструкция для Boost::ASIO: www.boost.org/doc/libs/1_59_0/doc/html/boost_asio/...

Использование HTTP-клиента в cpp-netlib с возможностью HTTPS-соединений: cpp-netlib.org/0.11.1/reference/http_client.html

Теоретически заголовочный файл в проект подключать не обязательно, это для вашего удобства (чтобы вы не теряли файлы, которые у вас есть в проекте). А вот cpp нужно полюбому, т.к. иначе у компилятора не попросят его собрать, а линковщику - не расскажут, что есть объектный файл (который получится после компиляции), который содержит реализации неких функций. Результат - линковщик ищет-ищет, и не находит релизацию метода.
Если бы у вас был lib а не cpp, то ситуация та же самая, только без этапа компиляции. Грубо можете считать lib-файл группой собранных воедино объектных файлов. В нем уже скомпилированный код находится, поэтому его нужно передавать сразу линковщику. Для этого в ключах линкощика указываются так называемые Library Directories - директории, где искать библиотеки, а также dependencies - какие конкретно lib-файлы надо просматривать при линковке. В студии есть как глобальный список таких директорий, так и локальные настройки для каждого проекта.

1) если хотите проверить, что кликнули на фигуру - лучше сделайте это с помощью уравнения эллипса;
2) если все-таки нужен цвет пикселя - лучше делайте всю отрисовку в отдельный Bitmap, его потом выводите на форму (с помощью контрола Image, например), и ИЗ НЕГО потом считывайте цвет при клике по контролу. Так будет меньше сюрпризов, чем заморачиваться с экраном;
3) внимательно следите, относительно чего считаются координаты, с которыми вы работаете - относительно угла экрана, формы или клиентской области формы.

Mark Collins - Beginning WF смотрели? Там вроде нет особой разницы под WinForms или WPF

> То есть за все запуски программы оно накапливается.
Это было бы крайне странно, маловероятно, что причина в этом. Есть возможность собрать трафик сниффером и посмотреть, какая длина последнего успешно принятого сообщения, а какая - у первого выброшенного?