In the document
(http://www.freepascal.org/docs-html/ref/refsu15.html#x38-450003.3.2) I read the code below:

Type
  MyRec = Record
          X : Longint;
          Case byte of
            2 : (Y : Longint;
                 case byte of
                 3 : (Z : Longint);
                 );
          end;

I still cannot understand what do these two "byte" mean. I have difficulty in understanding "The optional identifier in the case statement serves to access the tag field value, which otherwise would be invisible to the programmer" and need some explain. Thank you.

Another problem is about Object and Class. I notice that in wiki (http://wiki.freepascal.org/Object_Oriented_Programming_with_FreePascal_and_Lazarus), Class is explained as a pointer to the structure, while Object returns the whole structure. And the wiki said that Object is not used very much. Does this mean that Object is deprecated? Can Objects contain any properties?

2009/10/6 章宏九 :

Look at the second example on this page:

http://delphibasics.co.uk/RTL.asp?Name=Record

Look at this page for an explanation of the basic difference:

http://freepascal.org/docs-html/ref/refch6.html

I can't really comment on the scary details, since I'm rubbish at object oriented programming :)

Henry

I think the cases are useless here. AFAIK the case inside record is utilized to give multiple options of use for the same memory area. It is used so that the same structure can have multiple uses without wasting space. But this is pointless if the case has only 1 option, it should have 2 or more to make sense. For me the above is the same as:

Type
  MyRec = Record
     X : Longint;
     Y: Longint;
     Z: Longint;
  end;

I think that visibility isn't in place because even with multiple options you can access any of them at any given time even if they conflict.

And the wiki said that Object is not used very much. Does this mean that Object is deprecated?

Deprecated means that the feature will or may be removed in the future, but AFAIK there are no plans to remove support for Object. So I would say it's a legacy feature (from Turbo Pascal), but not deprecated at the moment.

If you are not sure which one to use, then just use classes.

2009/10/6 Henry Vermaak :

I can't really comment on the scary details, since I'm rubbish at object oriented programming :)

And objects aren't deprecated, since the compiler uses them (afaik).

Henry

Yup. Like you say, this is a wierd example.

It's called a "variant record". Google for that term. http://www.delphicorner.f9.co.uk/articles/op6.htm
That means, a record structure where one or more fields occupy the same memory, but have different types. Like a union in C. So depending on which field you read, the memory area can be read in different types.

So if you have
Type
   MyRec = Record
     Case byte of
     1: (X : Integer;);
     2: (Y : Word;);
   end;
var
   v : MyRec;
Begin
   v.y := 65535;
   writeln(v.x);
end.

assigning 65535 to v.y sets the underlying bytes to $FF, $FF so v.X is -1.

Now, one would not normally do this (writing to one field and reading the other). If you write to one field, the memory under the other one(s) is messed up. So you should only read from the field that you write to.

How do you know which field to read from?

Normally, you would have a tag field. This is a field with a specific ordinal type coming before the variant fields.

Type
   MyRec = Record
     Case FieldType:byte of
     1: (X : Integer;);
     2: (Y : Word;);
   end;

Now, if you are writing to field X, you should write a 1 to FieldType. Elsewhere in your program, you can read FieldType, and if it is 1 you read x. If it is 2 you read y. And if it is some other value you output an error message...

I think the syntax with just a type and no tag field name (case byte of) was invented afterwards, to handle the case when you don't want a tag field.

...

Object was introduced in the first object-oriented Borland Pascal, TurboPascal 5.5. To use polymorphism, you access objects through a pointer (because if you say var o:tMyObject; then you *know* what type it is). When Delphi came along, seems Borland decided that everyone should *always* use pointers for object types, and introduced the Class, which is always on the heap and handled as a pointer. Any new concepts that were introduced, like properties, were applied only to the new classes and objects were left in a corner, like the embarrassing relative that you wish you could get rid of, but can't. IMHO objects are the less confusing of the two, but they seem to be, not quite deprecated, but discouraged. So as Felipe said:

If you are not sure which one to use, then just use classes.

FP

Thank you. I saw all the examples you gave, but I still cannot master how to use a variant record without a specified tag.

For example:
type
  TShapeList = (Rectangle, Triangle, Circle, Ellipse, Other);
  TFigure = record
    case TShapeList of
      Rectangle: (Height, Width: Real);
      Triangle: (Side1, Side2, Angle: Real);
      Circle: (Radius: Real);
      Ellipse, Other: ();
  end;
var
  Figure1: TFigure;

How can I specified the TShapelist value in a Figure1?

2009/10/6 Henry Vermaak :

2009/10/6 章宏九 :

You can specify an identifier in the case statement, which will become a new field. You can then specify what the record is used for currently, e.g.:

TShapeList = (Rectangle, Triangle, Circle, Ellipse, Other);
TFigure = record
  case Shape: TShapeList of
          ^^^^^^^
    Rectangle: (Height, Width: Real);
    Triangle: (Side1, Side2, Angle: Real);
    Circle: (Radius: Real);
    Ellipse, Other: ();
  end;

Then you can set .Shape to Rectangle, for instance, and fill in .Height and .Width. A function receiving a variable of this record can then see what shape it is currently used for. You need to maintain this .Shape field, though.

Henry

Thank you. I saw all the examples you gave, but I still cannot master how to use a variant record without a specified tag.

If you use a specific tag as in

type TFigure = record
                case ShapeName : TShapeList of
                   Rectangle: (Height, Width: Real);
                   Triangle: (Side1, Side2, Angle: Real);
                   Circle: (Radius: Real);
                   Ellipse, Other: ();
                   end;

then you will get an additional part in your record named "ShapeName" which can (but not necessarily must) be used to store the meaning of the record variants. If you don't use such a variable name as in

type TFigure = record
                case TShapeList of
                   Rectangle: (Height, Width: Real);
                   Triangle: (Side1, Side2, Angle: Real);
                   Circle: (Radius: Real);
                   Ellipse, Other: ();
                   end;

then you have to detect the meaning of the variants in some other way. In both cases you can directly access the variants as in TFigure.Triangle or TFigure.Rechtangle. But if you stored with one variant and read with another you will get a lot of mess. ;-)

AFAIK there has to be some fixed part before the variant, e. g.

TFigure = record
    name: string;
    case TShapeList of
      Rectangle: (Height, Width: Real);
      Triangle: (Side1, Side2, Angle: Real);
      Circle: (Radius: Real);
      Ellipse, Other: ();
  end;

The program could then determine from the contents of the "name" field which variant is used in a certain instance. This saves memory ("TShapeList" has no memory reserved at run time), but the program is responsible to correctly identify the variant using the "name" field.

Anton

I see. That means if no tag name is given, I should make sure my code is correct by myself.

Thank you.

2009/10/7 Anton Tichawa :

How would that work? "name" is just a string which you can assign an arbitrary value to. The compiler cannot store additional information in it.

The detection of the correct variant is completely up to the programmer. There is no help by the compiler.

Therefore, there is absolutly no difference between

TFigure = record
           X : TShapeList;
           case TShapeList of
              Rectangle: (Height, Width: Real);
              Triangle: (Side1, Side2, Angle: Real);
              Circle: (Radius: Real);
              Ellipse, Other: ();
              end;

and

TFigure = record
           case X : TShapeList of
              Rectangle: (Height, Width: Real);
              Triangle: (Side1, Side2, Angle: Real);
              Circle: (Radius: Real);
              Ellipse, Other: ();
              end;

It ends up in the same record and also the programmer does not see any difference. He can store whatever he wants in X in both cases. It has no influences on the variants.

True. The second example has better style, though.

But the point is that X can be completely omitted.

E. g. you have the freedom to encode the information contained in X in some other way. It might be derived from a name or a part number.

Anton

Frank Peelo wrote

Any new concepts that were introduced, like properties, were applied only to the new classes and objects were left in a corner, like the embarrassing relative that you wish you could get rid of, but can't.

However, AFAIK Free Pascal supports properties in objects as well as global properties (that is properties, that act like a global variable, outside any object or class). But that's a Free Pascal specific extension, it's not supported by Delphi. Which is a non-issue for me, since I only use FPC these days :)

IIRC, there is a difference. With the second declaration the compiler can add a run-time check that the correct memebrs are accessed based on the value of X.

Unfortunately, I cannot find the compiler switch.

Vincent

FPC has no support for this.

Jonas

Then I did not remember correctly: I thought you implemented it. :-)

Vincent

Actually I though too that Jonas implemented this once :)

I once started working on it, but never finished it (and the variantcase.patch file in my compiler dir is extremely small, so I never got very far either).

Jonas

And I don't know any other Pascal Compiler who does any checks in this direction. Do some?

Jürgen Hestermann wrote

And I don't know any other Pascal Compiler who does any checks in this direction. Do some?

I don't know, but ADA reportedly does. Such a feature definitely seems useful to me.

Jonas

Afaik GPC does as well?

Given that the OP was asking about learning, maybe it would be worth mentioning that the way we normally have "data structures which hold different data" these days is by polymorphism in objects or classes.

Instead of having an array of variant records, each of which might hold a description of a circle, square or pentagon depending on the value of a tag variable, we would now have an array of Shape, where Shape is a class instance or pointer to an object. The actual elements of the array would be Circle, Square or Pentagon, where these are types descended from Shape.

This has several benefits, not least the fact that new shapes can be added more easily than in the variant record case.

The stuff that has been said about variant records is all good, and variant records still have uses in some cases, but we don't want to mislead the OP into thinking that this is necessarily the way to go with new programs.

FP

But if you look at it closely OP boils down to the same fundamental "pointers pointing to memory" logic too. You only don't tell the user. And that's something I hate with OP: You don't know what happens in detail (at least, it mostly isn't told you in any help about a programming language). I have a clear imagination about pointers pointing to memory addresses and variant records. But how are arrays of different objects (with different sizes) implemented? I suspect that it's simply an array of pointers pointing to the objects (spread all over the heap). But noone tells the users so they don't know exactly what happens under the hood and therefore may choose bad designs.

This has several benefits, not least the fact that new shapes can be added more easily than in the variant record case.

If you code this by yourself (array of pointers pointing to variant records) then it's the same as your OP design but at least you know how it is coded and where it can be optimized.

> And I don't know any other Pascal Compiler who does any checks in this > direction. Do some? I don't know, but ADA reportedly does.

I don't know the differences to Pascal. Does it have the same syntax for variant records?

Such a feature definitely seems useful to me.

Of course it would be. But how should it work? Setting the tag variable when assigning a value and raising an error when reading with different variant? Then what if the tag variable is changed directly? Or should it be readonly (which would make sense IMHO).

"Jürgen Hestermann" :

>> And I don't know any other Pascal Compiler who does any checks in >> this direction. Do some? > I don't know, but ADA reportedly does.

Yes, but the semantics of discriminants is slightly different than in PASCAL.

I don't know the differences to Pascal. Does it have the same syntax for variant records?

No.

Of course it would be. But how should it work? Setting the tag variable when assigning a value and raising an error when reading with different variant? Then what if the tag variable is changed directly? Or should it be readonly (which would make sense IMHO).

Well, variant records with read-only discriminants don't make much sense IME. They are just too inflexible.

In Ada both variants (discriminant is constant or changeable) are supported. To change the discriminant of such a (unconstrained) variable a whole-record assignment is needed, constrained variables (discriminant is initialized at declaration time) can't change their discriminant anymore. So validity checks can be done on both read and (partial) write accesses.

With the current state of FPC, discriminant-checked records with changeable discriminants would be possible without changing rules or syntax. If you want them read-only the rules must probably change. ;)

Vinzent.

FWIW, here is a link to the BNF of the Ada Programming Language: http://www.seas.gwu.edu/~adagroup/ada95-syntax/
Jerry