Здравствуйте, samius, Вы писали:
S>Однако в условии нет указания по поводу того что Close должен быть обязательно после Open. Нужно лишь проверить равенство числа вызовов.
Да, это я домыслил. Но легко исправить:
public class Box<T>
{
readonly private T value;
public Box(T value)
{
this.value = value;
}
public T Unbox() { return value; }
}
public class AntiBox<T>
{
readonly private T value;
public AntiBox(T value)
{
this.value = value;
}
public T Unbox() { return value; }
}
public static class Utils
{
public static Box<T> Open<T>(this T x)
{
return new Box<T>(x);
}
public static T Close<T> (this Box<T> box)
{
return box.Unbox();
}
public static T Open<T>(this AntiBox<T> box)
{
return box.Unbox();
}
public static AntiBox<T> Close<T> (this T x)
{
return new AntiBox<T>(x);
}
}
class Program
{
static void Main()
{
int i = 1.Close().Open().Open().Close().Open().Close().Close().Open(); //OK
//int i = 1.Open().Close().Open().Close().Close(); //Error
}
}
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, samius, Вы писали:
S>>И сыграть на констрейнтах к Check... ПРавда пока не очень представляю, как именно.
K>Это примерно то же самое, что и с присваиванием, если считать что Check() — метод типа, к которому принадлежит значение x, констрейнты тут вообще не нужны, да и вообще с Check — не интересно.
Я тоже пришел к тому что нужно присванивание и рекурсивный полиморфизм. Но смутился замечанием ТС что присваивание не суть важно.
K>А без Check или присваивания, я думаю, не сделать, ведь каждое подвыражение обязано быть корректным само по себе. Вот если бы компилятор выдавал ошибку "значение выражения ничему не присвоено" для всего кроме void, тогда можно было бы и без Check и без присваивания обойтись.
угу
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Константин Л., Вы писали:
КЛ>>в с++ получилось бы еще красивее
S>Зачем так сложно? Достаточно варианта ув. Пельмешко: S>
Здравствуйте, dotneter, Вы писали:
D>Здравствуйте, Аноним, Вы писали:
D>Я же написал, что главное в балансировке, как она будет достигнута не столь важно. D>x.Open()... это псевдокод показывающий суть а не реализацию.
Ну код вроде автоматом понятен. Наследуем класс от IDisposable, в диспозе вызываем private/protected Close, open защищаем от повторного вызова. При таком методе просто невозможно получить разбалансировку и при этом Close вызывается автоматом при "неиспользовании" объекта. Можно и как-то по другом сделать, но важно чтобы Close вызывалось "автоматом", а не было доступно пользователю.
Re: [Этюд]Балансировка вызовов функций.
От:
Аноним
Дата:
25.02.11 08:47
Оценка:
А где это может потребоватся? Какой практический смысл такого кода?
Здравствуйте, Аноним, Вы писали:
А>А где это может потребоватся? Какой практический смысл такого кода?
Во первых, "этюд" может и не нести никакой пользы.
Во вторых, открывать и закрывать что-то приходится довольно часто.
Достаточно варианта ув. Пельмешко:
