Здравствуйте, Sinclair, Вы писали:

S>А что вы назыаете "азами"? Я на плюсах в последний раз писал, афаик, в 2002. И не считаю знания таких деталей "азами". Азы — это, к примеру, понимание того, в каком порядке пишутся программы

Ну, ты, кажется, вызвался довольно менторским тоном всезнайки разговаривать о С++ коде, даже не врубаясь что там написано?

Не вижу сортировки по алфавиту.

и

А он неявно сортирует??? Офигеть. Я как отвык от того, что для множества нужно задавать отношение частичного порядка.
Я надеюсь, уточнение сортировки в Case-insensitive/accent-sensitive для турецкой локали не усложнит эту безусловно прекрасную программу?

твои же слова?

Вот таки они довольно смешно звучат, особенно если сравнить твой тон и твою эрудированность в вопросе
Так что я и советую таки, перед тем как в след. раз людей смешить, разобраться таки в вопросе СНАЧАЛА...

Здравствуйте, VladD2, Вы писали:

VD>Я сутки работал, трое учился, а по вечерам еще с тем же С++ разбирался. Просить у кого-то за это деньги мне даже в голову не приходило.

Ну что тут поделаешь, а некоторым (я их знаю лично) платят только за то, что они соглашаются где-то учиться... Мир несправедлив...

Здравствуйте, Erop, Вы писали:

E>Ну, ты, кажется, вызвался довольно менторским тоном всезнайки разговаривать о С++ коде, даже не врубаясь что там написано?
Нет, я задал вопрос. Менторский тон — это у тебя в голове.
E>Я надеюсь, уточнение сортировки в Case-insensitive/accent-sensitive для турецкой локали не усложнит эту безусловно прекрасную программу?[/q]твои же слова?
Ну да, мои. Ну так ты ответь, раз ты так хорошо знаешь STL и плюсы — как будет выглядеть программа с учетом сортировки, которую я привел.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, CreatorCray, Вы писали:
CC>>Беда то в том, что входной порог в managed сильно низкий, и обложенный памперсами нуб может спокойно говнокодить не получая при этом за свой говнокод по рукам — работает же, и не падает.
S>Ничего страшного. На плюсах нуб точно так же может говнокодить. То, что приложение сумело запуститься у нуба на машине, никак не гарантирует того, что оно будет устойчиво работать во всех сценариях.

В плюсах нуб просто не взлетит шутка конечно но ...

Здравствуйте, Хвост, Вы писали:
Х>просто вот когда дело доходит до новых апи — здравствуй интероп с нейтивом, хочешь массив на стеке — здравствуй ансейф, тот же пэйнт.нет афаир просто насквозь пропитан ансейфом, зачем тогда сишарп? хорошие вещи делаются только в нейтиве, вот тот же пример с выводом строк, для такой забавы как флейм на рсдн и стримы с регекспами не грех использовать, а вот если бы ето была программа промышленных маштабов — скажим анализатор логов, то здравствуй мем-маппед файлы да стейт-машины с отсутствием аллокаций, и писать етона си++ без ifstream и multiset, а не на сишарпе с gc и аллокацией на каждый чих.
О да. Анализатор логов — это конечно гораздо промышленнее сайта с дневной посещаемостью в сотню тысяч хитов.

На всякий случай напомню, что на каждую строчку лога, которую читает анализатор, этот самый сайт успевает авторизовать пользователя, сбегать в базу, раскрасить синтаксис, выдать HTML. И всё это "с GC и аллокацией на каждый чих", и стримами, и регекспами.
Но нет, конечно же авторы анализаторов логов считают себя гораздо более главными. Удачи.

Здравствуйте, Хвост, Вы писали:

Х>ну, давай по-порядку, на С# я писал давно и немного, на С++ на порядок больше, и есстествено что-то могло забытся, к тому же если ты проследишь начало темы про структуры, то она была о размещении их в массиве, и тут без ансейфа вариант действительно только один — боксинг.
По-прежнему неверно.
Даже при размещении массивов структур в хипе никакого боксинга нет.

Х>Теперь по-поводу "подобный пост про тебя", пиши пожалуйста, ведь ето ты будешь писать обо мне как о разработчике на C#, что ещё раз подтвердит мои слова , C# (особенно в версии 3.5) ето очень мощный язык, но для приложений требующих производительности, малой затраты ресурсов, быстрой реакции интерфейса ето просто моветон.
Ну, если писать на нём, не разбираясь в отличиях value-типов от reference-типов — то да. Но это вообще как бы моветон — писать приложение, требующее производительности, не зная при этом технических основ. Уверяю тебя, при аналогичном уровне знаний С++ результирующая программа будет еще медленнее и нестабильнее.

Здравствуйте, Sinclair, Вы писали:

S>О да. Анализатор логов — это конечно гораздо промышленнее сайта с дневной посещаемостью в сотню тысяч хитов.

S>На всякий случай напомню, что на каждую строчку лога, которую читает анализатор, этот самый сайт успевает авторизовать пользователя, сбегать в базу, раскрасить синтаксис, выдать HTML. И всё это "с GC и аллокацией на каждый чих", и стримами, и регекспами.
S>Но нет, конечно же авторы анализаторов логов считают себя гораздо более главными. Удачи.
авторизация — доступ в нативную rdbms, сбегать в базу — аналогично, раскрасить синтаксис — если ты говоришь об уровне расскраски как на рсдне то ето даже не смешно , выдать хтмл — нативный IIS.
где тут твой C#? позвать то, взять ответ, позвать другое и дать ему ответ предыдущего? клей, сопли, грусть. Ты сам-то в какой области на C# пишешь? а то я смотрю тут каждый второй на C# пишет только дальше сайтов и ентерпрайза никто своё рыльце не высовывает, потому что атата.

Здравствуйте, hattab, Вы писали:

H>У меня был контракт с конторой, в которой зарплата расчитывалась 2.5 суток (!) (большая контора). Они тоже считали это нормальным, пока мы не сократили время до 40 минут (переписали с нуля)

Мама мия... решение матрицы 500*500 занимает доли секунды , ЧТО может занимать 40 минут даже если считать зарплату всего земного шара ??? За 40 минут можно отрендрить ролик с симуляцией жидкости и ткани .

P.S. вот это и называется различные прикладные области, в моей считаются такты и тригонометрические операции.

Здравствуйте, alsemm, Вы писали:

A>После таких вопросов и появляются стереотипы, что С# отупляет

Неа , правильно выражение "разжижает мозг"

Здравствуйте, Хвост, Вы писали:

Х>правда, вот я прямо сейчас смотрю в реализацию гугловского V8, и вижу как ни странно запредельный перфоманс + надёжный и красивый код, а может тебе указать на библиотечку Blitz++ которая уделала фортран на вычислительных задачах (да, фортран, да, на вычислительных задачах) что не удавалось твоему перфоманс-фавориту Си? другое дело что мало кто так писать умеет, большинству проще на шарпах Linq'ом побаловаться или в WPF'е поформошлёпить )

Офтоп , Blitz++ в сад , boost::numeric::ublas на голову лучше (безопаснее и красивее и быстрее).

Здравствуйте, gandjustas, Вы писали:

G>Только делать так не нужно. В первую очередь стоит заняться алгоритмический оптимизацией или даже архитектурной, а не кидаться писать кастомный аллокатор.
G>Причем этот подход работает для любых языков.

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

Здравствуйте, minorlogic, Вы писали:

H>>У меня был контракт с конторой, в которой зарплата расчитывалась 2.5 суток (!) (большая контора). Они тоже считали это нормальным, пока мы не сократили время до 40 минут (переписали с нуля)

M>Мама мия... решение матрицы 500*500 занимает доли секунды , ЧТО может занимать 40 минут даже если считать зарплату всего земного шара ??? За 40 минут можно отрендрить ролик с симуляцией жидкости и ткани .

Ты наверное не думаешь, что расчет ЗП и решение матрицы это одно и тоже...

M>P.S. вот это и называется различные прикладные области, в моей считаются такты и тригонометрические операции.

Вот я и думаю, ты это серьезно, или прикалываешься

Здравствуйте, Erop, Вы писали:

E>Скажем в твоих задачах core обычно на СУБД какой-то реализовано, а в одной из часть core была на C...
Стереотипы... Не надо думать, что на .Net создаются только "коннекторы к БД", это далеко не так. Скажем во всех проектах, на которых я работал, конечно, использовались хранимки, но куча серверной бизнес-логики была на C#. Намного больше чем в SQL и core в этих системах как раз сервер приложений, сплошь себе управляемый.

Здравствуйте, hattab, Вы писали:

H>Вот я и думаю, ты это серьезно, или прикалываешься

Между нами пропасть непонимания.

Здравствуйте, Хвост, Вы писали:

Х>Здравствуйте, Sinclair, Вы писали:

S>>О да. Анализатор логов — это конечно гораздо промышленнее сайта с дневной посещаемостью в сотню тысяч хитов.

S>>На всякий случай напомню, что на каждую строчку лога, которую читает анализатор, этот самый сайт успевает авторизовать пользователя, сбегать в базу, раскрасить синтаксис, выдать HTML. И всё это "с GC и аллокацией на каждый чих", и стримами, и регекспами.
S>>Но нет, конечно же авторы анализаторов логов считают себя гораздо более главными. Удачи.
Х>авторизация — доступ в нативную rdbms, сбегать в базу — аналогично, раскрасить синтаксис — если ты говоришь об уровне расскраски как на рсдне то ето даже не смешно , выдать хтмл — нативный IIS.
Х>где тут твой C#? позвать то, взять ответ, позвать другое и дать ему ответ предыдущего? клей, сопли, грусть. Ты сам-то в какой области на C# пишешь? а то я смотрю тут каждый второй на C# пишет только дальше сайтов и ентерпрайза никто своё рыльце не высовывает, потому что атата.

Таким образом разработчику сайта надо:
1)продумать систему аутентификации и авторизации
2)создать схему БД, соотвествующую требованиям, обеспечивающую целостность данных и хорошую производительность
3)написать SQL или другой код для получения и изменения данных, организовать кеширование данных (возможно распределенное)
4)сделать шаблоны страниц
5)написать код для обработки данных из базы с целью исключения XSS
6)написать код для обработки данных от пользователя и размещения из в БД
7)написать код для противодействия спам-ботам
8)взаимодействовать с веб-сервером для установки кужных параметров ответа

Таким образом разработчику сайтов надо разбираться в проектировании и оптимизации БД, очень хорошо разбираться в протоколе HTTP, разбираться в безопасности приложений, разбираться в клиентских технологиях (HTML+CSS+JS), разбираться в устройтве веб-сервера.
При это сайт не должен содержать ошибок и не должен бешено тормозить, иначе толку нет даже при отсуствии конкурентов.

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

И это все не касаясь еще вопросов обработки тех самых данных — от раскраски синтаксиса до построения аналичитеских систем, способных предсказывать показатели.

так что насчет невысовывания рыльца — мимо кассы.

Вам на C++ часто приходится сталкиваться с таким объемом разных задач?

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, gandjustas, Вы писали:

G>>Только делать так не нужно. В первую очередь стоит заняться алгоритмический оптимизацией или даже архитектурной, а не кидаться писать кастомный аллокатор.
G>>Причем этот подход работает для любых языков.

H>Ты сам недавно писал, что архитектура ортоганальна перформансу
Да.
Архитектурная оптимизация — когда вы избавляетесь от части ненужных вычислений или делаете так что длительные вычисления не оказывают влияния на наблюдаемый перфоманс.

G>Да как раз не все равно. Ты перечитай еще раз о чем я тебе толкую. .NET поребляет больше памяти на практически константную величину. Истории о том что кто-то запустил программу на .NET и она схавала сразу все свидетельствуют о криворукости автора программы, а не об особенностях работы с памятью в .NET.

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

Здравствуйте, soniq, Вы писали:


G>>Да как раз не все равно. Ты перечитай еще раз о чем я тебе толкую. .NET поребляет больше памяти на практически константную величину. Истории о том что кто-то запустил программу на .NET и она схавала сразу все свидетельствуют о криворукости автора программы, а не об особенностях работы с памятью в .NET.

S>Насколько я помню, 18 мегабайт это и есть тот самый минимум, который отжирает сам .Net, дальше памяти нужно много меньше.

Вы неправильно понимаете.

Почитайте http://www.getdotnetcode.com/gdncstore/free/Articles/The%20Memory%20Mystery.htm

С#. Точка.

А C++ можешь изучать в свободное время для общего развития и радоваться, что выбрал C#.

Помни: поменять язык — это тебе не два байта переслать.

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

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

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

Не припоминаю сишарперов, который вдруг стали сишниками.

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

Для C++ часто требуется на порядок более высокая квалификация, а получать ты будешь примерно столько же, сколько C# программист, ну может быть, чуть-чуть больше — в некоторых фирмах. Это относится к России, как в других странах — не знаю.

Если ты раньше писал только на C# бизнес-приложения, то перейти в C++ будет, мягко говоря, трудновато, да и непонятно — зачем?

Я вот который год пишу на C++ и мне как-то немного тревожно за свое будущее…

Здравствуйте, gandjustas, Вы писали:

E>>Лично мне комфортно от того, что можно пробовать строить различные архитекутры, не думая изначально о том, сколько каких мелких объектов где выделяется, потому что в случае чего можно расчехлить тяжёлую артиллерию.
G>Отличная идея. GC как раз позволяет не думать о выделении и освобождении памяти вообще.

Это не правда. Если бы GC позволял не думать о выделении и освобождении памяти, то какой смысл бы был сравнивать производительность GC и стандартного аллокатора С++? Или эти сравнения в топике были бессмысленными?
Как можно не думать о выделении и освобождении объектов, если из-за этого может оказаться очень низкая производительность приложения?

G>Если производительность окажется недостаточной то надо смотреть причны и бороться с ними.
G>Причем чаще всего прчиной оказывается применение неподходчщего алогоритма. Очень редко приходится нарываться на ситуацию когда низкая производительность вызвана особенностями платформы.

А причём здесь алгоритмы, если речь идёт о декомпозиции на объекты? Если бы дело было только в алгоритмах, то тогда не применяли бы ООП, а так бы и писали эти алгоритмы на структурных языках. Алгоритм может быть одним и тем же, но по-разному представляться с помощью объектов, работать с разными объектами. По вашим словам один и тот же алгоритм может быть одновременно "подходящим" и "неподходящим" в зависимости от используемой объектной модели задачи. А если Вы подразумеваете под разными алгоритмами использование разных объектных декомпозиций, то тогда Вы просто ограничиваете доступный набор этих декомпозиций, с помощью которых можно решить задачу, просто называя такие декомпозиции неподходящими из-за скорости выделения памяти. А если я пишу программу на С++, то выбор доступных декомпозиций расширяется. Разве я не прав?