Здравствуйте, VladD2, Вы писали:
VD>Какую? Я просто пользовался штатными возможностями языка. Более того, так как язык не позволяет автоматически управлять памятью, я буду вынужден писать подобный код реализуя свои контейнеры. И мест для ошибок приводящих к очень неприятным последствиям тут хоть отбавляй. И все в следствии дизайна языка.
Здравствуйте, VladD2, Вы писали:
VD>Клиника это язык в котором такое море граблей. По сему добрую половину (а то и больше) С++-ного кода не удается назвать корректным кодом.
Да тут проблема иная, и это уже озвучивалось.
Проблема в том, что понятие "грабли" неумолимо расширяется год от года.
Вполне нормальная ситуация, типа:
— запрос ресурса
— использование ресурса
— освобождение ресурса
никогда не вызывала проблем еще буквально лет 7-8 назад.
Однако, с некоторых пор, добрая половина т.н. программистов, коя "разбавила" собой IT-отрасль считает такую ситуацию граблями. И под них, родимых, этот паттерн сократили до:
— запрос ресурса
— использование ресурса
в современных managed и IDisposable средах.
(Кстати, популярные идиомы С++ тоже помогают в приведении паттерна к такому виду)
Но это еще не предел, в некоторых "еще более хороших языках" этот паттерн сузился до апофеоза:
— просто используем ресурс (а там разбирайтесь сами)
Мне трудно комментировать подобную ситуацию, ибо всегда спор переходит в плоскость: "что сейчас дешевле — купить более мощный компьютер или нанять более опытного программиста?", т.е. в тупик, ибо сходу отвергает исходные постулаты эффективности и критерии качества, применяемые ранее в IT.
Я уверен, что "супер язык" C# и тот же VB.Net содержат ну просто невообразимое количество граблей для среднего программиста образца эдак 2015-го года. И ведь индустрия опять под него, под этого программиста прогнется.
<утопия>Или случится чудо, и количество программ(истов) постепенно перейдет в качество</утопия>
Re[6]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, VladD2, Вы писали:
T>>Во-во. Влад, может быть ты знаешь языки, в которых можно без написания множества строк кода сказать: "у меня будет тип НомерСимволаВСтроке, ведёт себя совсем как int, только это совсем другой тип и использовать один вместо другого нельзя"? В горячо мною любимом C++ для этого надо определить класс и все операции вручную. В Java не лучше. Но хоть где-нибудь-то можно?!
VD>Если не ошибаюсь, в D нечто подобное возможно. Было в Паскале... перекочивало в Аду. Эта концепция вообще-то была во многих языках. Называлась по разному, но суть одна неких typedef, но порождающий не алиас, а новый тип. По-моему очень полезная концепция. Ну, да можно жить и без нее. Все же и копипыст, и шаблоны, и дженерики для этого применимы. И лучше помучиться с ними, чем постоянно вставлять проверки и молиться.
VD>Кстати, было бы куда лучше если бы можно было создавать наследников вэлью-типов. Пусть даже без полиморфизма. А с полиморфизмом так вообще была бы круть.
Здравствуйте, vdimas, Вы писали:
V>Если намеренно не обходить защиту в виде типизации, то все будет ok.
Не спасет, так как ошибиться и вызвать деструктор дважды проще простого. А заставить всех писать деструкторы в реинтерабильной манере невозможно.
Что же касается обхода защиты... в С++ ее настолько просто обойти и это приходится делать настолько часто, что подобные проблемы не редкость и в программах написанных матерыми профи, а про среднего программиста (к коим на этом форуме оносится 80% народу) — это воощбе нормальная ситуация.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, vdimas, Вы писали:
V>...Однако, с некоторых пор, добрая половина т.н. программистов, коя "разбавила" собой IT-отрасль считает такую ситуацию граблями.
О... как забавно. Может чем выделять себя в особую касту подкинуть аргументов?
V>Я уверен, что "супер язык" C# и тот же VB.Net содержат ну просто невообразимое количество граблей для среднего программиста образца эдак 2015-го года. И ведь индустрия опять под него, под этого программиста прогнется.
Несомненно со временем цензы качества должны повыситься. Но почему увеличение ценза качества подменяется странным ярлыком "прогнется"?
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, vdimas, Вы писали:
V>мы используем для типизации int в C# enum.
Мне нужно было типизировать координату, по этому все равно пришлось лепить тип.
Использование enum — это конечно оригинально, но при этом ведь прийдется приводить эго к int при банальных арифмитических рассчетах. А ведь операторов для энума не сделашь.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, vdimas, Вы писали:
V>Мне напомнить про то, что я могу в unsafe режиме в донете и не такое сделать непосредственно в рамках C#?
Напомни. Может кто забыл. За одно напоми себе о том, что на Шарпе без проблем можно программировать без unsafe. А unsafe требует специльных опций компилятора и ручного указания unsafe-кода.
V>Почему мы все время говорим о том, что "а вот у здесь можно вот такую-то лажу нагнать", вместо того, чтобы обсудить, где удобнее не нагнать эту лажу.
Потому-что мы говорим, о том, что один язык содержик море граблей в своем дизайне. (Другой вопрос почему это происходит.)
V> В дотнете в interop вообще все можно уронить с пол-пинка, однако же пользуемся.
Можно примеры? Я вот на практике убедился в обратном.
V>Я вообще не вижу причин огорчаться в случае, если некорректная программа падает, дык — это корректное поведение неккоректной программы.
Огорчаться приходится из-за времени потраченного на отладку и потери данных (или сюжета в играх).
V> Меня больше интересует возможность в рамках некоего инструмента писать так, чтобы уменьшить вероятность собственных ошибок.
Меня тоже. И таких возможностей намного больше в языках которые проектировались специально для этого.
V>Знаю, что ты давно пересел на 2.0, но у нас коммерческие проекты, и они, разумеется, на 1.1. И сильной статической типизации плюсов порой ой как не хватает.
Думаю, что нехватать вам может только возможностей обобщенного программирования. Потому как в общем, шарп в сэйф-режиме полностью типобезопасен, а С++ нет.
V>Для того, чтобы избежать "обезличенных" сигнатур, типа V>
V>мы извращаемся как можем, и, на мой взгляд, не всегда корректно применяем имеющиеся штатные ср-ва. Однако, они себя окупают.
Использованите object всего лишь сдвигает контроль типов в рантайм. Но обойти его нельзя. Контроль в рантайме конечно хуже чем в процессе компиляции, но все же лучше наличия перспективы получения ошибок второго и более опрдков (порчи памяти).
V>Например. V>
V>public enum ObjectIdT { eNoObject };
V>
V>- пустой енум, мы его используем как типизированный int, используя весь диапазон int-значений. Это немного неккоректно, зато помогло найти несколько ошибок, при добавлении типизации в метод: V>
V>Method1(ObjectIdT, int);
V>
Да можно было и структуру-обертку создать. Хотя оригинально конено.
V>Да, "шаблонность" нам малость поможет потом частично разрулить эти безобразия, однако, прежнего удобства от наличия сильной статической модели кода, какую привык наблюдать в С++, все-равно не получим даже в 2.0. (У меня Express, все ограничения дженериков уже просек).
Что-то говорит мне, что обосновать это утверждение тебе не удастся. Но попробовать стоит. Это будет интересно.
В качестве примера могу привести редактор кода который я сейчас пишу. В нем приведений типов минимум (около 20). В основном они получаются при работе с вэлью-тпами, при обработке событий и рефлекшоне.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, VladD2, Вы писали:
VD>Использование enum — это конечно оригинально, но при этом ведь прийдется приводить эго к int при банальных арифмитических рассчетах. А ведь операторов для энума не сделашь.
О как... А исходя из чего такое причудливое ограничение?
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
C>void func()
C>{
C> struct
C> {
C> void operator ()(int a, int b)
C> {
C> ....
C> }
C> } inner;
C> inner(1,2);
C>}
C>
C>Чем не функция?
а как сделать такое
void func(int A,int B)
{
int C=0;
int D=0;
void inner(int E, int F)
{
C += (A * E);
D -= (B * F);
};
inner(1,2);
inner(3,4);
inner(5,6);
inner(7,8);
inner(9,0);
}
icWasya wrote:
> C>Чем не функция? > а как сделать такое > >void func(int A,int B) >{ > int C=0; > int D=0; > void inner(int E, int F) > { > C += (A * E); > D -= (B * F); > }; > > inner(1,2); > inner(3,4); > inner(5,6); > inner(7,8); > inner(9,0); >} > >
void func(int A,int B)
{
int C=0;
int D=0;
struct inner(int E, int F)
{
int &A,&B,&C,&D;
void operator()(int E,int F)
{
C += (A * E);
D -= (B * F);
}
} inner={A,B,C,D};
inner(1,2);
inner(3,4);
inner(5,6);
inner(7,8);
inner(9,0);
}
Некрасиво, но такое нужно бывает очень редко.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[9]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, Павел Кузнецов, Вы писали:
VD>>Использование enum — это конечно оригинально, но при этом ведь прийдется приводить эго к int при банальных арифмитических рассчетах. А ведь операторов для энума не сделашь.
ПК>О как... А исходя из чего такое причудливое ограничение?
Содрали м С++.
Вообще по мне так дуроное ограничение. И не нужное. Можно было извернуться.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, VladD2, Вы писали:
VD>Содрали м С++.
VD>Вообще по мне так дуроное ограничение. И не нужное. Можно было извернуться.
Может я не понял суть вопроса, но если речь шла о перегрузке операторов enum-типов в рамках C++, то это может выглядеть так:
enum EA
{
IS = 0,
BOX
};
EA operator++(EA &ea, int i)
{
EA ret = ea;
ea = (EA)((int)ea+1);
return ret;
}
EA operator++(EA &ea)
{
return ea = (EA)((int)ea+1);
}
Использование:
EA ea = IS;
EA pref_ea = ++ea; // префиксный
EA post_ea = ea++; // постфиксный
Re[11]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, Denis2005, Вы писали:
D>Может я не понял суть вопроса, но если речь шла о перегрузке операторов enum-типов в рамках C++, то это может выглядеть так:
Прочти внимательно о чем идет речь.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, vdimas, Вы писали:
V>>...Однако, с некоторых пор, добрая половина т.н. программистов, коя "разбавила" собой IT-отрасль считает такую ситуацию граблями.
VD>О... как забавно. Может чем выделять себя в особую касту подкинуть аргументов?
ниже...
V>>Я уверен, что "супер язык" C# и тот же VB.Net содержат ну просто невообразимое количество граблей для среднего программиста образца эдак 2015-го года. И ведь индустрия опять под него, под этого программиста прогнется.
VD>Несомненно со временем цензы качества должны повыситься. Но почему увеличение ценза качества подменяется странным ярлыком "прогнется"?
Потому как за все это конечный пользователь платит потерей эффективности. Соответственно, все эти "улучшения" приходят лишь в тот момент, когда снижение эффективности становится "незаметной на глаз", т.е. отрасль глотает эти потери без особого ущерба.
Соответственно, со временем, большая часть задач программирования будет становится все более и более простым делом. (Вернее, эти задачи сделают простым делом, за счет некоторых очередных потерь, разумеется)
--------
Кстати, качество от этого не повысится. У качества несколько иное определение.
Re[19]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, VladD2, Вы писали:
V>> В дотнете в interop вообще все можно уронить с пол-пинка, однако же пользуемся.
VD>Можно примеры? Я вот на практике убедился в обратном.
Неправильно call-conversion указан, или аттрибуты по управлению маршаллингом. Получаем неверную интерпретацию памяти, прямо как в С++ при неккоректном кастинге. Такие же незаметные глазу ошибки, кстати.
V>> Меня больше интересует возможность в рамках некоего инструмента писать так, чтобы уменьшить вероятность собственных ошибок.
VD>Меня тоже. И таких возможностей намного больше в языках которые проектировались специально для этого.
Они еще недопроектировались. И не доросли. Посмотрим на C# 3.0 ... Пока что мы приобретаем не больше чем теряем, переходя на C# (речь о языке, а не о фреймворке). Из твоих аргументов я выделяю лишь возможность "уронить" С++ программу при выходе за пределы массива или неккоректном кастинге. Однако, на С++ есть довольно сильная культура кода, не нарушая которую можно писать вполне надежные приложения. Я предвижу возражение: "нарушить же элементарно"... Украсть кусок мыла в магазине тоже элементарно, и даже прокатит в 99%, но вот стоит ли рисковать...
V>>Знаю, что ты давно пересел на 2.0, но у нас коммерческие проекты, и они, разумеется, на 1.1. И сильной статической типизации плюсов порой ой как не хватает.
VD>Думаю, что нехватать вам может только возможностей обобщенного программирования. Потому как в общем, шарп в сэйф-режиме полностью типобезопасен, а С++ нет.
Да нет, речь идет именно о статической типизации.
V>>Да, "шаблонность" нам малость поможет потом частично разрулить эти безобразия, однако, прежнего удобства от наличия сильной статической модели кода, какую привык наблюдать в С++, все-равно не получим даже в 2.0. (У меня Express, все ограничения дженериков уже просек).
VD>Что-то говорит мне, что обосновать это утверждение тебе не удастся. Но попробовать стоит. Это будет интересно.
VD>В качестве примера могу привести редактор кода который я сейчас пишу. В нем приведений типов минимум (около 20). В основном они получаются при работе с вэлью-тпами, при обработке событий и рефлекшоне.
Откуда, если не секрет, набралось 20 приведений в статической структуре редактора?
Шутка...
Ну, а если у нас бизнес-сущностей более 50-ти, например? И есть базовые классы-имплементации. Сейчас у нас неудобства примерно такие как от использования стандартных контейнеров. Ручками дохрена приходится типизировать в наследниках от базовых классов (напомню, речь об 1.1.). Если же ручками не типизировать, то опять будет как та ситуация со стандартными контейнерами — пихай куда хошь что хошь под безликий object, и в коде приводи постоянно к нужному типу при извлечении... В общем, раздражает этот типизационный копипейст, коего в том же С++ просто не было бы.
Re[12]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Denis2005, Вы писали:
D>>Может я не понял суть вопроса, но если речь шла о перегрузке операторов enum-типов в рамках C++, то это может выглядеть так:
VD>Прочти внимательно о чем идет речь.
Действительно не понятно, что именно ты сказал в том посте (из-за описки). Но в С++ можно перегружать операторы для enum.
Re[10]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, VladD2, Вы писали:
VD>>>Использование enum — это конечно оригинально, но при этом ведь прийдется приводить эго к int при банальных арифмитических рассчетах. А ведь операторов для энума не сделашь.
ПК>>О как... А исходя из чего такое причудливое ограничение?
VD>Содрали м С++.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, vdimas, Вы писали:
V>>Если намеренно не обходить защиту в виде типизации, то все будет ok.
VD>Не спасет, так как ошибиться и вызвать деструктор дважды проще простого. А заставить всех писать деструкторы в реинтерабильной манере невозможно.
Ну, Влад, это уже перегиб. Ошибится и вызвать деструктор многократно в какоим-нить самописном векторе — это совершенно надуманный аргумент. Я видел многократные вызовы деструкторов лишь в случае, если они были "размазаны" по объемному коду, безо всякой инкапсуляции. Ну дык, это понятно — налицо было нарушение идиомы RAII.
Если же "все как положено", то в самих инкапсулированных имплементациях ошибится сложнее.
— За сколько телегу почините?
— За пол-дня починим?
— А за день?
— Ну... если постараться, можно и за день...
— А за неделю???
— Ну, тут уж без помощника не обойтись.
VD>Что же касается обхода защиты... в С++ ее настолько просто обойти и это приходится делать настолько часто, что подобные проблемы не редкость и в программах написанных матерыми профи, а про среднего программиста (к коим на этом форуме оносится 80% народу) — это воощбе нормальная ситуация.
Да нет, Влад. Сведения устарели. Обход защиты — это нонсенс в современном мире С++ (речь о прикладном коде). В одном из проектов 2-х летней давности мне пришлось пойти на одиночное приведение в стиле старого С, и то, перед этим долго обсуждали с напарником — нет ли другого выхода? (исходники были недоступны, а залезть "внутрь" надо было). Событие было неординарное и оттого запомнилось.
А так — мне даже трудно представить, где мне потребуется подобное приведение в прикладном коде. А что касается системных вещей, то разве что в самописных менеджерах памяти происходят неявные приведения к void* (через сигнатуру оператора new). Остальное большинство системных задач ныне присутствуют в готовом и отлаженном виде.
Re[11]: Частота ошибок в зависимости от языка: что делать?
