Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
S>Простая группировка переменных достигается вообще безо всяких структур. Вот так:
S>
Скажу больше. Это тоже плохой С-шный стиль (именно С-шный, а не С++-ный). Переменные лучше объявлять при их первом использовании. Тогда и места меньше нуно, и яснее их назначение, и вероятность оставить ее неинициализированной существенно уменьшается (хтя это уже в C# сделать крайне сложно вообще).
S>Ты математику учил? Тензор — это не просто несколько цыферок записанных в табличку. Это математический объект, описываемый своими компонентами. И это компоненты обязаны вести себя определенным образом при смене системы координат.
S>Точно так же и структура — это сущность, компоненты которой ведут себя согласованно. С точки зрения ООЯ это объект.
Полностью согласен с предыдущим аратором.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>. А всех, кто с принципом "ООЯ доведенный до предела" не согласен — в ад!
Нет. Те используют языки ориентированные на процедурное/функциональное программирование. Ты же выбрал язык который просто не удобен для не ОО-кодирования.
Ну, а я так считаю, что половинчатые решения вроде описанного тобой (когда структура создается, но обрабатывающий код остается внешним) — это в первую очередь удар по абстракции, а значит ухудшение восприятия кода. Представь себе если бы вместо мат.-операций над матрицами пришлось бы использовать (а главное читать) голый код оперирующий с ихними членами. Зачем такая каша когда есть методы и операторы?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Хм, а как же тогда в managed C++ можно структуры внутри функций описывать ? Тут кто-то сказал, что можно. Или нельзя все же ?
Там и функции глобальные описать можно. Проблема только в том, что их никто не поймет. А еще там влет можно пройтись по памяти или вызвать переполнение буфера.
При разработке C# ставилась цель создать язык общего назначения который будет в первую очередь безопастным, во вторую простым, в третью объектно ориентированным. Задачи сдирания всего что есть в С++ не входило. По этому получился язык только синтаксически похожий на С++. Применять его унжно совсем по другому. Но если научиться его применять как надо, то очень вероятно, что С++ начнет со временем вызвать тошному. Я тому живой пример.
В общем, нужно понять, что нужно просто погрузиться в Шарп. Проблемы которые ты испытывашь — это проблемы человека меняющего привычки. Даже если привычка вредная отказаться от нее не просто. Одако отказавшись от нее ты осознашь, что выиграл от этого.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>В .Net классы есть некоторая сущность эпохи рантайма, и довольно серьезная сущность. Если же оставить .Net в стороне и рассматривать unmanaged код, то в нем классы в рантайме или вообще не существуют (C++ без RTTI), либо ограниченно существуют (C++ с RTTI, Object Pascal). А поскольку C# специально заточен под .Net, MS и сделала в нем такое ограничение. Вот в этом и причина, а не в идейных соображениях. С С++ она такое сделать не могла — язык ей не принадлежит .
Это то объяснение которое тебе хочется видеть. Тут вот рядом был флэймец с ВБ-шниками которые в упор отказывались понимать (а точнее, как ты, принимать) то что в C# нет индексированных свойств и дефолтных свойств. Аргументация была в точности противоположенная твоей. Мол "в MSIL-е же индексированные свойства есть, и индексатор C#-а превращается при компиляции в нег, значит индексированные свойства есть в C#". Пролодление было уже в твоем духе (только еще и в хамской манере). "...он явно он их не дает сделать потому что C# фуфло!". Вот така логика.
PD>Ну а правильно это или нет — будущее покажет.
Да уже показало. Для всех кто покончил с настальгией по тараканам С++ подобные штуки проблемой не являются. Даже ярые апологеты С++ вроде ПК находят куда более тонкие (и надо признать порой не безосновательные) претензии в C#.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Sinclair, не стоит передергивать. Нигде я такого не говорил. Это просто практика всех, кто писал раньше на C++/Pascal. Об этом в любом учебнике по этим языкам написано. И то, что в С# этого нет, еще не означает, что это неверно. C# и .Net еще не все программирование .
Я тоже писал на C++/Pascal, и Синклер писал. Но почему-то желания получить локальные классы не имеем.
Я бы еще согласился бы если поступило предложение ввести некие дополниельные оласти видимости в которых можно было бы собирать нечто относящееся к реализации некоторого метода. Ну, нечто вроде вложенных функций в Pascal-е, но без функций. Ведь, как правильно заметил Синклер, функция на 500 строк это жуть и мрак.
Кстати, почему тебя не напрягает отсуствие в С++ возможнсоти создать вложенную функцию? Ведь в Паскале это есть, и никого это не напрягает?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Все это интересно в данной функции. За пределами этой функции такая структура никому не нужна, да и вообще желательно, чтобы о ней никто не знал, потому как дело это сугубо внутреннее для этой функции. А получается, что сделать такое невозможно.
Специальная структура только для одной функции? Сдается мне, что функционал этой функции перегружен. А если еще будет такая внутренняя структура, то эту функцию отрефакторить как следует будет нельзя.
... << RSDN@Home 1.2.0 alpha rev. 615 on Windows XP 5.1.2600.131072>>
Sinclair,
> Ты не мог бы пояснить подробнее причины прятать структуру от остальных? Я вижу две проблемы: > 1. Есть риск конфликта имен.
И это тоже. Особенно актуально в больших проектах с долгим временем жизни, где разработка ведется в параллельных ветках SCM и т.п.
> 2. Есть риск того, что кто-то использует структуру без твоего ведома. > Вот этого аргумента я вообще понять не могу. Ну, использует, и что? Какой вред-то от этого произойдет?
Например, может прятаться конкретный класс при реализации одного из вариантов factory method. В случае, если конкретный класс определяется внутри порождающей функции, мы видим, что никто точно не лезет к деталям реализации конкретного класса, т.к. вынужден работать через базовый интерфейс. В случае, если конкретный класс определен "вовне", нужно так или иначе дополнительно заботиться о локализации доступа к нему. Впрочем, наверное, т.к. в C# нет "свободных" функций, это не так актуально, т.к. там вместо функции в обсуждаемом варианте:
auto_ptr<AbstractProduct> create_product()
{
class ConcreteProduct : public AbstractProduct
{
. . .
};
return auto_ptr<AbstractProduct>( new ConcreteProduct );
}
наверное, сразу будет сделан специальный класс:
public class ProductFactory
{
privateclass ConcreteProduct : AbstractProduct
{
. . .
}
public static AbstractProduct create_product()
{
return new ConcreteProduct();
}
}
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re: Структура внутри функции
От:
Аноним
Дата:
26.09.05 06:10
Оценка:
_>2 Автор _>Используй C#3 Там есть неименованные структуры
Нет там никаких анонимных структур. Пока что анонимные типы выраждаются в классы.
Мда, действительно.
А что будет в релизе вообще не ясно.
Само собой
_>Возвращай Hashtable, если возможно
Звучит дико. А не мог бы ты обосновать такое редложение?
Ну если человеку очень хочется сгруппировать несколько переменных. Почему бы их не сгруппировать в Hashtable
А вообще, конечно верно, что:
Поясняю. Ты пытаешся программировать на ООЯ не объектно-ориентированными методами. Отсюда и проблема. Не думай о структуре как о средстве сгриппировать переменные. Думай о ней как об объекте со своим состоянием, поведением и т.п.
А если тебя вдруг тянет банально объеденить две переменные, то нужно останавливаться и возвращаться к дизайну системы. Переменные ведь не просто так связаны. Скорее всего они являются частью состояние некой более абстракной сущности....
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Это поправимо в следующей версии спецификации. Жаль только, что темп работы комитетчиков столь нетороплив...
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, MatFiz, Вы писали:
MF>>С другой стороны, это не дает тебе писать в плохом стиле, когда тело функции занимает несколько экранов и в связи с этим нефтыкаемо методом окидывания взглядом.
PD>Не хочу я писать в плохом стиле. Я наоборот хочу в хорошем писать
PD>Ситуация. Пишу я функцию. В ней штук 10 переменных, описывающих некоторый внутренний для этой функции объект (слово объект в общечеловеческом смысле, а не в смысле языка). В соответствии с правилами хорошего стиля стоит из них создать структуру, чтобы обращаться к этим переменным как к некоторому единому целому. Ну хоть скопировать их все в другой набор таких же переменных (для другого объекта).
PD>Все это интересно в данной функции. За пределами этой функции такая структура никому не нужна, да и вообще желательно, чтобы о ней никто не знал, потому как дело это сугубо внутреннее для этой функции. А получается, что сделать такое невозможно.
Ну так и опиши эту функцию как класс с методом. А внутри этого класса определи структуру.
Здравствуйте, AndrewVK, Вы писали:
ПК>>Это поправимо в следующей версии спецификации. Жаль только, что темп работы комитетчиков столь нетороплив...
AVK>А в C++/CLI?
Только в C++/CLI это делать будет странно: ничего специфического для CLI в этой возможности нет. Данная возможность с разработчиками VC++ еще не обсуждалась, но я планирую сделать это в ближайшее время.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
AndrewVK,
> ПК> Только в C++/CLI это делать будет странно > > Ничего странного. С++/CLI, в отличие от С++, на комитет не подвязан и менять его значительно проще.
VC++ тоже к комитету не подвязан, и менять его ничуть не сложнее, чем C++/CLI. Точнее даже, ровно так же менять, даже в одном и том же месте, и даже одними и теми же разработчиками
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Sinclair, Вы писали:
PD>Честно сказать, мне эта дискуссия порядком надоела. Теперь уж точно в последний раз. Времени нет на эти пустопорожние споры.
PD>>>Sinclair, не стоит передергивать. Нигде я такого не говорил. Это просто практика всех, кто писал раньше на C++/Pascal. Об этом в любом учебнике по этим языкам написано. S>>Что именно написано?
PD>Почитай сам любой учебник.
PD>>>Ну нет так нет. Только одно добавим — в Шарпе нет. Потому как в других языках есть и используется. S>>Приведи причину.
PD>Там она и приводится.
S>>Да, совершенно верно. Тут вообще надо все рефакторить нафиг.
PD>Успехов!
PD>>>В моем примере — не думаю S>>А я тебе говорю. Сам видел совершенно аналогичный код. Отлаживаться — очень трудно.
PD>>>Ну что же, вот тебе пример. Порежь. Не буду возражать даже, если ты из этой функции 20 сделаешь. И размер у них небольшим совсем будет. Только тогда структуры A,B и т.д. неплохо бы внутри каждой из этих 20 функций соответственно и описать, а не выносить в класс. S>>Примера пока нету. Есть некоторые намеки на его структуру. По ним я нутром чувствую, что как раз в данном случае я бы вообще разнес это на 20 классов.
PD>Прекрасно. 20 классов, несколько десятков свойств и методов, интерфейс между ними и т.д. 30 сотраниц документации потом. И все это ради того, чтобы 20 структур сформировать и на устройство отправить. PD>Может, это все и верно, может, именно так и надо сейчас. Не знаю. Но если это именно так — неудивительно, что все это потом работает очень медленно , а памяти ест немеряно. Зато принципы ООП тут полностью в порядке.
Тебе бы Рихтера не мешало бы почитать на предмет типов .NET , а по поводу кода и некоторых советов не обязательно на 100% верных С. Макконнел "Совершенный код" ....
PD>>>Опять передергивание. Я же четко сказал — "в некотором смысле". Т.е. они существуют в рантайме, имеют свои поля (static members) и т.д. Я же не утверждаю, что тип есть переменная в C#. S>>Это уже радует.
PD>Я тоже рад, что ты это наконец понял.
PD>>>Кстати, в Object Pascal я это вполне могу утверждать — там есть переменная типа тип, даже с наследованием. S>>Нет, не можешь. Ты вообще путаешь понятия тип и переменная. Переменная — это экземпляр типа. В Delphi есть семейство типов для метаклассов. Никакого отношения к переменным оно не имеет. Ни в каком смысле.
PD>Опять двадцать пять. Я эе , кажется, ясно дал понzть, что говоря о типе, я имею в виду то, что это нечто, существующее в рантайме. Ты их называешь переменными метаклассов я — типами как переменными — от этого суть не изменится. Может, я не совсем точный термин употребил, но понять ИМХО можно было. Или ты впрямь думаешь, что я после 25 лет программирования определение (тип) от куска памяти (переменная) отличить не могу ?
