Я правильно понимаю, что в C# нельзя описать структуру внутри функции, чтобы она только в ней и была видна
class A
{
void f()
{
struct MyStruct{
int m,n;
};
}
};
Компилятор такое не пропускает. В C++ такое допустимо.
Если да — как лучше скалькировать это с С++ на С# ? Вариант выноса стуктуры на уровень класса не годится — в функции g на С++ может быть описана другая стуктура с тем же именем.
26.09.05 21:49: Перенесено модератором из '.NET' — TK
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я правильно понимаю, что в C# нельзя описать структуру внутри функции, чтобы она только в ней и была видна
Да. (И слава богу)
PD>Если да — как лучше скалькировать это с С++ на С# ? Вариант выноса стуктуры на уровень класса не годится — в функции g на С++ может быть описана другая стуктура с тем же именем.
Ну и что? Заведи класс _serviced или еще какой и туда засунь эту структуру.
A>Ну и что? Заведи класс _serviced или еще какой и туда засунь эту структуру.
Не понял. Что изменится в плане видимости, если я структуру засуну в класс ?
Кто помешает создавать экземпляры этого класса где бы то ни было ? А я хочу только в данной функции
Вот пример на C++
class MyClass
{
void f(void)
{
struct A {
int x,y;
};
// any code can use this type A (2 int fields)
}
void g(void)
{
struct A {
float a,b,c;
};
// any code can use this type A (3 float fields)
}
void h()
{
// no A declaration so type A can't be used
}
};
// no A declaration so type A can't be used
1.В функции f есть тип A — struct из 2 int. За пределами функции f он не существует.
2.В функции g есть тип A — struct из 3 float. За пределами функции g он не существует.
3.За пределами f и g никакого типа А вообще не имеется. Нельзя использовать тип A ни в других функциях класса MyClass, ни за пределами класса MyClass
Если не сложно, перепиши на C#, соблюдая требования 1-3.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Кто помешает создавать экземпляры этого класса где бы то ни было ? А я хочу только в данной функции
Таких параноидальных типов видимости в .NET не бывает.
Здравствуйте, Mab, Вы писали:
Mab>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Кто помешает создавать экземпляры этого класса где бы то ни было ? А я хочу только в данной функции Mab>Таких параноидальных типов видимости в .NET не бывает.
Я бы все же просил придерживаться политкорректности. Такие типы видимости существуют в Паскале, С/C++, из чего не следует, что эти языки являются параноидальными.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я бы все же просил придерживаться политкорректности. Такие типы видимости существуют в Паскале, С/C++, из чего не следует, что эти языки являются параноидальными.
О, ну прошу прощения, забыл добавить ИМХО. Так вот ИМХО это и есть чистой воды паранойя. Ибо такая возможность решает несуществующую проблему. Объявление типа в виде приватного члена объемлющего класса ничем не хуже.
Здравствуйте, Mab, Вы писали:
Mab>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Я бы все же просил придерживаться политкорректности. Такие типы видимости существуют в Паскале, С/C++, из чего не следует, что эти языки являются параноидальными. Mab>О, ну прошу прощения, забыл добавить ИМХО. Так вот ИМХО это и есть чистой воды паранойя.
Вытащил с одного сайта определение паранойи.
Паранойя, психическое нарушение, характеризующееся подозрительностью и хорошо обоснованной системой сверхценных идей, приобретающих при чрезмерной выраженности характер бреда
Не совсем понятно, при чем здесь подозрительность, а тем более сверхценные идеи
>Ибо такая возможность решает несуществующую проблему. Объявление типа в виде приватного члена объемлющего класса ничем не хуже.
А вот это опросил бы подробнее прокомментировать. Насколько я понимаю, такое объявление позволит мне создавать экземпляры этого объекта где бы то ни было внутри класса, так ?
Предположим, что класс огромный по размеру кода (я сказал "предположим", это не надо сейчас обсуждать с точки зрения хорошего стиля программирования), а поэтому его разработка поручена нескольким человекам. Им по ходу работы нужно создавать структуры (пусть даже не классы!), чтобы просто не иметь сотен переменных. Значит, им придется согласовывать друг с другом имена этих структур, так ? Ведь описания этих структур надо выносить на уровень класса ?
Или я что-то не так понял ?
With best regards
Pavel Dvorkin
Re[5]: Структура внутри функции
От:
Аноним
Дата:
21.09.05 07:30
Оценка:
Объявление типа в виде приватного члена объемлющего класса ничем не хуже.
--------------
Только если таких типов штук 10 и каждый из них используется только в отдельно взятой функции, уже не будет казаться таким параноидальным.
2 Автор
Используй C#3 Там есть неименованные структуры
А если серьёзно:
Если да — как лучше скалькировать это с С++ на С# ? Вариант выноса стуктуры на уровень класса не годится — в функции g на С++ может быть описана другая стуктура с тем же именем.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А вот это опросил бы подробнее прокомментировать. Насколько я понимаю, такое объявление позволит мне создавать экземпляры этого объекта где бы то ни было внутри класса, так ?
PD>Предположим, что класс огромный по размеру кода (я сказал "предположим", это не надо сейчас обсуждать с точки зрения хорошего стиля программирования), а поэтому его разработка поручена нескольким человекам. Им по ходу работы нужно создавать структуры (пусть даже не классы!), чтобы просто не иметь сотен переменных. Значит, им придется согласовывать друг с другом имена этих структур, так ? Ведь описания этих структур надо выносить на уровень класса ? PD>Или я что-то не так понял ?
Не забывай про метаданные.
В каком неймспейсе, например, будет находиться эта структура?
Конечно, я согласен, что афторы C# зря убрали возможность создавать временные структуры в теле функции, но ничего не поделать.
С другой стороны, это не дает тебе писать в плохом стиле, когда тело функции занимает несколько экранов и в связи с этим нефтыкаемо методом окидывания взглядом.
Так что это ограничение на самом деле тебе самому и на пользу.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А вот это опросил бы подробнее прокомментировать. Насколько я понимаю, такое объявление позволит мне создавать экземпляры этого объекта где бы то ни было внутри класса, так ?
PD>Предположим, что класс огромный по размеру кода (я сказал "предположим", это не надо сейчас обсуждать с точки зрения хорошего стиля программирования), а поэтому его разработка поручена нескольким человекам. Им по ходу работы нужно создавать структуры (пусть даже не классы!), чтобы просто не иметь сотен переменных. Значит, им придется согласовывать друг с другом имена этих структур, так ? Ведь описания этих структур надо выносить на уровень класса ? PD>Или я что-то не так понял ?
Тут вопрос философский. .NET как платформа для разработки заодно подразумевает некоторый стиль написания кода под нее. Свойство это выражено намного сильнее, чем, скажем, в C++, где одно и то же можно описать десятью различными способами, а потом еще удивляться, отчего сосед делает это 11-м. Платформа подразумевает этот стиль временами весьма навязчиво, так что написание кода не следуя ему становится довольно затруднительным.
Поэтому не стоит удивляться, отчего платформа не дает и дальше писать код в старом стиле, делая этот "огромный" класс еще более огромным. Рефакторинг поможет решить эту проблему, благо в C# инструменты для него имеются (в отличие от C++ и Pascal).
Здравствуйте, MatFiz, Вы писали:
MF>С другой стороны, это не дает тебе писать в плохом стиле, когда тело функции занимает несколько экранов и в связи с этим нефтыкаемо методом окидывания взглядом.
Не хочу я писать в плохом стиле. Я наоборот хочу в хорошем писать
Ситуация. Пишу я функцию. В ней штук 10 переменных, описывающих некоторый внутренний для этой функции объект (слово объект в общечеловеческом смысле, а не в смысле языка). В соответствии с правилами хорошего стиля стоит из них создать структуру, чтобы обращаться к этим переменным как к некоторому единому целому. Ну хоть скопировать их все в другой набор таких же переменных (для другого объекта).
Все это интересно в данной функции. За пределами этой функции такая структура никому не нужна, да и вообще желательно, чтобы о ней никто не знал, потому как дело это сугубо внутреннее для этой функции. А получается, что сделать такое невозможно.
MF>Так что это ограничение на самом деле тебе самому и на пользу.
Mab>Тут вопрос философский. .NET как платформа для разработки заодно подразумевает некоторый стиль написания кода под нее. Свойство это выражено намного сильнее, чем, скажем, в C++, где одно и то же можно описать десятью различными способами, а потом еще удивляться, отчего сосед делает это 11-м. Платформа подразумевает этот стиль временами весьма навязчиво, так что написание кода не следуя ему становится довольно затруднительным.
А кстати, если можно, еще один вопрос. Не в курсе, как в managed C++ с этим дело обстоит ? В С++ это разрешается! Или в managed запретили, или все же дело не в .Net, а только в C# ?
Mab>Поэтому не стоит удивляться, отчего платформа не дает и дальше писать код в старом стиле, делая этот "огромный" класс еще более огромным. Рефакторинг поможет решить эту проблему, благо в C# инструменты для него имеются (в отличие от C++ и Pascal).
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А кстати, если можно, еще один вопрос. Не в курсе, как в managed C++ с этим дело обстоит ? В С++ это разрешается! Или в managed запретили, или все же дело не в .Net, а только в C# ?
Нет не запретили. Это эмулируется через объявление в сборке в отдельном неймспейсе структуры с compile-generated именем.
PD>Ладно, насчет "огромного" класса возражение приму. Но остается другое возражение, я его привел в ответе MatFiz (http://www.rsdn.ru/Forum/Message.aspx?mid=1393827&only=1
)
Сложно посоветовать в общем случае. Периодически на работе приходится сталкиваться с тем, что алгоритм работы отдельных функций и количество требуемых им описаний типов начинает превышать допустимые лимиты (мы, в частности, пишем код для обсчета транспортных графов, где проблемы в первую очередь алгоритмические). В такой ситуации подходящим решением оказывается выделение каждого из этих алгоритмов в отдельный класс. Вообще принцип простой: как только становится ясно, что дальнейшее наращивание размера класса приводит к трудностям при сопровождении, -- значит нужно делать рефакторинг и резать класс на более мелкие.
Re[8]: Структура внутри функции
От:
Аноним
Дата:
21.09.05 08:32
Оценка:
Ну не пойму чем тебе Hastable не нравится?
class Class1
{
public Hashtable FuncA()
{
Hashtable result = new Hashtable();
result.Add( "m", 10 );
result.Add( "n", 5 );
return result;
}
public Hashtable Func2()
{
Hashtable result = new Hashtable();
result.Add( "Cost", (double)10 );
result.Add( "MySpecificData", new MySpecificObject() );
return result;
}
}
Здравствуйте, Mab, Вы писали:
Mab>Сложно посоветовать в общем случае. Периодически на работе приходится сталкиваться с тем, что алгоритм работы отдельных функций и количество требуемых им описаний типов начинает превышать допустимые лимиты (мы, в частности, пишем код для обсчета транспортных графов, где проблемы в первую очередь алгоритмические). В такой ситуации подходящим решением оказывается выделение каждого из этих алгоритмов в отдельный класс. Вообще принцип простой: как только становится ясно, что дальнейшее наращивание размера класса приводит к трудностям при сопровождении, -- значит нужно делать рефакторинг и резать класс на более мелкие.
Это ответ на несколько не тот вопрос, который я там задал
Но в общем все понятно. Нет их, и все тут, а дальше можно философствовать на тему, хорошо это или плохо, до бесконечности.
Здравствуйте, k_savelev, Вы писали:
_>Ну не пойму чем тебе Hastable не нравится?
_> class Class1 _> { _> public Hashtable FuncA() _> { _> Hashtable result = new Hashtable(); _> result.Add( "m", 10 );
Хорошенькое дело! В структуре список полей жестко определен, несуществующее поле употребить просто невозможно. А здесь пиши, что хочешь! И потом стуктура все же в стеке лежит, доступ к ней прямой, а тут поиск в Hashtable.
Здравствуйте, Mab, Вы писали:
Mab>Здравствуйте, Pavel Dvorkin, Вы писали:
Mab>Это относится ко всем типам. Они могут быть описаны лишь внутри структур, классов или пространств имен.
Вот это уже черт знает, что такое. Получается, что внутри функции и набор констант определить нельзя!
Там есть неименованные структуры
