Ranger21

Нет. не получается. Изучайте синтаксис С++
После оператора Continue будет выполнен ++, никакого обнуления не произойдет.

Фишка этого кода в другом: здесь пытаются сгенерировать все пары объектов, делая проверку nObjects ^2 раз.
Это можно сделать за меньшее число итераций и без проверок.

Aside Ясно, создание переменной происходит один раз, просто оно входит в функцию. х) Но в каком случае может оказаться, что эти два числа не равны друг другу?

Это будет случаться ровно nObjects^2 - nObjects раз.

Ах... тогда понял, да... это мега-бред какой-то. =)

И как это заметить в коде? Цикл внутри цикла?

я за С#!!! и за ASM

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

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

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

Вот чем мне не нравятся разработки Майкрософт, так это постоянным жестким смешением концепций. В тот же C# они напихали и указатели, и свой SQL с шахматами и танцовщицами, и конструкции из функционального программирования, и прочую неведомую фигню вроде nullable типов. С другой стороны, в F# у них изменяемые несколькими способами переменные, и тоже груды какого-то непонятного синтаксиса, причем в нескольких вариантах, в этом всём без поллитра не разберёшься (сейчас как раз изучаю этот язык)

Указатели в C# есть добро. В быту они практически не нужны. А вот когда они все-таки нужны - вот здесь C# реально выигрывает. Что касается nullable типов - а что, очень удобно помойму. SQL, вы наверно имели в виду LINQ. Ну с ним все просто - не хотите - не используйте Стоит заметить, что все изменения, которые вводились в C# с момента его появления, за редким исключением, являются лишь новыми способами , без которых вполне можно жить ценой более длинного кода.
Что касается функционального программирования - и правильно, что MS его продвигают. Когда я был студентом, очень бесило, что нужно тратить на написание (а точнее описание) очевидных вещей так много кода. Функциональное программирование эту проблему решает во многих случаях, увы не во всех

Aside


да ерунда это. С++ умрет не раньше той-же Явы. Например он совершенно точно останется в Unix (там до сих пор в ходу очень много даже чистого С кода). Некоторые плоскоголовые менджеры сравнивают его с асемблером, что является хорошим индикатором их идиотизма Его считают низкоуровневым только программеры которые писали лет 10 назад без STL и Boost, а потом вдруг перешли на C# / Java.

ToSHiC


смотря на чем, на WinAPI / MFC да, а на Qt это по производительности (т.е. по затратам времени кодера) не отличается от C# + .NET.

Добавлено спустя 5 минут 19 секунд:
Aside


на самом деле в очень многих смартах, тот же винмобайл, айфон, симба, маемо/миго, даже андроид (NDK)



на том на котором больше всего писал, особенно последнее время ("время" тут не дни конечно и не недели, а месяцы минимум). Вообще основным языком будет только один. У меня например сейчас в ходу: C++, Objective-C, Python, из них лучше всего знаю С++, потому как больше всего опыта, прочитано книг, понимания тонкостей, знания библиотек которые там в ходу. Python например от случая к случаю использую, и в основном для маленьких задачек - выветривается быстро, да конечно вспоминаешь по ходу работы, но легкости в кодинге нет.
Ранее использовал Object-Pascal, выветрился нафиг уже, ничего кроме базовых понятий, более 10 лет прошло (хотя я на нем плотно программил 2 года). PHP - тоже частично выветрился (хотя то что он С-подобный что облегчает ситуацию), но главное уже тотально устарели знания, когда я его использовал там не было ООП, не было тех либ которые сейчас в ходу и т.д., я это знаю потому, что моя жена с ним плотно работает и вижу что она использует. Но тем не менее могу что-то допилить, как-то дома ставил на свой сервак веб-морду к rTorrent, пришлось кое-что переделать в принципе разобрался с помощью док, гугла и в особо тяжких случаях жены .

Со спец. языками типа SQL немного проще, они несложные, если один раз изучил и хорошенько попользовался, то знания остаются надолго. Аналогично языки разметки html / xml.

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

Ява не менее чем в 3 раза востребованнее С++, на данный момент.
Бизнес приложения под заказ на С++ не создаются, а если и создаются, то различными не очень адаптированными к рынку компаниями.


Количество С кода в Unix (кстати. в которой из них?) не имеет отношения к популярности С++ в прикладных программах под заказ. И Джавы в Unix все равно больше как не крути


Я с этим на 85% согласен. Действительно, с данными библиотеками С++ становится куда более дружелюбным, гибким и пригодным для не очень запарной разработки. Однако, классические проблемы человеческого восприятия он не решает: как не крути, и не используй всякие умные и неумные указатели, мы по прежнему работаем с голой памятью, которую по прежнему легко испортить. В С# - тяжело.


QT отличная библиотека. Однако, в ней присутствуют паттерны, которых в Windows Forms, к примеру, просто нету. При равных возможностях. Все-таки я думаю, входной порог в QT программированием выше. Разумеется, QT это не только интерфейсы, но как правило все подразумевают именно их.


По языку С++ написано много книг, мастеровитый С++ программист должен был их все прочитать и знать все заковыристые особенности этого языка, только тогда он крут (по крайней мере так было раньше),иначе - простой кодер.
Все эти книги и псевдовозможности самого языка находятся очень далеко от цели любого языка программирования - решения практических задач. Даже как бывший С++ программист. я считаю. что, например, Александреску вреден и вместо того, чтобы сподвигать человека к непосредственному решению задачи, он учит его строить все новые и новые абстракции уровня кода, которые якобы позволяют делать что-то удобнее, а на самом деле делают код более сложным и трудноизменяемым.

Я считаю, что главные критерии ценности языка в современном мире являются простота программирования на нем в аспекте скорости производства решения для данной задачи, т.е. продуктивность языка, порождение им удобных, скомпонованных и модульных архитектур, а так же наличие удобной стандартной библиотеки. С# здесь выигрывает. Связка F# + C# делает из программиста машину для производства кода.

высоконагруженные - создаются ещё как. производительность - не конёк явы, как ни крути

Aside
у меня такое ощущение, что ты судишь по аутсорсу, где индусы, пакистанцы и вьетнамцы готовы работать за еду, проф. уровень их невысок, туда отдаются только несложные задачи, и востребованы как можно более уйстойчивые к code monkeys технолгии.

Я не спорю, шарп и ява хорошие языки, и технологии с нимим связанные тоже неплохие, но не везде и не всегда они все решают. Где то лучше будет применять вообще функциональны языки, а среди вьетнамцев может быть знающих что такое монады, нет вообще. Можно ли отсюда сделать вывод, что функциональщина это фигня полная?

Ниша С++ сместилась и он уже не столь маинстримный, с этим я согласен. В то же время я не согласен, что на нем нельзя делать типичные окошечные приложения по быстрому, Qt и вперед, это задачи такие вполне в аутсорсе встречаются. Причем, как ты правильно заметил, Qt не просто окошечная либа, а вполне так серьезный фреймфорк сравнимый с .NET, на нем даже серверные приложения можно делать, хотя эта часть там не очень развита и .NET тут наверное впереди.

Еще такой момент: как это не странно, но С++ в ряде случаев оказывается более кросплатформенным чем Java или C#, и это не мои личные бредовые теории, а суровая практика, у меня есть код который работает на никсах, мак оси, айфоне и встроенке на винЦЕ, не заставит труда его запустить на андроиде через NDK (просто мне лично пока не до этого, и нет заказа). И это не хелоо-ворд, вполне так сложная вещь, использующая либы sqlite, zlib, icu, boost, и ряд других менее известных, кое что из-них пришлось допилить мне. Никакая ява этого не обеспечит, просто потому что ява эта не на всех платформах имеется, и явы могут отличаться, андроид тому пример, так что даже Оракл (правоприемник САНа) подал иск на Гугл, за то что он исковеркал идею кода работающего везде, как в свое время это сделал микрософт. А .NET и подавно, это виндоуз онли технология, моно же для линукс-гиков, готовых рисковать и извращаться.

Ну и каков процент таких приложений? Более того, высоконагруженные и на Java создаются и прекрасно работают.
Железо решает.


Это вообще к чему сказано? Я готов с этим поспорить.


Я выше как раз и писал про функциональный язык F#.


С тем что С++ более кроссплатферменный, чем C# будет не соглашаться только человек, не знающий состояния дел.
Что касается C++ vs Java, то во-первых, исторически Java была всегда более кросплатформенной потому, что так и задумывалась, а то, что я не могу писать на ней под айфон или что-то другое (кстати, а так ли это?) не делает её менее кроссплатформенной в её основном секторе enterprise приложений. Во-вторых - Java является кроссплатформенной на бинарном уровне, а С++ нет, поскольку требует перекомпиляции (всякие варианты, типа различного кода в одном файле для разных платформ, являются уже надстройкой, хотя я с ними никогда не имел дела, честно говоря).


Что касается рисков использования Mono - мне видится, в первую очередь, риск низкого перформанса. К сожалению, я почти не имел дела с данной имплементацией .NET и не знаю никого, кто бы это внедрял что-то на данной платформе.

я же сказал - высоконагруженные. в таких проектах применяются сервера уровня Sun SPARC Enterprise M8000 и HP Superdome. впрочем, могу привести пример и для обычных "домашних" процессоров - гугл. вот эта картинка наглядно показывает, какую долю рынка они занимают

опять же, если брать из небольших - то абсолютное большинство веб-серверов (apache, nginx, iis) написаны на сях, а не на жаве. жава же подходит в основном для больших приложений, с разлапистой логикой и бизнес-логикой, но не требующих большой производительности. если считать в деньгах - то, возможно, она лидирует, но говорить о том, что она вытеснит с++ никак нельзя. она пока даже кобол в банковских приложениях вытеснить не может:)

Картинка, безусловно, интересная, но давайте не будем путать процент серверов с процентом проектов, а процент проектов, с процентом востребованности той или иной технологии на данный момент.



И что? Вебсервер написали и забыли про него - это утилитарное программное обеспечение, которое непосредственную задачу бизнеса/заказчика не решает. Такие приложения и пишутся на более системных языках.
Я сейчас говорю про ПО, которое решает прикладные задачи , которые возникают у людей.


Пожалуйста, приведите конкретные примеры систем, где сейчас используется Кобол (кроме SAP) и чтобы на известном всем сайте было приличное число вакансий по данной системе.

Aside



да теоретически приложение Java бинарно-кроссплатформенно, а практически ты например не сможешь запустить приложение J2EE на Android, там нет бинарной совместимости, отличаются и стандартные библиотеки. J2ME тоже у всех немного разная. На айфоне Явы точно нет и не будет (только Objective-C / Objective-C++). На Windows Mobile и Windows CE что-то из J2ME вроде можно запустить если конкретный производитель устройства об этом позаботился, на практике Java можно сказать тоже нет, только C++ и C#. В итоге не все так радужно. Если говорить о серверах, то Java распространена в основном на Unix машинах, а там и C/C++ не сильно отличается сам по себе и по библиотекам



а еще логику часто пишут на скриптах

в россии практически нету компаний-разработчиков софта. интеграторов дофига и больше, но разработкой они не занимаются. никто из телекомов не пустит интеграторов в чужой биллинг. никто из банков не пустит интеграторов в биллинг (или как его правильно назвать?), клиринговую или процессинговую систему. вопросы про кобол ещё есть?:) кстати, ITA Software, крупнейший разработчик софта для поиска и бронирования туров/билетов во всю фигачит его на лиспе, и этот софт активно юзают, и в своей нише они лидеры. и опять же, никто туда никаких интеграторов не пустит, максимум - интерфейс на сайт встроить. поэтому да, на российском рынке труда востребованы вакансии жава-программеров, причём совершенно не обязательна высокая квалификация.

итак, сравним вакансии на hh.ru:
в поиск вбил с++, москва: 416 вакансий, 4 премиум.
Software Developer/Senior SWD C++ - 3д визуализация, очень хотят физико-математическое образование
Программист (C/C++) - оптимизация времени отклика биржевых систем (клиентская часть)
Разработчик под Symbian OS - ну тут понятно
и каким-то боком попала вакансия программиста perl

Java, москва: 484 вакансии, 4 премиум
Руководитель группы разработчиков Java - та же контора, что и вакансия №1 по с++, но уже Struts 2, AJAX, Web Services, JUnit
Ведущий разработчик Java - swing, Wicket, Struts или JSF
Ведущий разработчик Java EE - разработка интеграционных и BPM-решений, систем документооборота, заказного ПО на базе Java EE
Senior Java Developer - JSP, Servlet, Web-Services, JDBC, XML, XSLT, JMS, Struts, Hibernate, Spring


мне вот эта минимальная выборка подсказывает требования к квалификации с++ и жава-программистов.

Вы недостаточно хорошо информированы, особенно по второму пункту.



И здесь тоже.


Это мы ещё посмотрим, пустят нас или нет


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



Во-первых, мне не интересно смотреть на С++, я просил показать Кобол - совершенно понятно, что показывать практически нечего
Во-вторых, из приведенной информации очевидно, что Java программист (который ниже) должен знать больше технологий, чем вышеприведенный С++ программист (срез), а значит в данном аспекте его квалификация должна быть выше.

Кроме всего остального, несколько вещей:
1) Java находит свое применение не только в чистом виде, но и как раз в вышеназванных интеграционных проектах, которых скоро будет чуть более, чем очень много. Отсюда получаем высокое разнообразие проектов и востребованность этой технологии и языка.
2) Сравнивать Java EE и Android некорректно, не только потому,что у Java EE другая идеалогия, но и вообще по простой банальной причине отсутствия в Android необходимости в распределенных транзакциях, веб серверах и прочей индустриальной канители, которая к мобильному телефону не применима.
3) Я хотел бы узнать ваши критерии квалификации программиста и то, как она коррелирует с его знанием Java

возможно. есть примеры крупных софтин, написанных интеграторами? есть какие-то конкретные сведения? петер-сервис даёт интеграторам править код? комверс - это закрытый ящик, в ансамбль от амдокса лазает ручками только сам вымпелком. у меня нет сведений о STROM telecom, которую с потрохами купила афк система, но я почти уверен, что интеграторов российских и туда не пускают. только не надо говорить про старт и связьинтек:) это совершенно другая история
ну пустили мы интеграторов (связьинтек проклятый) в свой CRM - ничего хорошего не получилось. к сожалению, после превращения связьинвеста в ростелеком вряд ли что-то изменится к лучшему

0. научится пользоваться фреймворком, кмк, существенно проще, чем освоить нехилый пласт математики для написания рендерера. системное программирование априори более требовательно к квалификации, чем прикладное.
1. я слабо себе представляю, что такое применения жавы в чистом виде. написание библиотек? применение в интеграционных проектах - это, очевидно, очень даже прикладное применение. ОС на жаве, вроде, уже перестали писать:)
2. а я где-то сравнивал?
3. очень слабо коррелирует


собственно, тезисно, глядя в начало дискуссии:
1. вакансий по с/с++ на хх.ру примерно столько же, сколько по жаве
2. в россии крайне мало производителей софта и очень много интеграторов, которые любят пилить и программерам остаётся не сильно много.
3. то, что пишется в рамках интеграторских задач, либо является допиливанием готового, либо не сильно крупное, решения вполне себе типовые. как следствие - меньше требуется архитектурных изысков, а в бизнес-среде, как таковой, практически не нужны математические изыски. в результате получаем низкие входные требования для программистов, фактически сводящиеся к знанию фреймворков и ряда паттернов программирования. много ли жава-программеров могут оценить сложность алгоритма и отличить O(n*n) от O(n*log n)? хочу в гугл:)
4. крупные компании не хотят пускать интеграторов внутрь business-critical софта сторонних производителей, и на то могут быть разные причины: лицензионные ограничения, финансовая ответственность за простои и баги, желание быть независимыми от интегратора.

забавно, но вот сегодня просматривал вакансии по нашему городу, в люксофт требуется как раз "СИСТЕМНЫЙ АРХИТЕКТОР COBOL"