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

L>>Математики пусть алгоритмы на доске мелком рисуют. писать программы должны программисты.

I>Многи ли ты можешь назвать специалистов по теории доминирования которые занимаются этим лет 15-20 ? Выбирать, как видишь, не из чего.

Пофигу. Дайте своим специалистам маткад или матлаб, пусть ваяют нетленку в них. А интергировать будете сгенерированный код. Если они специалитсы по теории, то пусть и занимаются своей теорией, а код пусть оставят профессионалам.

I>>>Это по малолетству так кажется.

L>>Слив защитан.

I>О, ты у Пацака подсмотрел такой аргумент ?

Переход на личности -> неадекват -> слив защитан.

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

L>>>Читаем "в менеджед отсутствует целый класс ошибок, которых в принципе нигде нет". Ты ведь так и не показал нам, что это за ошибки, связанные с указателями.

I>>Показал. вам, сиплюсникам, надо определиться. Или проблем с указателями нет, тогда не ясно зачем вам valgrind, или...
_>Уже определились Вопрос о оценке этих проблем. Мы не считаем их столь значительными и пугающими как нам об этом рассказывают, а когда с ними сталкиваемся используем соответствующие инструменты.

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

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


I>>>Показал. вам, сиплюсникам, надо определиться. Или проблем с указателями нет, тогда не ясно зачем вам valgrind, или...
_>>Уже определились Вопрос о оценке этих проблем. Мы не считаем их столь значительными и пугающими как нам об этом рассказывают, а когда с ними сталкиваемся используем соответствующие инструменты.

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

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

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

L>ну если для бизнеса потеря доли рынка — фигня, то у меня вопросов нет. Только название конторы назови, штоб случайно не вляпаться.

Разве я пишу что потеря доли рынка это фигня ? Хватит додумывать.
Ты просил назвать контору "продавать глюкало, падающее на ровном месте и при этом не растерять всех клиентов".
Я тебе ответил "достаточно потерять долю рынка". То есть, контора, котоаря не может решить внутренние проблемы с продуктом, обязательно потеряет долю рынка. Таких контор пруд пруди, из гигантов — hp, sun, microsoft, ibm...

I>>Ты или читай внимательно, или спрашивай, что непонятно. Я не говорил, что "переписали на жабе". Была кучка проектов, часть плюсовых, часть — джава. Плюсовые вымерли. Джава осталась в строю. Плюсовые вымерли из за обилия проблем внутри кода — утечки, указатели, исключения.

L>Так а я то говорю? плюсы ниасилили, там же указатели и исключения, а от них утечки. Руки кривые, что поделать?

Вопрос в том, где найти должное количество людей которые осилили. Конторы пускаются во все тяжкие, переманивают любыми плюшками и предлагают ЗП топовее некуда и все равно сиплюсников нормальных очень мало — не хватает. А потому проекты запускаются на дотнете, джаве, питоне.
Всё, поезд ушел, С++ превращается в лавочку "для своих".

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

I>>"проект писали криворучки" — не ты ли чуть не пеной брызгал и доказывал что все плюсовики суть мега-продвинутые девелоперы у которых годами не бывает багов с указателями ?

L>Все плюсовики, с которыми мне приходится работать, именно такие. Вы там можете хоть на клавиатуре плясать, но заявлять про "проблемы с указателями", когда на самом деле вы просто ниасилили плюсы несколько самонадеянно. Много на себя берете.

Ага, в старом проекте проблемы в коде за 5-7 лет до того, как я в универ пошел, и основная причина — что я сейчас чего то не умею ? А ты, логик, аплодирую стоя

M>>>>Ну дык. Указатели старательно упаковывают в GC для бедных — auto_ptr, shared_ptr и прочая *_ptr
BBI>>>Это не GC ни разу. Это RAII.

M>>Выделено.

M>>>> чтобы не дай бог кто-то не использовал голые указатели.
BBI>>>Отнюдь. Основная причина: упрощение управления времени жизни объекта. Уменьшение рукопашной.

M>>А что GC, по-твоему, делает с точки зрения программиста? ВНЕЗАПНО упрощает управление временем жизни объекта. Уменьшает рукопашную. Но GC — это зло, а вот все остальное — это добро, агаага

ТКС>Люди, ни разу не писавшие на языках с деструкторами и RAII, под временем жизни объекта понимают несколько другое, нежели люди, активно использующие RAII. Поэтому им не понятно, что GC НЕ упрощает управление временем жизни объекта в понимании С++. В плюсовой программе удаление одного объекта-хозяина часто приводит к целому каскаду событий, как-то закрытие файлов, сокетов, изменение имперсонации (логаут пользователя с точки зрения операционной системы, например) и .т.п.

Да не надо рассказывать сказки. Тут рядом, например, Шеридан показывает, как он это понимает, ага.

ТКС>В языках с GC все эти действия приходится продумывать отдельно от управления памятью. Сложно назвать это упрощением.

Расскажи мне, что происходит при вызове delete на shared_ptr, например? Да ничего не происходит до тех пор, пока счетчик ссылок не обнулится. И тогда пойдет тот самый «каскад» который обломится на очередном shared_ptr со счетчиком > 0 ну и т.п.

Но это жы RAII!!!!одинодинодин

Что в языках с GC что без GC надо достаточно строго следить за внешними к программе ресурсами — файлами, сокетами и т.п. Для всего остального так называемый «современный С++» всеми силами стремится избавится от указателй за *_ptr, которые обеспечивают ровно то, что обеспечивает GC — своевременное удаление этих объектов из памяти.

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

I>>Показал. вам, сиплюсникам, надо определиться. Или проблем с указателями нет, тогда не ясно зачем вам valgrind, или...

L>Если ты не сиплюсплюсник, то что ты к указателям прицепился?

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

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

I>>Многи ли ты можешь назвать специалистов по теории доминирования которые занимаются этим лет 15-20 ? Выбирать, как видишь, не из чего.

L>Пофигу. Дайте своим специалистам маткад или матлаб, пусть ваяют нетленку в них. А интергировать будете сгенерированный код. Если они специалитсы по теории, то пусть и занимаются своей теорией, а код пусть оставят профессионалам.

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

I>>О, ты у Пацака подсмотрел такой аргумент ?

L>Переход на личности -> неадекват -> слив защитан.

Да,да, иди погуляй.

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

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

Они так и делают. Более того — суровые сиплюсники тоже часто мигрируют в менеджед. Вот наоборот сильно вряд ли. например мигрируют потмоу что нужны более разнообразные задачи.

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


L>>Причем практически только в случаях совместного владения или когда владение должно передаваться, в остальных случаях достаточно RAII.

M>Пример можно? Боюсь, в примере не будет
M>

M>X *p = new X();
M>...
M>...
M>...
M>delete p;
M>

New, может, и не будет, но delete будет явный. Из недавнего — собственная реализация дерева без использования умных указателей. Из-за дикого размера дерева и дикого количества оных одно оборачивание детей в умный указатель давало оверхед по памяти мегабайт в триста. Выкинули умные указатели, обучили ноду дерева делать delete в деструкторе. Профит.

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

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

G>>Видишь, ты зная указатели не понимаешь ссылки в .NET.
MM>Ой спасибо. Мне недавно еще посоветовали почитать книгу по WPF, мол, я в нем мало что понимаю. Посоветуй и ты мне книжку, которая учит приемам демагогии.

Из твоей формулировки как раз и следует непонимание ссылок. Путаница в терминологии отражает путаницу в мыслях.

Ссылка никак не относится к адресам. Указатель это именно номер байта в АП, то есть, самый что ни есть, адрес и отсюда следует адресная арифметика и тд.

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

L>>Если ты не сиплюсплюсник, то что ты к указателям прицепился?

I>Я занимаюсь в т.ч. набором и периодически приходится проводить собеседования по С++. бОльшая часть кандидатов валится там где ты и другие утверждают что проблем якобы нет никаких.

Это не они валятся, это ты некомпетентен.

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

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

I>Они так и делают. Более того — суровые сиплюсники тоже часто мигрируют в менеджед. Вот наоборот сильно вряд ли. например мигрируют потмоу что нужны более разнообразные задачи.
Ну и слова богу. Процесс в принципе естественный. Работы меньше. Плюсников сегодня нужно много меньше чем скажем лет 10 назад. Считаю что необходимое количество адекватных разработчиков наловить можно.

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

M>>Пример можно? Боюсь, в примере не будет
M>>

M>>X *p = new X();
M>>...
M>>...
M>>...
M>>delete p;
M>>

L>New, может, и не будет, но delete будет явный.

Что значит "New, может, и не будет" ? Предполагается логику слежения за инстанцами переложить на пользователя дерева ?

>Из недавнего — собственная реализация дерева без использования умных указателей. Из-за дикого размера дерева и дикого количества оных одно оборачивание детей в умный указатель давало оверхед по памяти мегабайт в триста. Выкинули умные указатели, обучили ноду дерева делать delete в деструкторе. Профит.

И получается, если дерево не будет инстанцировать объект, то пользователь обязан знать кишки, т.е. что деструктор нода разрушает элемент

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

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

L>>>Если ты не сиплюсплюсник, то что ты к указателям прицепился?

I>>Я занимаюсь в т.ч. набором и периодически приходится проводить собеседования по С++. бОльшая часть кандидатов валится там где ты и другие утверждают что проблем якобы нет никаких.

L>Это не они валятся, это ты некомпетентен.

Да.

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

I>>Они так и делают. Более того — суровые сиплюсники тоже часто мигрируют в менеджед. Вот наоборот сильно вряд ли. например мигрируют потмоу что нужны более разнообразные задачи.
_>Ну и слова богу. Процесс в принципе естественный.

Процесс естественный, но для с++ ничего хорошего нет. Будет со временем задвинут на задворки как и ассемблер.

>Работы меньше. Плюсников сегодня нужно много меньше чем скажем лет 10 назад. Считаю что необходимое количество адекватных разработчиков наловить можно.

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

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


M>>>А что GC, по-твоему, делает с точки зрения программиста? ВНЕЗАПНО упрощает управление временем жизни объекта. Уменьшает рукопашную. Но GC — это зло, а вот все остальное — это добро, агаага

ТКС>>Люди, ни разу не писавшие на языках с деструкторами и RAII, под временем жизни объекта понимают несколько другое, нежели люди, активно использующие RAII. Поэтому им не понятно, что GC НЕ упрощает управление временем жизни объекта в понимании С++. В плюсовой программе удаление одного объекта-хозяина часто приводит к целому каскаду событий, как-то закрытие файлов, сокетов, изменение имперсонации (логаут пользователя с точки зрения операционной системы, например) и .т.п.

M>Да не надо рассказывать сказки. Тут рядом, например, Шеридан показывает, как он это понимает, ага.

А при чем здесь Шеридан? Он что, на плюсах программировать умеет В форум по плюсам он заходил пару раз, порол чушь. Про RAII его постов не припомню

ТКС>>В языках с GC все эти действия приходится продумывать отдельно от управления памятью. Сложно назвать это упрощением.

M>Расскажи мне, что происходит при вызове delete на shared_ptr, например? Да ничего не происходит до тех пор, пока счетчик ссылок не обнулится. И тогда пойдет тот самый «каскад» который обломится на очередном shared_ptr со счетчиком > 0 ну и т.п.

Это желаемое поведение. Все что надо отработает ровно в тот момент, как только объект перестанет быть нужен. А не через три секунды или полчаса.

M>Но это жы RAII!!!!одинодинодин

Что такое "одинодинодин"?

M>Что в языках с GC что без GC надо достаточно строго следить за внешними к программе ресурсами — файлами, сокетами и т.п. Для всего остального так называемый «современный С++» всеми силами стремится избавится от указателй за *_ptr, которые обеспечивают ровно то, что обеспечивает GC — своевременное удаление этих объектов из памяти.

GC не обеспечивает своевременное удаление объектов из памяти.

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

ТКС>GC не обеспечивает своевременное удаление объектов из памяти.

Что значит своевременное?

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

L>>New, может, и не будет, но delete будет явный.

I>Что значит "New, может, и не будет" ? Предполагается логику слежения за инстанцами переложить на пользователя дерева ?

Ты продолжаешь показывать свое чудовищное непонимание вопроса. Тебе точно не стоит собеседовать кандидатов на C++.
"New не будет" означает, что сущность, ответственная за корректное удаление некоего объекта, его сама не создает. Этот объест ей передается в полное владение извне, в конструкторе. Сам же объект создается, к примеру, в фабрике.

>>Из недавнего — собственная реализация дерева без использования умных указателей. Из-за дикого размера дерева и дикого количества оных одно оборачивание детей в умный указатель давало оверхед по памяти мегабайт в триста. Выкинули умные указатели, обучили ноду дерева делать delete в деструкторе. Профит.

I>И получается, если дерево не будет инстанцировать объект, то пользователь обязан знать кишки, т.е. что деструктор нода разрушает элемент

Получается, что ты ничерта не понял. Дерево — это интрузивный контейнер в данном случае.

I>Вот такие решения и создают проблемы на ровном месте

Дадададд, там же УКАЗАТЕЛИ!! Галактеко опасносте!

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

L>Ты продолжаешь показывать свое чудовищное непонимание вопроса. Тебе точно не стоит собеседовать кандидатов на C++.
L>"New не будет" означает, что сущность, ответственная за корректное удаление некоего объекта, его сама не создает. Этот объест ей передается в полное владение извне, в конструкторе. Сам же объект создается, к примеру, в фабрике.

Это ж целая инфраструктура и только для того, что бы правильно работать с указателями ...

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

ТКС>>GC не обеспечивает своевременное удаление объектов из памяти.

G>Что значит своевременное?

А что, кому-то из контекста обсуждения это не понятно? Если речь идет об управлении внешними ресурсами (а именно об этом речь и идет), то "своевременно" означает "немедленно".