Здравствуйте, 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 прописывать — жосткий мазохизм, для подобных целей есть языки и поудобнее
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
I>Для управления внешними ресурсами есть IDisposable и это не имеет отношения к GC.
Кстати, как по мне, IDisposable гораздо удобнее в плане читабельности кода(_чужого_), чем какие-то там скрытые ссылки на внешние ресурсы внутри классов, которые неявно открываются, и столь же неявно закрываются. Смотришь на код — и точно видишь, что есть внешний ресурс, и видишь его цикл жизни явно. А не какой-нибудь класс blablaFile, который на деле может вообще оказаться сущностью в памяти, и не содержать в себе ссылки на системный ресурс.
PS жду не дождусь, когда в жабе такое же сделают. Бо конструкции try-finally ну черезчур громоздкие.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Тот кто сидит в пруду, Вы писали:
ТКС>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>Ссылка это просто возможность работать с конкретным объектом.
Надо полагать что ты считаешь что тут в отличие от указателя к объекту доступ осуществляется не по адресу а путём божественного вмешательства.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Mamut, Вы писали:
M>А что GC, по-твоему, делает с точки зрения программиста?
Это другой подход к аллокации и освобождению памяти, только и всего.
M> ВНЕЗАПНО упрощает управление временем жизни объекта.
Там вообще другой подход к времени жизни объекта чем в не-GC аллокации.
Сравнивать GC и RAII обёртки как то странно, они из разных опер.
M> Уменьшает рукопашную.
Ну дык все автоматизированные методы работы с памятью уменьшают рукопашную. Их жеж для того и делают.
Впрочем с GC рукопашной кое где становится даже больше, например там, где надо заpinить область памяти, дабы не дать GC её переместить.
M> Но GC — это зло, а вот все остальное — это добро, агаага
Нет, почему?
GC для одних целей хорош, другие способы работы с памятью — для других.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Mamut, Вы писали:
M>Да не надо рассказывать сказки. Тут рядом, например, Шеридан показывает, как он это понимает, ага.
Ну ты конечно выбрал кого брать в пример. Ты например Кодта бери, он кошернее.
ТКС>>В языках с GC все эти действия приходится продумывать отдельно от управления памятью. Сложно назвать это упрощением. M>Расскажи мне, что происходит при вызове delete на shared_ptr, например?
Эм. На shared_ptr delete никто не зовёт.
M>Что в языках с GC что без GC надо достаточно строго следить за внешними к программе ресурсами — файлами, сокетами и т.п.
В C++ для этого используют всё тот же RAII, который обеспечивает закрытие всех необходимых внешних ресурсов в тот самый момент когда удаляется держащий их объект.
M>которые обеспечивают ровно то, что обеспечивает GC — своевременное удаление этих объектов из памяти.
GC объект удалит из памяти только при ближайшей сборке мусора. Которая еще хз когда произойдёт. Какое тут ещё своевременное?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ikemefula, Вы писали:
L>>Математики пусть алгоритмы на доске мелком рисуют. писать программы должны программисты. I>Многи ли ты можешь назвать специалистов по теории доминирования которые занимаются этим лет 15-20 ? Выбирать, как видишь, не из чего.
В такой ситуации правильный подход такой: математики пишут какой то алгоритм, который они у себя доводят до работающего состояния. Затем по этому алгоритму нормальными программерами пишется код для production.
А пускать их говнокод сразу в prodution это ССЗБ.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ikemefula, Вы писали:
I>>>Куда деть такой код? BBI>>Зависит от качества кода. Хороший в реюз. Плохой или чинить или выкинуть.
I>Выкинуть как правило слишком дорого. Например потому, что код писал некото с большим матбеграундом и большими способностями запоминать неструктурированый код. Ему было легко работать с простынями в 100кб и более . Этот код работает, более того, является ключевым. I>Что бы его переписать, нужен точно такой же специалист, а это как правило всегда проблема.
Ок. Тогда сесть и итерационно отрефакторить с прогоном regression tests после каждой итерации. Выйдет всё одно дешевле в долгосрочной перспективе.
Если код действительно ключевой то его принципы работы должен понимать хотя бы один человек в конторе, он должен находится в состоянии, когда его можно развивать и поддерживать. Иначе проект неминуемо скатится в говно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ikemefula, Вы писали:
I>>>Показал. вам, сиплюсникам, надо определиться. Или проблем с указателями нет, тогда не ясно зачем вам valgrind, или... L>>Если ты не сиплюсплюсник, то что ты к указателям прицепился?
I>Я занимаюсь в т.ч. набором
А, ну теперь понятно почему у вас нормальных С++сников нету.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ikemefula, Вы писали:
I>Ссылка никак не относится к адресам. Указатель это именно номер байта в АП, то есть, самый что ни есть, адрес и отсюда следует адресная арифметика и тд.
Скажи, а как происходит обращение к объекту по ссылке? Как его находят, если по-твоему в ссылке в отличие от указателя адреса нету?
I>Из твоей формулировки как раз и следует непонимание ссылок.
Судя по всему это ты не понимаешь.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ikemefula, Вы писали:
ТКС>>GC вообще отстой. Толку на три копейки, издержек на рубль. I>Зато есть алгоритмы которые рвут с++ именно за счет ГЦ. Да-да.
Померяемся? Уже как то оказалось что GC медленнее чем native аллокация.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ikemefula, Вы писали:
ТКС>>GC вообще отстой. Толку на три копейки, издержек на рубль.
I>Зато есть алгоритмы которые рвут с++ именно за счет ГЦ. Да-да.
Да кто бы сомневался. Только не плюсы вообще, а хип. Если память в хипе слишком часто выделять, конечно GC окажется быстрее. Только 1) такие ситуации довольно редки 2) это всегда или почти всегда можно обойти.
ТКС>>Ты, я гляжу, не вполне понимаешь, что является внешним ресурсом. Поэтому поясню — операция удаления файла ресурсом не является. Вследствии чего никакой необходимости заводить класс DeleteFileOperation, в деструкторе которого удаляется файл, нету, и предложенный тобой код является полнейшим идиотизмом.
I>Зато файл является внешним ресурсом, а у тебя сказано "легко прибить гвоздями к управлению временем жизни объектов и нет ни одной причины, чтобы разделять их". I>Раз причин разделять нет, то удаление файла должно делаться в деструкторе какого то класса.
Конечно. Если у тебя есть объект, соотвествующий файлу. Для временных файлов это вполне нормальное решение. Если же у тебя такого объекта нет, то придумывать его тоже нет причин. Соответственно, и прибивать гвоздями нечего.
I>Вот пример: I>"удаления файла из пекаджа который представляет собой простой зип"
I>Жду примера кода.
Я не вполне понимаю, что именно ты хочешь увидеть. Поэтому жду примера кода на C#, потом представлю аналог на плюсах.
I>>>Представь себе xml-конфиг где прописывается сценарий работы с ресурсом...
ТКС>>Сценарии в xml прописывать — жосткий мазохизм, для подобных целей есть языки и поудобнее
I>Ты скромно ушел от ответа.
Нет, это ты забыл вопрос сформулировать.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Ночной Смотрящий, Вы писали:
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>Это ж целая инфраструктура и только для того, что бы правильно работать с указателями ...
Ты серьезно ничего не понял или придуриваешься?
Я тебе на пальцах только что описал архитектуру одного модуля системы с пояснениями, а ты увидел только указатели. Это уже комплекс.