Здравствуйте, n-839, Вы писали:
N8>Здравствуйте, Glоbus, Вы писали:
G>>Да все нормально с авто поинтером
N8>Я погорячился, прошу прощения. N8>Во-первых, не Саттер с Александреску, а Мейерс — из-за местами пересекающихся материалов в их книгах я часто путаю, кто и что именно рекомендовал. N8>Во-вторых, не auto_ptr сам по себе зло, а контейнеры, содержащие auto_ptr. N8>Мейерс, "Эффективное использование STL", Совет 8: "Никогда не создавайте контейнеры, содержащие auto_ptr".
N8>Как я понимаю, все зависит от задачи
Чорд, как вообще можно додуматься до контейнера с auto_ptr<>? В любой книжке же сказано, что при копировании передает владение объектом этот самый auto_ptr<>. То есть при большинстве манипуляциях с контейнером, его элементы auto_ptr<> превратятся в черт знает что, точнее указывать они будут в ж..у. А придуман auto_ptr, если склероз не изменяет, для передачи параметров в функции.
Здравствуйте, мыщъх, Вы писали: М>я там выделил куда клоню. погуглите. а теперь представим, что в деструктор мы впихнули что-то более важное, чем освобождение памяти. кстати, со стека объект удалят со свистом и без деструкторов. то есть зачем нужен деструктор вы похоже таки не понимаете
Полностью согласен. Всегда утверждал, что автосборка мусора — не более, чем пиар, и в целом она для мало-мальски ответственных объектов проблему не решает, откуда и берется IDisposable в .Net (а значит, мы вообще-то для каждого создаваемого объекта в должны задумываться, а не поддерживает ли он или не будет ли потом поддерживать — если это объект из нашего кода — интерфейс IDisposable). Обязанности конструктуров и деструкторов далеко выходят за рамки банального освобождения памяти, эти-то действия даже и на куче вполне можно штатными функциями выделения памяти осуществить =)
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Здравствуйте, egaron, Вы писали:
E>5 лет меня учили в институте решать математические задачки и дифуры — блин, помню только как берется производная от много(стесняюсь сказать)члена
E>помнится-то то, чем все время занимаешься, остальное уходит в бэкграунд. сколько я ни учил интерфейс IDisposable хоть и понять-то там все понял (чего там не понимать), но так, с ходу ,вдруг — не воспроизведу. ибо на работе приходилосаь его реализовывать раз или два. поэтому перед собесами приходится "переучивать"... то же и с деструкторами.
Ну тогда не надо писать в резюме "5 лет работы с IDisposable". Ведь проблема в том, что люди приходят я говорят о годах опыта, а на самом деле это означает "сегодня — дата знакомства с предметом". Если человеку больше 30, он около 10 лет "работал" с с++ и говорит, что не помнит зачем нужен виртуальный деструктор — я считаю, что он 10 лет программировал на с++ каждый день и ни разу не прочёл книжку по азам и моё право с ним после этого распрощаться. Почему меня должно волновать какие у него были мотивации и условия. Я беру человека выполнять определённую работу не планирую проверять поставил ли он virtual перед деструктором.
И ещё я видел какие решения изобретают программисты, не знающие хорошо свой инструмент (язык). Оверхед измеряется в сотнях строк.
Здравствуйте, leonty, Вы писали:
L>Ну тогда не надо писать в резюме "5 лет работы с IDisposable". Ведь проблема в том, что люди приходят я говорят о годах опыта, а на самом деле это означает "сегодня — дата знакомства с предметом". Если человеку больше 30, он около 10 лет "работал" с с++ и говорит, что не помнит зачем нужен виртуальный деструктор — я считаю, что он 10 лет программировал на с++ каждый день и ни разу не прочёл книжку по азам и моё право с ним после этого распрощаться.
Кстати тоже вариант — давайте будем честными.
Будем писать в резюме не "опыт работы N лет с языком программирования Z", а "N лет поддержки гавно-кода с багфиксингом и внедрением новых фич "которые уже вчера нужны, ;%::?*!".
Интересно сколько резюме при таком подхоже превратятся их конфетки в откровенное говно.
А я и сам при таком раскладе выгляжу как говно, ибо в новые проджекты редко судьба забрасывала, все больше "развить, доделать, пофисит, прикрутить, обновить".
Жизнь отматывает время, а IT с виртуальными деструкторами пролетает мимо меня, чорт.
Здравствуйте, Denwer, Вы писали:
D>Последние два месяца прорезюмировал просто толпу соискателей на программистов по с++. Каково было мое удивление что 90% людей не знаю ДЛЯ ЧЕГО НУЖЕН ВИРТУАЛЬНЫЙ ДЕСТРУКТОР. Как такое может быть? Куда делись настоящие программситы, а не оходники за деньгами? Что творится с людьми?
Здравствуйте, avishnyakov, Вы писали:
A>Кстати тоже вариант — давайте будем честными. A>Будем писать в резюме не "опыт работы N лет с языком программирования Z", а "N лет поддержки гавно-кода с багфиксингом и внедрением новых фич "которые уже вчера нужны, ;%::?*!".
Одна из самых сложных задач, сопровождение и модификация унаследованного кода. Обычно если вы не в состоянии постепенно выравнивать любого качества код , вы и новый не можете писать.
Здравствуйте, minorlogic, Вы писали:
M>Одна из самых сложных задач, сопровождение и модификация унаследованного кода. Обычно если вы не в состоянии постепенно выравнивать любого качества код , вы и новый не можете писать.
Здравствуйте, avishnyakov, Вы писали:
A>Здравствуйте, minorlogic, Вы писали:
M>>Одна из самых сложных задач, сопровождение и модификация унаследованного кода. Обычно если вы не в состоянии постепенно выравнивать любого качества код , вы и новый не можете писать.
A>Слишком идеализированно.
Наоборот, очень прагматично. Готов поспорить, если человек сапортил код и жалуется что код плохой , и сапортить его очень тяжело , и становится только хуже он очень плохой програмист.
Редко когда именно написание кода занимает даже 25% времени, в основном это обдумывание алгоритмов, предметной области , подходов к решению и декомпозиции . А навыки базового структурирования и т.п. у хорошего спеца должны быть уже рефлекторными.
Здравствуйте, minorlogic, Вы писали:
M>Наоборот, очень прагматично. Готов поспорить, если человек сапортил код и жалуется что код плохой , и сапортить его очень тяжело , и становится только хуже он очень плохой програмист.
Ради интереса, есть какой то опыт саппортинга/внедрения новых фич?
Впрочем, проекты и код слишком разные, что бы отвечать на этот вопрос коротким "да/нет", как и спорить по выше написанному утверждению.
Здравствуйте, avishnyakov, Вы писали:
A>Ради интереса, есть какой то опыт саппортинга/внедрения новых фич? A>Впрочем, проекты и код слишком разные, что бы отвечать на этот вопрос коротким "да/нет", как и спорить по выше написанному утверждению.
Здравствуйте, minorlogic, Вы писали:
M>Наоборот, очень прагматично. Готов поспорить, если человек сапортил код и жалуется что код плохой , и сапортить его очень тяжело , и становится только хуже он очень плохой програмист.
лучше не надо, проспорите. Бывает так что начальство предпочитает постоянно набирать/выгонять "студентов", а паре постоянных программистов постоянно приходиться это править.
Здравствуйте, jhfrek, Вы писали:
J>лучше не надо, проспорите. Бывает так что начальство предпочитает постоянно набирать/выгонять "студентов", а паре постоянных программистов постоянно приходиться это править.
Если я должен был увидеть противоречие или контраргумент, то не увидел. Расшифруйте.
Здравствуйте, minorlogic, Вы писали:
M>Наоборот, очень прагматично. Готов поспорить, если человек сапортил код и жалуется что код плохой , и сапортить его очень тяжело , и становится только хуже он очень плохой програмист. J>>лучше не надо, проспорите. Бывает так что начальство предпочитает постоянно набирать/выгонять "студентов", а паре постоянных программистов постоянно приходиться это править. M>Если я должен был увидеть противоречие или контраргумент, то не увидел. Расшифруйте.
код реально плохой и реально становится хуже из-за того что набираемые "студенты" портят его быстрее чем программист исправляет. К тому же они постоянно новые, поэтому портят по разному.
Здравствуйте, minorlogic, Вы писали:
M>Наоборот, очень прагматично. Готов поспорить, если человек сапортил код и жалуется что код плохой , и сапортить его очень тяжело , и становится только хуже он очень плохой програмист.
Ну да, раз не смог переплыть море/океан, значит программист плохой
Для написания нового код в старом проекте часто нужно изменить архитектуру/интерфейсы/структуру и тд.
А теперь представь, что продукт выставляет АПИ для клиентов. Это значит, что архитектуру/интерфейсы изменить нельзя, а структуру поменять тоже крайне сложно.
Если можно забить на обратную совместимость или можно удачно обойти, то, конечно, все можно поправить при наличии
1. времени на разработку
2. времени на тестирование,
3. чем сильнее изменения тем больше нужно тестировщиков
В любом случае просто не получается. Как правило код пишется коммандой/коммандами, а суппортится небольшим кол.вом людей.
Здравствуйте, Vzhyk, Вы писали:
>> Эволюция однако, программирование становится доступным каждому. V>Ага. И все вы видим последствия этого. Что не купишь и где есть хоть V>какая программа работает плохо.
Это так. Купил намедни Оксфордский словарь и заплатил спецально а CDROM к нему. Сейчас ищу ответственного за тот геморрой, что на диске, с целью ****** или, как минимум, нанесения ****** ******* *************.
Вроде бы почти работат, но пользоваться крайне сложно, туды его в качель.
Здравствуйте, jhfrek, Вы писали:
J>код реально плохой и реально становится хуже из-за того что набираемые "студенты" портят его быстрее чем программист исправляет. К тому же они постоянно новые, поэтому портят по разному.
J>А программист отличный.
Это другая ситуация и другие проблемы, совсем не сапорт.
Здравствуйте, Ikemefula, Вы писали:
I>Ты уверен, что этих сил достаточно для решеня любой проблемы огласно требованиям времени, бюджета, качества ?
Если этой фразе предполагается что я это утверждал, то ты ошибаешься. Перечитай
"Именно так, часто слышу подобные жалобы "да если бы не код , да я бы !!!! ". Плохому танцору .. ну вы в курсе. "
Т.е. если от сопровождения код становится хуже, это показатель непрофесионализма и доверять такому програмисту новый код не стоит. А если он ухудшения кода мотивирует качеством существующего, тогда он еще и психологически незрел.