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

I>>>Естественно, капитан, в понимании С++ нет никакого GC

ТКС>>Вообще-то есть. Некоторые их даже применяли.

I>Ты про МС++ что ли ? Или про возможность написания квази-gc под нативнй с++ ?

Естественно, про С++.

I> Естественно, и то и то это отстой.

GC вообще отстой. Толку на три копейки, издержек на рубль.


I>>>Такие вещи и нужно продумывать отдельно. Не все сводится к удалению, закрытию и тд. Это только малая часть ворклфоу.

ТКС>>Неа. В плюсах управление ресурсами легко прибить гвоздями к управлению временем жизни объектов и нет ни одной причины, чтобы разделять их.

I>Вероятно удаление файла у тебя выглядит так:
I>

I>DeleteFile(string fileName)
I>{
I>  DeleteFileOperation operation(fileName);

I>  // в деструкторе будет удаление файла прибитое гвоздями к управлению жизни объекта DeleteFileOperation
I>} 
I>

I>

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


I>>>В с++ никто не напишет за тебя корректный воркфлоу, а совмещение _некоторых_ действий с управлением памяти ничего существенно не меняет.

ТКС>>Не "некоторых действий", а всего управления внешними ресурсами.

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

А чего тебе непонятно? Что файл в деструкторе закрывать уместно или что?


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

ТКС>>Т.е., ты хочешь сказать, что RAII не работает и указанное тобой невозможно реализовать средствами RAII?

I>Представь себе xml-конфиг где прописывается сценарий работы с ресурсом...

Сценарии в xml прописывать — жосткий мазохизм, для подобных целей есть языки и поудобнее

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


I>Для управления внешними ресурсами есть IDisposable и это не имеет отношения к GC.

Кстати, как по мне, IDisposable гораздо удобнее в плане читабельности кода(_чужого_), чем какие-то там скрытые ссылки на внешние ресурсы внутри классов, которые неявно открываются, и столь же неявно закрываются. Смотришь на код — и точно видишь, что есть внешний ресурс, и видишь его цикл жизни явно. А не какой-нибудь класс blablaFile, который на деле может вообще оказаться сущностью в памяти, и не содержать в себе ссылки на системный ресурс.

PS жду не дождусь, когда в жабе такое же сделают. Бо конструкции try-finally ну черезчур громоздкие.

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

ТКС>GC вообще отстой. Толку на три копейки, издержек на рубль.

Зато есть алгоритмы которые рвут с++ именно за счет ГЦ. Да-да.

I>>>>Такие вещи и нужно продумывать отдельно. Не все сводится к удалению, закрытию и тд. Это только малая часть ворклфоу.

ТКС>>>Неа. В плюсах управление ресурсами легко прибить гвоздями к управлению временем жизни объектов и нет ни одной причины, чтобы разделять их.

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

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

ТКС>>>Не "некоторых действий", а всего управления внешними ресурсами.

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

ТКС>А чего тебе непонятно? Что файл в деструкторе закрывать уместно или что?

Вот пример:
"удаления файла из пекаджа который представляет собой простой зип"

Жду примера кода.

I>>Представь себе xml-конфиг где прописывается сценарий работы с ресурсом...

ТКС>Сценарии в xml прописывать — жосткий мазохизм, для подобных целей есть языки и поудобнее

Ты скромно ушел от ответа.

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

E__>Кстати, как по мне, IDisposable гораздо удобнее в плане читабельности кода(_чужого_), чем какие-то там скрытые ссылки на внешние ресурсы внутри классов, которые неявно открываются, и столь же неявно закрываются. Смотришь на код — и точно видишь, что есть внешний ресурс, и видишь его цикл жизни явно. А не какой-нибудь класс blablaFile, который на деле может вообще оказаться сущностью в памяти, и не содержать в себе ссылки на системный ресурс.

E__>PS жду не дождусь, когда в жабе такое же сделают. Бо конструкции try-finally ну черезчур громоздкие.

Да ладно, ты просто не понимаешь ни указателей ни деструктров и вообще ты боишься с++

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

I>>>Это только краткосрочный вариант. Я чет смотрю, конторы которые заманивают топовыми ЗП, очень быстро дохнут.
_>>Ну не знаю. Есть знакомые в ms, sap некоторых других достаточно больших компаниях, на условия не жалуются да и конторы живее всех живых.

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

I>>>Это что же, ты отказываешься от мега-способа — заваливания деньгами ?
_>>Я? Не, просто предлагаю один из вариантов ликвидировать недостаток специалистов. Но деньги имхо дадут более надежный результат

I>Наоборот, в долгосрочной перспективе это самый ненадёжный. Сдёрнуть с места можно, а сформировать команду уже сильно вряд ли. Обучение даёт гораздо бОльший выхлоп не только с С++.
Смотря для чего. Достаточно типичный стартап: относительно высокие зарплаты и перспективы послепродажного навара позволяют собрать хороших спецев которые за пару тройку лет доводят проект до продажного состояния. Потом продались, деньги поделили и разбежались или новый стартап замутили.
Вы выходит рецепт знаете? Чего плакать-то на бестолковость кандидатов в команду? Отбирайте наиболее обучаемых и вперед.

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

I>Указатель и ссылка это две большие разницы.
Даааа. Ссылка это сахар над указателем. Вот и вся разница.

I>Ссылка это просто возможность работать с конкретным объектом.
Надо полагать что ты считаешь что тут в отличие от указателя к объекту доступ осуществляется не по адресу а путём божественного вмешательства.

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

M>А что GC, по-твоему, делает с точки зрения программиста?
Это другой подход к аллокации и освобождению памяти, только и всего.

M> ВНЕЗАПНО упрощает управление временем жизни объекта.
Там вообще другой подход к времени жизни объекта чем в не-GC аллокации.
Сравнивать GC и RAII обёртки как то странно, они из разных опер.

M> Уменьшает рукопашную.
Ну дык все автоматизированные методы работы с памятью уменьшают рукопашную. Их жеж для того и делают.
Впрочем с GC рукопашной кое где становится даже больше, например там, где надо заpinить область памяти, дабы не дать GC её переместить.

M> Но GC — это зло, а вот все остальное — это добро, агаага
Нет, почему?
GC для одних целей хорош, другие способы работы с памятью — для других.

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

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

ТКС>>В языках с GC все эти действия приходится продумывать отдельно от управления памятью. Сложно назвать это упрощением.
M>Расскажи мне, что происходит при вызове delete на shared_ptr, например?
Эм. На shared_ptr delete никто не зовёт.

M>Что в языках с GC что без GC надо достаточно строго следить за внешними к программе ресурсами — файлами, сокетами и т.п.
В C++ для этого используют всё тот же RAII, который обеспечивает закрытие всех необходимых внешних ресурсов в тот самый момент когда удаляется держащий их объект.

M>которые обеспечивают ровно то, что обеспечивает GC — своевременное удаление этих объектов из памяти.
GC объект удалит из памяти только при ближайшей сборке мусора. Которая еще хз когда произойдёт. Какое тут ещё своевременное?

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

L>>Математики пусть алгоритмы на доске мелком рисуют. писать программы должны программисты.
I>Многи ли ты можешь назвать специалистов по теории доминирования которые занимаются этим лет 15-20 ? Выбирать, как видишь, не из чего.
В такой ситуации правильный подход такой: математики пишут какой то алгоритм, который они у себя доводят до работающего состояния. Затем по этому алгоритму нормальными программерами пишется код для production.
А пускать их говнокод сразу в prodution это ССЗБ.

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

I>>>Куда деть такой код?
BBI>>Зависит от качества кода. Хороший в реюз. Плохой или чинить или выкинуть.

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

Ок. Тогда сесть и итерационно отрефакторить с прогоном regression tests после каждой итерации. Выйдет всё одно дешевле в долгосрочной перспективе.
Если код действительно ключевой то его принципы работы должен понимать хотя бы один человек в конторе, он должен находится в состоянии, когда его можно развивать и поддерживать. Иначе проект неминуемо скатится в говно.

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

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

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

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

I>Скучные у тебя аргументы, смотри сюда, классика жанра:
I>

I>IComObject *pObj = ... ;
I>void **pUnknown = NULL;

pObj->>QueryInterface(IID_IUnknown, temp);
I>

I>Тебе объяснить, где тут ошибка ?
В том что переменная temp не объявлена?

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

I>Ссылка никак не относится к адресам. Указатель это именно номер байта в АП, то есть, самый что ни есть, адрес и отсюда следует адресная арифметика и тд.
Скажи, а как происходит обращение к объекту по ссылке? Как его находят, если по-твоему в ссылке в отличие от указателя адреса нету?

I>Из твоей формулировки как раз и следует непонимание ссылок.
Судя по всему это ты не понимаешь.

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

ТКС>>GC вообще отстой. Толку на три копейки, издержек на рубль.
I>Зато есть алгоритмы которые рвут с++ именно за счет ГЦ. Да-да.
Померяемся? Уже как то оказалось что GC медленнее чем native аллокация.

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

S>Эй, осторожнее. В местных специальных олимпиадах я лидирую!
S>

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

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

ТКС>>GC вообще отстой. Толку на три копейки, издержек на рубль.

I>Зато есть алгоритмы которые рвут с++ именно за счет ГЦ. Да-да.

Да кто бы сомневался. Только не плюсы вообще, а хип. Если память в хипе слишком часто выделять, конечно GC окажется быстрее. Только 1) такие ситуации довольно редки 2) это всегда или почти всегда можно обойти.

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

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

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


I>Вот пример:
I>"удаления файла из пекаджа который представляет собой простой зип"

I>Жду примера кода.

Я не вполне понимаю, что именно ты хочешь увидеть. Поэтому жду примера кода на C#, потом представлю аналог на плюсах.


I>>>Представь себе xml-конфиг где прописывается сценарий работы с ресурсом...

ТКС>>Сценарии в xml прописывать — жосткий мазохизм, для подобных целей есть языки и поудобнее

I>Ты скромно ушел от ответа.

Нет, это ты забыл вопрос сформулировать.

Здравствуйте, Ночной Смотрящий, Вы писали:

S>>Эй, осторожнее. В местных специальных олимпиадах я лидирую!
S>>

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

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

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

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

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

Это не легаси. Определение легаси я давал в другом посте. То, что ты нам тут приводишь как пример легаси, нормальные люди относят к категории "говнокод обыкновенный".

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

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

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

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

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

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

Вот именно. Это нормальный инженерный процесс.

BBI>А пускать их говнокод сразу в prodution это ССЗБ.

плюс стопицот.

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

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

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

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

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