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

TL>Там будет в основном клиент-сервер разного уровня много-уровневости. Либо с веб-интерфейсом, либо с джава-дотнет клиентскими формами. А легаси си,++ там вполне себе могут остаться бекграундные генераторы отчетов каких-нибудь, которые и выбросить нельзя

это legacy

TL>К тому же на внутрикорпоративный трендинговый софт почему-то до сих пор Си++ программеров ищут. Может легаси, а может и правда жив еще курилка.

а это performance-critical и то его пишут на всём вплоть до ml и хаскеля (в дойчебанке), поскольку там и алгоритмы сложные нужны и в то же время скорость. а пользователей так мало, что дешевле каждому из них машину вдесятеро мощнее купить

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

__>классический пример из C# — если счетчик цикла делать не int, а Integer...

Ничего, что типа Integer в шарпе нет, а int — синоним System.Int32?

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

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

__>>классический пример из C# — если счетчик цикла делать не int, а Integer...

HB>Ничего, что типа Integer в шарпе нет, а int — синоним System.Int32?
ну ошибся я, про Яву написал. про C# можно придумать похожий пример со string ами в цикле

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

__>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, __kot2, Вы писали:
G>>>>И циклы разруливает? И нету refcount? И можно безопасно между потоками передавать?
__>>>цикл — это брошенный замкнутый список без указателя на саму сущность — список.
__>>>если у нас есть сама сущность "список", то он уничтожится когда мы потеряем на него указатель. брошенный список это архитектурная ошибка даже без смартпойнтеров и это такая редкая вещь, что проще встретить слона в лесу, чем в проекте эту проблему
G>>Датыче?
G>>А в языках с GC циклические ссылки — вполне нормальное явление.
__>да и в С++ их никто не запрещает. циклически связанные элементы без контейнера — это что вообще? пример?
Спокойно. Загружаю данные из БД, у меня есть Клиент, который имеет список Заказов, каждый из которых ссылается на этого самого Клиента.

Ты просто толком не работал в языках с GC чтобы понимать когда и что там бывает.

__>>>чем плох refcount? требует доп память? но, например, мелкие обьекты предпочитают собирать в коллекции и использовать соотв-но ее как едуную сущность, а не как ерунду с коунтером у каждого элемента.
G>>И память и время инкремент\декремент(на каждое присваивание), а также синхронизацию (привет многопоточность)
__>О, Ассемблер я люблю.
Причем тут ассемблер?

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

__>а насчет синхронизации — механизмы что у С++, что у Явы, C# — одинаковые, аппаратные.
Во-первых не одинаковые, а во вторых используются по разному.

__>тут никуда не деться, только вот синхронизация Java и C# немного, как бы сказать, наивная. такая школьно-курсовая — там нет разграничений на запрос чтения и на запрос записи — там просто — запрос на обьект. а это сказывается на многопоточности. например, как яве сделать, чтобы обьект можно было читать многими потоками, а писать только одним?
В java не знаю, не работаю в ней, в .NET есть ReaderWriterLockSlim.
Кстати, как такая же задача решается в C++?

__>это напрямую сказывается на скорость работы, например, сервера — у нас 100 потоков, а мы постоянно их блокируем и по очереди пускаем читать одно поле. некрасиво..
Ты опять показываешь свое незнание. Так как ты описываешь делают те, кто прочитал первые три страницы книги по C#\Java.


__>>>почему нельзя безопасно между потоками передавать?
__>>>в С++ есть мощные шаблоны, которые позволяют легко параметризовать смартпойнтеры для потокобезопасной работы — автоблокировке мутексом при вызове любого метода, например — совершенно прозрачно для программиста. ничего вообще переписывать не надо. поменял параметры (traits) смартпойнтера — все, у нас автоматом syncronyzed (this) на все вызовы встало
G>>Именно. Обвешаный всей этой фигней смартпоинтер в купе с аллокатором начинает тормозить хуже GC.
__>правильно люди пишут, что современные компы так быстро развиваются что уже вполне даже можно считать издержки Явы-C#, например, на вызовы метода вполне даже так ничего .. с пивом потянет


__>а если говорить в рамках О — нотации, то вот как раз GC добавляет проблем, которые я описывал выше,
Ниче он сам не добавляет, добавляет неправильно написание программы.

__>кроме того, что он дерганно и достаточно надолго вмешивается в работу программы. я бы не стал ездить даже на супер навороченной машине, если она периодически глохнет. ну да, средняя скорость вполне может быть ничего — а вот удобства езды никакого. ну не 21ый век это.
Доказательства по аналогии не катят вообще.

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

HB>>Ничего, что типа Integer в шарпе нет, а int — синоним System.Int32?
__>ну ошибся я, про Яву написал. про C# можно придумать похожий пример со string ами в цикле
Теперь ясно. Если ты имеешь ввиду такой код:

var пицот_тыщ = "500000";
for (string i = "0"; int.Parse(i) < int.Parse(пицот_тыщ); i = (int.Parse(i) + 1).ToString())
{
    Console.WriteLine(i);
}

, то да, Шарписты часто так пишут. Повышается читабельности и многопоточность


Завязывай уже

Здравствуйте, MxMsk, Вы писали:
MM>, то да, Шарписты часто так пишут. Повышается читабельности и многопоточность
да я в общем-то не холивор хотел затеять что С++ всех круче. проще застрелиться, чем на С++ с БД работать или гуй писать на MFC
я начал все с того, что C# и Java нисколько не перекладывают геморрой с головы программиста на голову компилятора. есть конечно технические моменты — COM, Unicode.. но что касается алгоритмов и освобождения памяти-ресурсов то тут шансы наломать дров не меньше чем на чистом С

Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, MxMsk, Вы писали:
MM>>, то да, Шарписты часто так пишут. Повышается читабельности и многопоточность
__>да я в общем-то не холивор хотел затеять что С++ всех круче. проще застрелиться, чем на С++ с БД работать или гуй писать на MFC
__>я начал все с того, что C# и Java нисколько не перекладывают геморрой с головы программиста на голову компилятора. есть конечно технические моменты — COM, Unicode.. но что касается алгоритмов и освобождения памяти-ресурсов то тут шансы наломать дров не меньше чем на чистом С
и вообще я давно хотел бы перейти на яву — как только ее увидел. ну кайф же на ней писать, просто как в мерседесе сидишь.
но она же парализованная из-за своего GC, берешь задачу и понимаешь — нет, тут ява не проканает. жаль.. был бы способ яве GC подменить или хоты бы пусть собирает мусор сразу после удаления последнего указателя, растягивая это удовольствие равномерно, а не рывками, я б уж давно на нее бы перешел. но у нее ниша другая. Ява живет и прекрасно существует параллельно с С++, занимая свою небольшую с точки зрения разработки, зато огромную с точки зрения бизнеса нишу. и C# за ней бежит — "и я! и я тоже!"

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

On 07.10.2010 14:48, __kot2 wrote:
> ь или хоты бы пусть собирает мусор сразу после удаления последнего
> указателя, растягивая это удовольствие равномерно, а не рывками,

На эту тему есть развесистое чтиво:

http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html

Возможно какая-то комбинация волшебных -XX и поможет.

--
WBR,
Serge.

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

BZ>так это legacy массовый софт.

так а новый массовый софт пишут на джаве / дотнете?

BZ>если возьмёшь внутрикорпоративный, стартуемый сейчас, то там будет противоположная картина

тут не в курсе.

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

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

BZ>>>фанат чего?
D>>фанат-лингводрочер

BZ>взаимно

BZ>>>в библиотеках что ли?
D>>В стандарт завезут. При должной сноровке можно пользоваться и сейчас.

BZ>вот когда будет, тогда и будем о нём говорить

BZ>>>как имитировать GC, как имитировать GT, как имитировать клозуры вместо того чтобы заниматься делом. в чём тут разница с асмом? на нём тоже всмё можно сделать библиотеками

D>>Ты давно сам на с/с++ вручную синхронизовался? Я давно.

BZ>похоже, ты уже забыцл что речь шла о green threads

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

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

BZ>>>я назвал самые базовые вещи, которые мне необходимы для выражения алгоритмов
D>>Булат, при всем уважении ты не составляешь даже и 5% необходимых для опровержения тезиса. На C# сейчас есть неплохая реализация всего, что тебе надо, покажи мне хотябы 100 человек, которые этим реально пользуются, а 3.14руют у новичков и эстетов.

BZ>в попытке доказать свой тезис любой ценой ты постоянно мухлюешь с аргументами. то причудливо мешаешь наличие в языке библиотек с удобством будущих built-in языковых средств, то доказываешь удобство библиотечных green threads тем, что ты не используешь синхронизацию для решения других задач, то делишь все фичи ЯП на ненужные потому что ими не пользуются новички и ненужные потому что их может сэмулировать профессионал

Чито? я прям как фортепьян, более того ничего из того, что ты перечислил я не говорил Про ГТ тебе ниже уже все расписали. Я если честно, не сталкивался с жизненной необходимостью их использовать. При решениии сложных алгоритмических задач (распознавание образов, видеообработка, ЦОС) для распараллеливания я в основном использую OpenMP (заметь ничего руками не синхронизирую) для грязного прототипирования, а дальше джентельмены вылизывают это для засовывания в продакшн.


BZ>де-факто C++ остался языком именно профессионалов, которым платят деньги за преодоление трудностей когда не осталось других вариантов.
Он становится языком профессионалов не из-за трудностей, которые приходится преодолевать, сколько из-за ложной "сложности". В народе ходят активные слухи, что на ++ все надо делать РУКАМИ (и кто бы мог их распространять).

BZ> для прикладнины среднеквалифицированные программисты в основном используют c#/java из-за упомянутых мной особенностей, облегчающих наш будничный труд

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

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

BZ> и если твои прикладные задачи не имеют особых требований к производительности, то ты сэкономишь массу времени, заменив C++ на C#
В общем случае, это неверно.

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

G>И циклы разруливает? И нету refcount? И можно безопасно между потоками передавать?

Кстати да, всегда было интерестно как в GC разруливаются циклические зависимости? Как там это реализовано?

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

FR>>Полноценные зеленые потоки есть в OS например в windows это Fibers

G>Ну бред же. Так же, как и обычные потоки Файберы жрут по метру памяти, только шедулятся вручную, а не ОС, что несет как достоинства, так и недостатки.


LPVOID WINAPI CreateFiber(
__in SIZE_T dwStackSize,
__in LPFIBER_START_ROUTINE lpStartAddress,
__in_opt LPVOID lpParameter
);

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

__>>программы на C#-Java работают неравномерно. они то работают, то не работают
O>На плюсах та же проблема, если плюсовая программа запускается на обычной ОС.

Плюсовые программы конечно сейчас тоже разжирели, но памяти все-так жрут прилично меньше чем ява/шарп.
Да даже легкие GC например OCaml'овский тоже заметно меньше ее отъедают.

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

G>Вот у меня как-то диспетчер задач показывает что за память в основном борятся нативный Chrome с нативным же SQL Server. Ты думаешь что программам на C++ надо меньше памяти в реальных условиях?

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

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


__>я кстати и не только про int пишу, я про сам подход языков с GC на основе деревья достижений и реорганизующегося стека — из популярных это C#, Java, Python. сами подходы этих языков провоцируют на на писание маразматического асимптотически по памяти кода, который из-за этого будет "то работать, то не работать".

В питоне GC — подсчет ссылок.

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

G>>И циклы разруливает? И нету refcount? И можно безопасно между потоками передавать?

N_>Кстати да, всегда было интерестно как в GC разруливаются циклические зависимости? Как там это реализовано?

Дотнетовский GC вместо того, чтобы искать объекты, которые "не нужны", ищет все, которые достижимы по ссылкам от "корней" (например, от статических переменных или локальных переменных выполняющегося метода), помечает их как живые и уничтожает все остальные.

Это, конечно, очень грубое описание.

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

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


__>>я кстати и не только про int пишу, я про сам подход языков с GC на основе деревья достижений и реорганизующегося стека — из популярных это C#, Java, Python. сами подходы этих языков провоцируют на на писание маразматического асимптотически по памяти кода, который из-за этого будет "то работать, то не работать".

FR>В питоне GC — подсчет ссылок.
хорошая новость
а то я думал, что раз они сделали отступы эти, то и GC обязательно тормозной должен быть

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

HB>Дотнетовский GC вместо того, чтобы искать объекты, которые "не нужны", ищет все, которые достижимы по ссылкам от "корней" (например, от статических переменных или локальных переменных выполняющегося метода), помечает их как живые и уничтожает все остальные.

HB>Это, конечно, очень грубое описание.

Понятно. Тогда это многое обьясняет почему он такой медленный

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

U_E>>что любопытно, при этом почти весь софт, что стоит у нас на машинах (ок-ок, у меня) написан именно на С++, в меньшей степени на Delphi, а дотнетных программ что-то не особо и видно. в быту, так сказать.

BZ>так это legacy массовый софт. если возьмёшь внутрикорпоративный, стартуемый сейчас, то там будет противоположная картина

Пять лет назад это отмазка проходила сейчас уже нет.
А внутрикорпоративный софт практически и не писался на C++ были VB и Delphi с плавным перетеканием в яву.