C++ vs Pascal Чей case круче

Здравствуйте...
Такой вопрос
в Паскале есть конструкция

x:=30;

case x of

1..10:{ что-то делаем};

12..15, 16..18: {что то делаем};

end;

как подобное организовать в C++.

Поддерживает ли сишный switch case такие извороты?

 

Delphi
Либо
case 1:
case 2:
...
case 10:
{}
break;
case 12:
...
case 15:
{}
break;
case 16:
...
case 18:
{}
break;

либо (так короче)
if (1 <= x && x <= 10) {}
else if (12 <= x && x <= 15) {}
else if (16 <= x && x <= 18) {}

 

А вот в Питоне можно написать, например
if x in [1,2,3]:

 

Delphi

Хм.. Первый раз слышу. Думал, только 1..10: begin end;

такое в делфи есть, кстати.

 

IceStudent
Да, в Дельфи такая конструкция используется с типом set. В Питоне имеется в виду список произвольной длины из объектов произвольной природы.

 

crypto
Да но в питоне можно и еще проще for x in range(3):

 

crypto
В сях можно еще значения switch через запятую писать.

IceStudent
такое в делфи есть, кстати.

Увы, множества в Delphi за предел 256 элементов не выходят. Совершенно не понимаю, почему эту полезную конструкцию никак не хотят расширять в течение 15 (или сколько там уже лет Turbo Pascal'ю и его продолжениям?) - ведь это, помимо прочего, готовый "массив битов", реализованный на уровне компилятора.

 

IceStudent
В таких скобках в Дельфи принято писать комментарии.

ЗЫ: В новом C++ можно будет в case писать строковые константы.

 

Quantum
А, это у него комментарии были.

Это хорошо, там ещё несколько вкусностей будет, только когда? MS успеет ещё парочку студий выпустить, потом они настолько тяжеловесны будут, что и новым C++ не захочешь пользоваться Разве что на gcc переходить.

CyberManiac

А зачем? Для мелких множеств и 256 байт хватает, а что побольше - не сложно и руками написать.

 

это и сейчас можно, если использовать доработки, например буст

 

IceStudent

У gcc вкусностей уже много. Те же вложенные функции поддерживаются. Но под Win32 я не могу назвать эту программу удобной (и производительной)...

 

censored
Буст - это хорошо, но смущает время компиляции шаблонов - зачастую предпочитаешь скорость компиляции подобным удобствам

 

CyberManiac, IceStudent
Множество в 256 элементов занимает 256/8=32 байта памяти - уже не хило, но оправдано для упрощения операций с set of char. Делать полнофункциональную поддержку множеств бОльшего размера (с операциями +,-,*) и смысла нет, и накладно. А если рассматривать set просто как массив бит (boolean), то для этого в дельфях есть класс TBits

 

Delphi
Мне лично больше такое использование case нравится

Код (Text):

1.   TTypeData = packed record
2.     case TTypeKind of
3.       tkUnknown, tkLString, tkWString, tkVariant: ();
4.       tkInteger, tkChar, tkEnumeration, tkSet, tkWChar: (
5.         OrdType: TOrdType;
6.         case TTypeKind of
7.           tkInteger, tkChar, tkEnumeration, tkWChar: (
8.             MinValue: Longint;
9.             MaxValue: Longint;
10.             case TTypeKind of
11.               tkInteger, tkChar, tkWChar: ();
12.               tkEnumeration: (
13.                 BaseType: PPTypeInfo;
14.                 NameList: ShortStringBase));
15.           tkSet: (
16.             CompType: PPTypeInfo));
17.       tkFloat: (
18.         FloatType: TFloatType);
19.       tkString: (
20.         MaxLength: Byte);
21.       tkClass: (
22.         ClassType: TClass;
23.         ParentInfo: PPTypeInfo;
24.         PropCount: SmallInt;
25.         UnitName: ShortStringBase;
26.        {PropData: TPropData});
27.       tkMethod: (
28.         MethodKind: TMethodKind;
29.         ParamCount: Byte;
30.         ParamList: array[0..1023] of Char
31.        {ParamList: array[1..ParamCount] of
32.           record
33.             Flags: TParamFlags;
34.             ParamName: ShortString;
35.             TypeName: ShortString;
36.           end;
37.         ResultType: ShortString});
38.       tkInterface: (
39.         IntfParent : PPTypeInfo; { ancestor }
40.         IntfFlags : TIntfFlagsBase;
41.         Guid : TGUID;
42.         IntfUnit : ShortStringBase;
43.        {PropData: TPropData});
44.       tkInt64: (
45.         MinInt64Value, MaxInt64Value: Int64);
46.   end;

 

leo

Почему это смысла нет? Мне, к примеру, множества с числом элементов до тысячи были нужны не так уж редко. А накладные расходы на реализацию таких множеств ненамного выше, чем на 256-элементные.

Классы хороши для более высокоуровневых абстракций. Но вот с битами... В общем, обычно биты нужны в несколько иных ситуациях, чем те, для которых особо актуально ООП. И обертывание битов в ООП - это еще более накладно, чем расширить возможности множеств.

 

CyberManiac
Как я уже сказал у max=256 есть разумное обоснование - set of char. Не ограничивать вообще ес-но нельзя, т.к. нерадивые "школьники" могут и set of integer замутить А если ограничить "до тысячи элементов", то всегда найдутся критики которым и этого покажется мало Поэтому и выход простой - до 256 пользуемся статическим set, а больше - динамическими структурами типа TBits или пишем сами - хошь на паскале, хошь на асме

При использовании статических методов вся "накладность" ООП выливается в косвенные ссылки на поля типа mov eax,[eax].FBits, зато в замен получаем возможность динамического расширения и удобство обращения к битам через дефолтное свойство Bits:=true

 

leo
Не ограничивать вообще ес-но нельзя, т.к. нерадивые "школьники" могут и set of integer замутить

На ну и пофиг на "школьников" - массив [1..MaxInt] of Byte тоже никто не запрещал, хотя 99% компов от такого массива подохнут в мучениях. А у меня такой set даже в память влезет, хоть и в единственном экземпляре. В общем, лучше все же иметь, чем не иметь

 

CyberManiac
Кстати, в разделе коммерции некто Hugo Chaves, предлагавший написать генератор ключей, дал ссылку на программу, из которой можно взять полный набор функций, работающих с битовыми полями произвольной длины.