Здравствуйте, AleksandrN, Вы писали:
N>>И фиг они чем помогут в ситуации "структуры порушены несколько минут назад совершенно другим кодом, каким — ХЗ".
AN>Тут помогут инструменты типа valgrind.
Спасибо, кэп. Но:
1. Часть проблем — да, выловят. До конца — нет, и valgrind не поможет в случае сложных ситуаций. Говорю по своему опыту.
2. Вы его видели где-то за пределами Linux? У меня сейчас всё на Linux, ok. А если кому-то таки надо под другое писать?
3. Вместо того, чтобы сначала плодить проблемы работы с памятью, а потом их ловить — причём может оказаться, что диверсант сидит в чужом проприетарном коде, и ты фиг запинаешь его авторов исправить свою ошибку — можно изначально использовать инструмент, у которого этих проблем нет.
Собственно на этом выезжают managed среды, начиная с BASIC и Java: какой бы говнокод на них не писался и не импортировался, он не доведёт обстановку до совсем нерабочего состояния, если не использовать спец. средства, которые легко детектируются. А в unmanaged — наоборот.
Здравствуйте, netch80, Вы писали:
N>Собственно на этом выезжают managed среды, начиная с BASIC и Java: какой бы говнокод на них не писался и не импортировался, он не доведёт обстановку до совсем нерабочего состояния, если не использовать спец. средства, которые легко детектируются. А в unmanaged — наоборот.
Все зашибись, конечно, только разработчики managed сред как-то выпустили из виду, что ресурсы, в общем случае, это не только память. И как только дело доходит до разного рода хэндлов системы, разработчики управляемых языков начинают выглядеть достаточно бледно, ибо организовать RAII, равнозначный плюсовому, невозможно, пользуясь недодеструкторами этих языков. Образно говря, сделали красивый памперс, но на всю попу его не хватает.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, rg45, Вы писали:
R>Все зашибись, конечно, только разработчики managed сред как-то выпустили из виду, что ресурсы, в общем случае, это не только память. И как только дело доходит до разного рода хэндлов системы, разработчики управляемых языков начинают выглядеть достаточно бледно, ибо организовать RAII, равнозначный плюсовому, невозможно, пользуясь недодеструкторами этих языков. Образно говря, сделали красивый памперс, но на всю попу его не хватает.
И еще одно важное отличие. На C++ у меня, как у разработчика какой-нибудь библиотеки, есть возможность сделать ошибку юзера невозможной (пардон за каламбур):
Здравствуйте, rg45, Вы писали:
R>И еще одно важное отличие. На C++ у меня, как у разработчика какой-нибудь библиотеки, есть возможность сделать ошибку юзера невозможной (пардон за каламбур): R>
P.S. в теории согласен с твоими доводами, но за последнии два года я на практике пришел к странному выводу. Несмотря на то, что в теории на C++ можно написать более надежный код благодаря RAII, разделяемым указателям и прочее, на Go он волшебным образом содержит меньше ошибок и проще поддерживается, пусть даже тут есть только defer.
То есть, вопрос владения/освобождения закрыт, правильно я понимаю? Переходим к другим вопросам — "дегенеративного сишного говносинтаксиса" и "невероятной переусложненности С++? Ну, дальше без меня, если можно. Я уже не единожды высказывал свою точку зрения: в каждом инструменте разработки есть свои сильные и слабые стороны и настоящий профессионал просто умеет правильно сочетать их извлекать пользу, а не устраивать холивары "какие травмы я получил, дотронувшись до шаблонов".
--
Не можешь достичь желаемого — пожелай достигнутого.
надежность работы программы на откуп кому отдана?
R>То есть, вопрос владения/освобождения закрыт, правильно я понимаю?
Ничего подобного, я говорю о том, что за пределами освобождения НЕпамяти есть гора других толком не решённых проблем. Ну а возможность забыть вызвать defer вполне сопоставима с возможностью забыть завернуть handle в умный указатель. По моим наблюдениям, не всякий программист работающий с C++ вообще знает о такой возможности.
Здравствуйте, kaa.python, Вы писали:
KP>Ничего подобного, я говорю о том, что за пределами освобождения НЕпамяти есть гора других толком не решённых проблем. Ну а возможность забыть вызвать defer вполне сопоставима с возможностью забыть завернуть handle в умный указатель. По моим наблюдениям, не всякий программист работающий с C++ вообще знает о такой возможности.
Не сопоставима. Ибо, как правило, функции и классы используются существенно большее количество раз, чем реализуются, а значит, и вероятность допустить ошибку при использовании существенно выше, чем при реализации, это во-первых. А главное, у ОПЫТНОГО разработчика C++ есть возможность недопустить некоторые грубые ошибки в исплользовании разработанных им функций и классов, а у ОПЫТНОГО разработчика Java и C# такой возможности нет.
P.S. При этом заметь, я не иду в атаку с криками "Долой C#!" и "Java — отстой!". Повторюсь: в каждом инструменте есть свои слабые и сильные стороны и нужно просто уметь их исполльзовать.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, rg45, Вы писали:
N>>Собственно на этом выезжают managed среды, начиная с BASIC и Java: какой бы говнокод на них не писался и не импортировался, он не доведёт обстановку до совсем нерабочего состояния, если не использовать спец. средства, которые легко детектируются. А в unmanaged — наоборот.
R>Все зашибись, конечно, только разработчики managed сред как-то выпустили из виду, что ресурсы, в общем случае, это не только память. И как только дело доходит до разного рода хэндлов системы, разработчики управляемых языков начинают выглядеть достаточно бледно, ибо организовать RAII, равнозначный плюсовому, невозможно, пользуясь недодеструкторами этих языков. Образно говря, сделали красивый памперс, но на всю попу его не хватает.
Я знаю. На прошлой неделе боролся с этим на питоне У CPython одна логика, у PyPy — другая, и скрестить их можно только если по-разному в них работать. Финального решения ещё не сделал, вот закончу с другой частью и вернусь к той.
Но реально получается, что через finally можно побороться с заметной частью этих случаев, через слабые ссылки — с другой, через явные деструкторы — с третьей, и в подавляющем большинстве случаев выход находится. В разных языках, да, он сильно по-разному тут сделан, иногда удорожает реализацию.
Но для тех задач, которые в основном покрываются managed средами, это не очень критично.
Здравствуйте, rg45, Вы писали:
R>Не сопоставима. Ибо, как правило, функции и классы используются существенно большее количиство раз, чем реализуются, а значит, и вероятность допустить ошибку при использовании существенно выше, чем при ее реализации, это во-первых. А главное, у ОПЫТНОГО разработчика C++ есть возможность недопустить некоторые грубые ошибки в исплользовании разработанных им функций и классов, а у ОПЫТНОГО разработчика Java и C# такой возможности нет.
Здравствуйте, netch80, Вы писали:
R>>Не сопоставима. Ибо, как правило, функции и классы используются существенно большее количиство раз, чем реализуются, а значит, и вероятность допустить ошибку при использовании существенно выше, чем при ее реализации, это во-первых. А главное, у ОПЫТНОГО разработчика C++ есть возможность недопустить некоторые грубые ошибки в исплользовании разработанных им функций и классов, а у ОПЫТНОГО разработчика Java и C# такой возможности нет.
N>О каких случаях речь в последнем утверждении?
Здравствуйте, rg45, Вы писали:
KP>>Не так элегантно как в C++, но всё же работает достаточно надежно: KP>>f := createFile("/tmp/defer.txt") KP>>defer closeFile(f) KP>>writeFile(f)
R>А как на счет мемберов классов? "Не так элегантно" — это слишком мягко сказано.
Ну мне решение с defer нравится. Тем более что оно есть и в C++ — BOOST_SCOPE_EXIT. Это реально удобнее в таких последовательных действиях типа "открыли A, открыли B, аллоцировали C, открыли D, временно подменили E и F...", для которых нужен обратный откат (а если закоммитили то можно просто поставить флажок об этом).
Задержка освобождения по GC, да, проблема. Не буду повторять предыдущий свой комментарий, но решается, хоть и заметно другими методами.
Здравствуйте, rg45, Вы писали:
R>>>Не сопоставима. Ибо, как правило, функции и классы используются существенно большее количиство раз, чем реализуются, а значит, и вероятность допустить ошибку при использовании существенно выше, чем при ее реализации, это во-первых. А главное, у ОПЫТНОГО разработчика C++ есть возможность недопустить некоторые грубые ошибки в исплользовании разработанных им функций и классов, а у ОПЫТНОГО разработчика Java и C# такой возможности нет.
N>>О каких случаях речь в последнем утверждении?
R>Ну хотя бы вот о таких
. Я надеюсь, ты понимаешь, что пример абстрактный и мы не станем углубляться в проблему открытия/закрытия файлов.
То есть ты всё о той же несвоевременной финализации. Я думал, будет что-то другое.
Так вот — возможность "не допустить некоторые грубые ошибки" есть. Главное — заранее об этом позаботиться.
Если бы это было что-то со вкусом хаскеля, надо было бы на такие объекты навешивать специальную монаду кстати, интересно, можно ли это без особой крови ввести в Java/C#/etc.
Здравствуйте, netch80, Вы писали:
N>То есть ты всё о той же несвоевременной финализации. Я думал, будет что-то другое. N>Так вот — возможность "не допустить некоторые грубые ошибки" есть. Главное — заранее об этом позаботиться.
Да, я все о том же. Вопрос принципиальный — кто должен/может об этом позаботиться. В одном случае это разработчик класса/функции, в другом — сам пользователь. И, с моей точки зрения, это не просто какая-то там ерунда.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, Somescout, Вы писали:
S>Да, ваше сообщение вполне однозначно: "У вас значительно устаревшие данные по этому вопросу. Примерно на уровне 1998 года".
Ну здесь написано, что у вас данные 98 года, а не фича 98 года.
Фича появилась в С++11, а компиляторы научились разбираться с шаблонами гораздо раньше.
Было же написано: W>Сейчас и в компиляторах и в самом языке есть возможности по устранению оверхеда связанного с генерацией кода по шаблону.
Вот эта вот вторая часть "в самом языке" было про фичу. А первая, веделенная болдом, — про компиляторы в целом.
И научились они с этим справляться гораздо раньше принятия 11 стандарта.
Вон netch80 гораздо более объективный недостаток шаблонов указал. И это вовсе не лишняя генерация кода,
а многословность и вычурность в определенных аспектах. С этимм как раз нельзя не согласиться.
И вы еще удивляетесь почему я так реагирую? Да, я сорвался на личность. Извините. Но подобные демагогические приемы с
выкидыванием всех неудобных слов и выворачиванием смысла наизнанку истощают последние запасы терпения.
Здравствуйте, wander, Вы писали:
S>>Да, ваше сообщение вполне однозначно: "У вас значительно устаревшие данные по этому вопросу. Примерно на уровне 1998 года".
W>Ну здесь написано, что у вас данные 98 года, а не фича 98 года.
Да простят модераторы (или пусть банят, плевать): вы придуривайтесь? Если фича не в 98 году появилась, то с чего вдруг вы вообще его упомянули? Почему не 2002? Не ещё какой год из диапазона? Facepalm, блин.
Здравствуйте, Somescout, Вы писали:
S>Здравствуйте, wander, Вы писали:
S>>>Да, ваше сообщение вполне однозначно: "У вас значительно устаревшие данные по этому вопросу. Примерно на уровне 1998 года".
W>>Ну здесь написано, что у вас данные 98 года, а не фича 98 года.
S>Да простят модераторы (или пусть банят, плевать): вы придуривайтесь? Если фича не в 98 году появилась, то с чего вдруг вы вообще его упомянули? Почему не 2002? Не ещё какой год из диапазона? Facepalm, блин.
Я же выше объяснил.
Вы транслировали мнение, что С++ шаблоны не подходят для Embedded потому что раздувают код.
А я вам сказал, что в 98 году (или около того) действительно было такое явление, и компиляторы С++ 98 года (или около того) действительно не подходили для Embedded.
Но с тех пор все изменилось.
И сейчас есть прекрасные примеры Embedded-проектов на С++, в том числе с шаблонами. И возможно это благодаря тому, что с тех пор сильно развились техники оптимизации, в том числе шаблонного кода (доработаны компиляторы). А помимо этого (в С++11) появились дополнительные фичи по контролю лишний инстанцирований (доработан язык).
Здравствуйте, netch80, Вы писали:
N>Ну мне решение с defer нравится. Тем более что оно есть и в C++ — BOOST_SCOPE_EXIT. Это реально удобнее в таких последовательных действиях типа "открыли A, открыли B, аллоцировали C, открыли D, временно подменили E и F...", для которых нужен обратный откат (а если закоммитили то можно просто поставить флажок об этом).
Все та же проблема — этот самый defer должен написать полльзователь функции, а не разработчик.
Другая проблема — не работает для подобъектов. Какждый раз требуется ручное управление, что плодит ошибки времени выполнения.
Третья проблема, использую сишарпный аналог defere-а — using. Много ли найдется разработчиков C#, которые скажут сходу, какой из следующих вариантов является правильным (пример, опять же, абстрактый, просьба не придираться к прикладным аспектам):
public static T Deserialize<T>(Stream input)
{
var textReader = new StreamReader(input);
// че-то читаем из textReaderusing (var xmlReader = XmlReader.Create(textReader))
{
return Deserialize<T>(xmlReader);
}
}
или
public static T Deserialize<T>(Stream input)
{
using (var textReader = new StreamReader(input))
{
// че-то читаем из textReaderusing (var xmlReader = XmlReader.Create(textReader))
{
return Deserialize<T>(xmlReader);
}
}
}
Или может, вообще можно без всяких using, как правильно?
И даже на этом веселуха еще не заканчивается — обязательно ведь найдется грамотей, который позовет Dispose (прямо либо через using) для входного стрима.
И подобные проблемы неминуемо возникают везде, где ресурс выделяется провайдером, а отвестсвенность за его осводождение лежит на консумере. Остается только радоваться разнообразию этих проблем: неосвобождение ресурсов (учетчки), повторное освобождение, несвоевременное освобождение.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, Слава, Вы писали:
С>Туда можно запихать Java Card и Аду. Кстати, запихивание в систему с очень ограниченными ресурсами — это скорее про Си.
Ага, берешь такой какую-нибудь Atmega 328 и запихиваешь
У CPython одна логика, у PyPy — другая, и скрестить их можно только если по-разному в них работать. Финального решения ещё не сделал, вот закончу с другой частью и вернусь к той.
