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

A>По-моему, какая-то отстойная аналогия...

Зачем же так? Я всего лишь хотел сказать, что .Net это, скорее, эволюционная технология, а не революционная. Поэтому споры подобного рода носят умозрительный характер и не имеют большого смысла.

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

C>Вы считаете, что на дотнет писать неудобнее, чем на С++?

Сравнивать дотнет и С++ не имеет смысла. Это очень разное. Но, что касается языков, то мне приятнее, например, деревья, писать на C++. Указатели для динамических сруктур лично мне кажутся более естественными. Конечно, они есть и в C#, но их применение противоречит философии net. До сих пор на "чистом" net трудно написать достойную САПР программу. WPF прекрасен, но это набор глыб. Это мое мнение.

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

H>>совершаемые ошибки есть стимулирование проф. развития (это к словам о том, что говнокодер есть понятие внеязыковое и вообще независимое) т.к. заставят с кодом возиться вплотную.

A>Смотря что считать развитием. Научится чуять затёртый стек и научится чуять удачный рефкторинг всё же разные вещи.

Понимание сути совершаемых действий и есть развитие.

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

M>>>Мне кажется у вас неверные представления. Если бы симптомы ошибки проявлялись так очевидно, тогда плюсы были бы лишены 95% недостотков. Обычно я наблюдаю противоположную картину, ошибки живут годами и никак себя не проявляют до неожиданного момента.

H>>Я и не говорю про очевидность всего и вся. Но даже небольшую утечку можно обнаружить, если программой активно пользуются, не говоря уже о больших.

C>У Вас наверно очень мало опыта, раз Вы до сих пор не понимаете, что между "обнаружить наличие утечки" и "обнаружить место утечки" две очень очень большие разницы.

Ты видимо понятия не имеешь, что менеджеры памяти (FastMM [CBuilder, Delphi] во всяком случае) умеют рапортовать об утечках (с адресами, размерами потерянных блоков).

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

H>>Этот пример сродни тому, что приводил Синклер. Вы потерли память, но данные это не затронуло. Можно это считать ошибкой? Технически можно, но только технически. Теперь я говорю: "потом обязательно накроет". Накрыло? А как бы вы еще об этом узнали (пристальный код-ревью оставим в сторонке). Я согласен, что локализовать такие ошибки может быть очень не просто, потому и цитировал Суворова.

M>Еще это может означать что вы мало пишете кода для многократного использования, библиотечного.

Я, в основном, библиотечный и пишу, ужо 13 лет как . Мне только не понятно желание некоторых участников пообсуждать меня, а не мои тезисы

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

H>>В определенной степени это так. Но в нативе за каждый неверный шаг -- расстрел на месте (а не на месте, так потом обязательно накроет). Память потекла (как в приведенном примере), будет видно сразу (если потечет байтами, конечно нифига без специальных телодвижений не увидишь). Память затер -- получишь либо неверные данные, либо сразу Access Violation.
S>Либо получишь undefined behavior, который в тестовых условиях будет крайне похож на нужный.
S>Понимаешь — одно дело получить ексепшн при тайпкасте, другое дело — получить неверные данные. Вон Рома приводил только что пример про чуваков, которые передавали в функцию мусор. Ну так это стандартная ошибка — взять sizeof не от того. И никто тебе по рукам не настучит. Всё ведь в их примере выглядело как настоящее; работало себе и пережило несколько мажорных версий.

Undefined Behavior ловится тестами. Новичка жизнь научит постепенно.

H>>Собственно, это двоякая ситуация: с одной стороны хорошо, что говнокодер сразу и жестко наказывается,
S>Еще раз поясню — "сразу" и "жестоко" — это когда компилятор C# говорит ему "так нельзя". А то, о чем вы говорите — это "потом" и "может быть". Разница понятна?

Неиспользование using для нативных ресурсов компилятор покажет? В нативе конечно сложнее, кто спорит... Но речь то о том, что преодоление этих трудностей есть вещь необходимая для профессионального развития, и стумулирующая освоение "культуры кодирования" (а затем и культуры производства), как одного из обязательных требований к профессионалу.

Хотя, вообще, разговор был о том, что говнокодить легче на C#

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

H>Неиспользование using для нативных ресурсов компилятор покажет? В нативе конечно сложнее, кто спорит... Но речь то о том, что преодоление этих трудностей есть вещь необходимая для профессионального развития, и стумулирующая освоение "культуры кодирования" (а затем и культуры производства), как одного из обязательных требований к профессионалу.
Постоянная борьба с ветрянными мельницами несомненно обязательно необходимо для каждого, ставшего на тернистый путь Дон Кихота.

H>Хотя, вообще, разговор был о том, что говнокодить легче на C#
Вам виднее где Вам легче говнокодить..

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

H>>>Я и не говорю про очевидность всего и вся. Но даже небольшую утечку можно обнаружить, если программой активно пользуются, не говоря уже о больших.

C>>У Вас наверно очень мало опыта, раз Вы до сих пор не понимаете, что между "обнаружить наличие утечки" и "обнаружить место утечки" две очень очень большие разницы.

H>Ты видимо понятия не имеешь, что менеджеры памяти (FastMM [CBuilder, Delphi] во всяком случае) умеют рапортовать об утечках (с адресами, размерами потерянных блоков).

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

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

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

H>>>совершаемые ошибки есть стимулирование проф. развития (это к словам о том, что говнокодер есть понятие внеязыковое и вообще независимое) т.к. заставят с кодом возиться вплотную.

A>>Смотря что считать развитием. Научится чуять затёртый стек и научится чуять удачный рефкторинг всё же разные вещи.

H>Понимание сути совершаемых действий и есть развитие.

Понимание сути есть результат развития, а не развитие как таковое.

Здравствуйте, hattab, Вы писали:
H>Undefined Behavior ловится тестами. Новичка жизнь научит постепенно.
Это иллюзии молодости — насчёт UB.

H>Неиспользование using для нативных ресурсов компилятор покажет?
Нет, не покажет. Но я повторно намекну: using — это "ускоритель", позволяющий получить детерминистическое освобождение. Фишка в том, что если его нет, то программа таки будет корректно работать. Просто ресурсы будут освобождаться медленнее. А в C++ ты получишь чистую утечку.

H>В нативе конечно сложнее, кто спорит... Но речь то о том, что преодоление этих трудностей есть вещь необходимая для профессионального развития, и стумулирующая освоение "культуры кодирования" (а затем и культуры производства), как одного из обязательных требований к профессионалу.
Нет. К сожалению, преодоление дурацких грабель всего лишь вырабатывает вредные привычки. В 1% случаев приобретаются какие-нибудь среднеполезные знания, но в остальных 99% это всего лишь мусор. Который, естественно, с годами хозяин начинает ценить. Вот я в свое время писал статью сюда — про отлов недореализованных абстрактных методов в Delphi.
Да, когда я столкнулся с этим глюком, я узнал дофига всего про потроха VCL и компилятора дельфи. Но зачем? В шарпе это просто не воспроизведешь никак.

H>Хотя, вообще, разговор был о том, что говнокодить легче на C#
Это, имхо, вопрос открытый. Кодить вообще — легче на шарпе. А вот насчет говнокодинга — довольно много плохих практик шарп пресекает сразу. Еще много чего даёт последующий анализ.

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

H>>Неиспользование using для нативных ресурсов компилятор покажет?
S>Нет, не покажет. Но я повторно намекну: using — это "ускоритель", позволяющий получить детерминистическое освобождение. Фишка в том, что если его нет, то программа таки будет корректно работать.
Неа. Ты получишь тот самый UB о котором говоришь, если ресурсы закончатся раньше, чем GC их прибьёт.

Здравствуйте, Cyberax, Вы писали:
C>Неа. Ты получишь тот самый UB о котором говоришь, если ресурсы закончатся раньше, чем GC их прибьёт.
С чего бы это?

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

C>>Неа. Ты получишь тот самый UB о котором говоришь, если ресурсы закончатся раньше, чем GC их прибьёт.
S>С чего бы это?
Представь, что ты таким образом обращаешься с соединениями к БД. Весьма велика вероятность, что у тебя их пул закончится раньше, чем будет проведён полный цикл GC. Аналогично и с файловыми дескрипторами.

Знаем, проходили.

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

H>Неиспользование using для нативных ресурсов компилятор покажет? В нативе конечно сложнее, кто спорит... Но речь то о том, что преодоление этих трудностей есть вещь необходимая для профессионального развития, и стумулирующая освоение "культуры кодирования" (а затем и культуры производства), как одного из обязательных требований к профессионалу.

Не надо таких громких слов. Я видел как толпы новичков в C# (и в программировании вообще) использовали using там где надо, потому что подключили fxcop в build-систему.

такие вещи как незадипозенный объект ловятся статическим анализом, а вот потертый стек тебе ни одна утилита не покажет.

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

G>Не надо таких громких слов. Я видел как толпы новичков в C# (и в программировании вообще) использовали using там где надо, потому что подключили fxcop в build-систему.
FXCop не поймает использование ресурсов, если он будет полем класса.

G>такие вещи как незадипозенный объект ловятся статическим анализом, а вот потертый стек тебе ни одна утилита не покажет.
Открой для себя valgrind...

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

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

G>>Не надо таких громких слов. Я видел как толпы новичков в C# (и в программировании вообще) использовали using там где надо, потому что подключили fxcop в build-систему.
C>FXCop не поймает использование ресурсов, если он будет полем класса.
А сам проверял, прежде чем писать?
Все ловит


G>>такие вещи как незадипозенный объект ловятся статическим анализом, а вот потертый стек тебе ни одна утилита не покажет.
C>Открой для себя valgrind...
Я уже давно открыл для себя managed языки

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

M>Сравнивать дотнет и С++ не имеет смысла. Это очень разное. Но, что касается языков, то мне приятнее, например, деревья, писать на C++. Указатели для динамических сруктур лично мне кажутся более естественными. Конечно, они есть и в C#, но их применение противоречит философии net. До сих пор на "чистом" net трудно написать достойную САПР программу. WPF прекрасен, но это набор глыб. Это мое мнение.

Никто же тебе не запрещает делать кучу на массивах. Только хранить нужно ссылку на массив и индекс в массиве.
Например http://www.rsdn.ru/forum/Message.aspx?mid=445372&only=1

Автор: Serginio1
Дата: 17.11.03

Кстати в Net очень плохо с большим количеством объектов на которые часто меняются ссылки. И такой подход может значительно ускорить работу Net

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

C>>FXCop не поймает использование ресурсов, если он будет полем класса.
G>А сам проверял, прежде чем писать?
И проверял, и использовал.

G>Все ловит
Нет.

Здравствуйте, Cyberax, Вы писали:
C>Представь, что ты таким образом обращаешься с соединениями к БД. Весьма велика вероятность, что у тебя их пул закончится раньше, чем будет проведён полный цикл GC. Аналогично и с файловыми дескрипторами.
И что дальше? Откуда возьмется UB?
Поведение будет вполне детерминированным. Нехорошим, но детерминированным.

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

C>>Представь, что ты таким образом обращаешься с соединениями к БД. Весьма велика вероятность, что у тебя их пул закончится раньше, чем будет проведён полный цикл GC. Аналогично и с файловыми дескрипторами.
S>И что дальше? Откуда возьмется UB?
Оттуда.

S>Поведение будет вполне детерминированным. Нехорошим, но детерминированным.
Время запуска GC — недетерминировано.