Здравствуйте, alexey_ma, Вы писали:
_>Мне-то зачем что-то представлять? Это Вы тут пытаетесь напугать сообщество ужасными голыми указателями.
Я никого не пугаю, а говорю то, с чем пришлось сталкиваться копаясь в древних проектах писаными кем попало.
>Вот и подгоняйте достоверные примеры неуловимых багов на указателях. Лично меня убеждать не нужно, я и так знаю с какими реальными багами приходится сталкиваться, и неправильная инициализация указателя вообще не входит в список часто встречающихся и трудно уловимых. Вы ж упорно пытаетесь убедить меня в обратном тупым примером.
"убедить меня в обратном" — чушь. Я привел простейший пример для демонстрации проблемы.
>Никто не говорит что проблемы польностью отсутствуют.
Да ладно, тут двое утверждают что багов не бывает годами и что де проблема не в указателях а в руках Кому из вас верить ?
Здравствуйте, Mamut, Вы писали:
_>>Прямой доступ к памяти это преимущество с/c++, причем иногда абсолютно необходимое.
M>Преимущество по сравнению с чем?
С языками которые этого не позволяют.
_>>>Прямой доступ к памяти это преимущество с/c++, причем иногда абсолютно необходимое.
M>>Преимущество по сравнению с чем? _>С языками которые этого не позволяют.
Здравствуйте, landerhigh, Вы писали:
L>>>Нет такого класса багов. В принципе. Указатель — это просто число, накосячить с ним не просто.
I>>Очень просто, чисто для демонстрации: I>>
I>>char *p;
I>>strcpy(p,src);
I>>
L>Бага с указателем не видно. Видно баг в /dev/brain и отовсюду торчат кривые hands.sys
д'Артаньян детектед
L>Не говоря уже о том, что сейчас делают так
L>
L>std::string dst(pSrc);
L>
Сколько тебе понадобится времени, что бы в древнем проекте 50-100мб пофиксить строки и прикрутить std:string ?
I>>Не надо там пытаться. Пример не сложнее предыдущего. L>В моей команде тебе придется на уши встать и гопака на потолке станцевать, чтобы что-то отдаленно напоминающее приведенный выше прикол прошел код ревью.
Если ваша команда работает только со своим кодом, то так и будет. А совсем недавно товарищу пришел убитый проект на лялих++... Надо продолжать ?
?
L>Несмотря на то, что std::string называть умным указателем это несколько неортодоксально, но разве кто-то возражает?
Ну, я возражаю против утверждений типа «почти никогда не видел в С++ проблем с указателями». Если не видел, обычно это значит, что используются любые средства, лишь бы таки не использовать эти самые указатели
I>Я никого не пугаю, а говорю то, с чем пришлось сталкиваться копаясь в древних проектах писаными кем попало.
Язык и библиотеки на месте не стоят. Древние проекты не показатель имхо. >>Вот и подгоняйте достоверные примеры неуловимых багов на указателях. Лично меня убеждать не нужно, я и так знаю с какими реальными багами приходится сталкиваться, и неправильная инициализация указателя вообще не входит в список часто встречающихся и трудно уловимых. Вы ж упорно пытаетесь убедить меня в обратном тупым примером.
I>"убедить меня в обратном" — чушь. Я привел простейший пример для демонстрации проблемы.
>>Никто не говорит что проблемы польностью отсутствуют.
I>Да ладно, тут двое утверждают что багов не бывает годами и что де проблема не в указателях а в руках Кому из вас верить ?
В данном случае можете верить обоим. Большинство багов на свете происходят по причине либо кривых рук либо кривых мозгов. Ваш кэп. Я вполне могу поверить что в плюсовом проекте годами может не быть багов связанных с памятью.
Здравствуйте, Mamut, Вы писали:
M>Голословно. В чем это преимущество выражается?
Сдается мне, когда говорят о прямом доступе к памяти, подразумевают старые добрые времена, реальный режим, MS DOS, Turbo C 2.0. В MS DOS прямой доступ к памяти использовался постоянно. Кто в DOS не писал окошки, ставя указатель на видеопамять, предварительно проверив текущий видеорежим. Работало на порядки быстрее, чем через BIOS. Или проверить буфер клавиатуры и вообще область данных BIOS.
Но с тех пор, как я начал программировать под Винду, прямой доступ к памяти мне ни разу не понадобился.
Здравствуйте, Mamut, Вы писали:
L>>Несмотря на то, что std::string называть умным указателем это несколько неортодоксально, но разве кто-то возражает?
M>Ну, я возражаю против утверждений типа «почти никогда не видел в С++ проблем с указателями». Если не видел, обычно это значит, что используются любые средства, лишь бы таки не использовать эти самые указатели
Не совсем так. Используется устройство /dev/brain для определения правил владения объектами, их временем жизни и видимостью. Динамически создается только то, что должно создаваться динамически, а умные указатели используются для автоматического контроля временем жизни подобных объектов. Причем практически только в случаях совместного владения или когда владение должно передаваться, в остальных случаях достаточно RAII.
Здравствуйте, alexey_ma, Вы писали:
I>>Я никого не пугаю, а говорю то, с чем пришлось сталкиваться копаясь в древних проектах писаными кем попало. _>Язык и библиотеки на месте не стоят. Древние проекты не показатель имхо.
Чисто между прочим, ты в курсе, что старого кода на порядки больше чем нового и от него никто не собирается отказываться ?
I>>Да ладно, тут двое утверждают что багов не бывает годами и что де проблема не в указателях а в руках Кому из вас верить ? _>В данном случае можете верить обоим. Большинство багов на свете происходят по причине либо кривых рук либо кривых мозгов. Ваш кэп.
Все баги происходят по причине человеческого фактора. Вообще все. Потому когда речь про проблемы вроде с указателями, очевидно, имеется ввиду зависимость от этого ЧФ, которая у указателей много выше, чем с другими механизмами вроде ссылок.
Это следует из того, что одни и те же люди не могут заставить взлететь проект на С++ хотя менеджед версия летает.
Здравствуйте, Mamut, Вы писали:
_>>>>Прямой доступ к памяти это преимущество с/c++, причем иногда абсолютно необходимое.
M>>>Преимущество по сравнению с чем? _>>С языками которые этого не позволяют.
M>Голословно. В чем это преимущество выражается?
Очевидно что иногда бывает сильно нужно пошарить по памяти: Как обратиться в внешнему Grid`у через API
L>>>Несмотря на то, что std::string называть умным указателем это несколько неортодоксально, но разве кто-то возражает?
M>>Ну, я возражаю против утверждений типа «почти никогда не видел в С++ проблем с указателями». Если не видел, обычно это значит, что используются любые средства, лишь бы таки не использовать эти самые указатели
L>Не совсем так. Используется устройство /dev/brain для определения правил владения объектами, их временем жизни и видимостью.
Ну это нужно вне зависимости от языка
L>Динамически создается только то, что должно создаваться динамически, а умные указатели используются для автоматического контроля временем жизни подобных объектов.
Ну дык GC для бедных
L>Причем практически только в случаях совместного владения или когда владение должно передаваться, в остальных случаях достаточно RAII.
Здравствуйте, Ikemefula, Вы писали:
L>>Бага с указателем не видно. Видно баг в /dev/brain и отовсюду торчат кривые hands.sys
I>д'Артаньян детектед
То есть по поводу кривых рук возражений не будет?
L>>Не говоря уже о том, что сейчас делают так
L>>
L>>std::string dst(pSrc);
L>>
I>Сколько тебе понадобится времени, что бы в древнем проекте 50-100мб пофиксить строки и прикрутить std:string ?
Опять сферический код в вакууме? Если это древний проект и он дожил до наших дней, то он стабилен и работает, и в этом случае ничего к нему прикручивать не надо. Максимум починить некритические баги. Если же в нем баг на баге, то он был отправлен в помойку стопицот лет назад и к нему тоже ничего прикручивать не надо.
I>>>Не надо там пытаться. Пример не сложнее предыдущего. L>>В моей команде тебе придется на уши встать и гопака на потолке станцевать, чтобы что-то отдаленно напоминающее приведенный выше прикол прошел код ревью.
I>Если ваша команда работает только со своим кодом, то так и будет. А совсем недавно товарищу пришел убитый проект на лялих++... Надо продолжать ?
Судя по тому, что тебе, по всей видимости, указатели снятся в кошмарах, тебе лучше не спрашивать, чем моя команда занимается. Можешь повторить шутку про Дартаньяна
_>>>>>Прямой доступ к памяти это преимущество с/c++, причем иногда абсолютно необходимое.
M>>>>Преимущество по сравнению с чем? _>>>С языками которые этого не позволяют.
M>>Голословно. В чем это преимущество выражается? _>Очевидно что иногда бывает сильно нужно пошарить по памяти: _>Как обратиться в внешнему Grid`у через API
Очевидно, что это — неочевидно. И учитывая, что тут работа с COM, это является весьма специфичной задачей. Назвать это именно преимуществом над другими языками у меня рука не поднимается. Так, чпособ решить костыли другими костылями
Здравствуйте, landerhigh, Вы писали:
I>>Сколько тебе понадобится времени, что бы в древнем проекте 50-100мб пофиксить строки и прикрутить std:string ?
L>Опять сферический код в вакууме? Если это древний проект и он дожил до наших дней, то он стабилен и работает, и в этом случае ничего к нему прикручивать не надо. Максимум починить некритические баги. Если же в нем баг на баге, то он был отправлен в помойку стопицот лет назад и к нему тоже ничего прикручивать не надо.
Неправильно. Если он дожил, значит бюджет позволял жить. Рано или поздно это прекратится.
I>>Если ваша команда работает только со своим кодом, то так и будет. А совсем недавно товарищу пришел убитый проект на лялих++... Надо продолжать ?
L>Судя по тому, что тебе, по всей видимости, указатели снятся в кошмарах, тебе лучше не спрашивать, чем моя команда занимается. Можешь повторить шутку про Дартаньяна
Стало быть про убитый проект на лялих++ возражений нет. На том и закончим.
Здравствуйте, Ikemefula, Вы писали:
I>Все баги происходят по причине человеческого фактора. Вообще все. Потому когда речь про проблемы вроде с указателями, очевидно, имеется ввиду зависимость от этого ЧФ, которая у указателей много выше, чем с другими механизмами вроде ссылок.
Спасибо кэп Вам это и пытаются втолковать, что борьба с человеческим фактором может заключаться не только в переходе на управляемые языки но и использовании более безопасных техник на неуправляемых, как то применения умные указатели, разумные coding conventions и т.п. I>Это следует из того, что одни и те же люди не могут заставить взлететь проект на С++ хотя менеджед версия летает.
Это в первую очередь говорит о том что скорее всего и персонал и язык для проекта подобраны не правильно. И опять хочется примеров чего это такого удалось на менеджед сделать и не удалось на плюсах.
M>Очевидно, что это — неочевидно. И учитывая, что тут работа с COM, это является весьма специфичной задачей. Назвать это именно преимуществом над другими языками у меня рука не поднимается. Так, чпособ решить костыли другими костылями
И чего мне делать-то если у клиента его апликация использует грид или rоt? Обьяснять ему что он лошара и должен весь свой софт немедленно на java переписать? Так ведь пошлет и денег не даст. Именно такие специфические задачи и требуют сответствующего инструмента. И С/C++ позволяет такие задачи решать достаточно быстро и эффективно в отличии от других языков.
Здравствуйте, alexey_ma, Вы писали:
I>>Все баги происходят по причине человеческого фактора. Вообще все. Потому когда речь про проблемы вроде с указателями, очевидно, имеется ввиду зависимость от этого ЧФ, которая у указателей много выше, чем с другими механизмами вроде ссылок. _>Спасибо кэп Вам это и пытаются втолковать, что борьба с человеческим фактором может заключаться не только в переходе на управляемые языки но и использовании более безопасных техник на неуправляемых, как то применения умные указатели, разумные coding conventions и т.п.
Начнем сначала. Сколько нужно времени что бы старом проекте на 50-100мб кода заменить указатели на смартпоинтеры и тд.
I>>Это следует из того, что одни и те же люди не могут заставить взлететь проект на С++ хотя менеджед версия летает. _>Это в первую очередь говорит о том что скорее всего и персонал и язык для проекта подобраны не правильно. И опять хочется примеров чего это такого удалось на менеджед сделать и не удалось на плюсах.
такое ощущение что большинство адептов С++ в этом топике не в курсе про legacy код. раньше на с++ писалось очень много того, что сейчас пишется на менеджед средствах. Куда деть такой код ? Может назвать его несиплюсным ? это резко снимет проблему указателей