To me it seems like some kind of trick, to extend a empty record field, functions as a sort of offset/label/pointer if you will to the new fields that will will be extended to the record by simply allocating more memory then the size of the record.

Then this "label"/"field" can be used as a sort of offset, by typecasting it to some extension record type.

Could be pretty handy, quite impressive trick.

However, is it safe to use ?

I cannot find anything in the documentation about this ?

Seems to be an old trick as well.

Gonna copy this stuff and ask on free pascal compiler list, maybe they know something about this ;) I wonder if free pascal supports this trick as well ;)

Bye,
Skybuck.

"Skybuck Flying" wrote in message

Op Fri, 15 Feb 2008, schreef Skybuck Flying:

Empty records are valid Pascal.

I cannot find anything in the documentation about this ?

Nothing in the documentation says it is forbidden either. The reason it is not explicetely mentioned is because there exists a much better method, objects:

type  base_structure=object
         field1:byte;
       end;
       extended_structure=object(base_structure)
         field2:byte;
       end;

Daniël

What's the benefit of using objects ?

One drawback of objects already discovered:

Objects cannot have the same field identifiers.

A problem that does not exist with records, and empty records.

// object example, pointers and typecasts still necessary.
program Project1;
{$APPTYPE CONSOLE}
uses
  SysUtils;
type
 PethernetHeader = ^TethernetHeader;
 TethernetHeader = object
  SomeFields1 : packed array[0..13] of byte;
 end;
 PipHeaderVersion4 = ^TipHeaderVersion4;
 TipHeaderVersion4 = object(TethernetHeader)
  SomeFields2 : packed array[0..19] of byte; // first problem, identifier
redeclared, numbers used to fix it.
 end;
 TudpHeaderVersion4 = object(TipHeaderVersion4)
  SomeFields3 : packed array[0..7] of byte;
 end;
 TtcpHeaderVersion4 = object(TipHeaderVersion4)
  SomeFields4 : packed array[0..19] of byte;
 end;
 Tframe = object
  SomeFields5 : packed array[0..66000] of byte;
 end;
procedure Main;
var
 frame : Tframe;
begin
 frame.SomeFields5[14] := 234;
// TethernetHeader(frame). // typecast not possible.
// with frame as TethernetHeader do // operator not applicable
// begin
//  SomeFields5[4] := 123;
// end;
 // maybe pointers can help
 writeln( PipHeaderVersion4(@Frame).SomeFields2[0] );
end;
begin
  try
 Main;
  except
 on E:Exception do
   Writeln(E.Classname, ': ', E.Message);
  end;
  readln;
end.

Bye,
Skybuck.

Well ok,

I see one benefit of using objects so far.

No extension field needed per record/object, makes the code less complex ;)

Bye,
Skybuck.

One drawback of objects already discovered: Objects cannot have the same field identifiers.

Indeed, especially if you want to win an obfuscation contest.

For records, I would use an extension field like:

IP.Payload

and

UDP.Payload

I would hardly call that obfuscation :)

Bye,
Skybuck.

Florian Klaempfl ha scritto:

ok, this is true for object type, but it should not be extended to class types. Look at this example taken from Delphi Help:

type
   TAncestor = class
     Value: Integer;
   end;
   TDescendant = class(TAncestor)
     Value: string;  // hides the inherited Value field
   end;
var
   MyObject: TAncestor;
begin
   MyObject := TDescendant.Create;
   // MyObject.Value := 'Hello!';  // error
   TDescendant(MyObject).Value := 'Hello!';  // works!
end;

it compiles correctly in Delphi (5 and 7) but FPC (v2.2.0 - compiled with Params Values=" -S2cdgi -OG1 -gl -WG -vewnhi") still says that there is a duplicate identifier "Value"...

am I correct?

This is not allowed in {$mode objfpc}, because of the reasons Florian memtioned. It is allowed in {$mode delphi}.

Vincent

var MyObject: TAncestor;

This is the problem.

it compiles correctly in Delphi (5 and 7)

Are you sure? It fails on my Delphi 7.

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

Vincent Snijders ha scritto:

errr... I tryied various combinations of options before posting, but did not try {$mode Delphi}... :-(

going back to read the manuals...

to Bee: Not so sure now, compilation depends on a lot of details...

-S2 is the same as {$mode objfpc} and -Sd is the same as {$mode delphi}. With -S2cdgi you are trying to set both {$mode objfpc} (-S2) and {$mode delphi} (-Sd). There is a bug in the compiler though, because for some reason -S2d does not seem to properly set Delphi mode (or unset objfpc mode) while it should.

Jonas

But the whole idea of inheritance is that child fields and methods are also available in UDP.

Have a look at a basis OOP tutorial.

Having the same name for different things is always obfuscation.

In every language I know, words can have multiple meanings.

The context in which the words are used determines their meaning.

One possible reason could be because there is so much to describe that coming up with unique words might be impossible or inpractical.

Bye,
Skybuck.

In every language I know, words can have multiple meanings.

Natural languages yes. But they need a billion neurons that is trained for 20 years to interpret, not a simple automaton.

IOW, lots of computer languages don't.

One possible reason could be because there is so much to describe that coming up with unique words might be impossible or inpractical.

I think the main reason is that brains naturally don't process information _without_ context. It's not just words, but also intonation, facial expression of the speaker, posture etc.

Abstracting is a learned skill.

The context in which the words are used determines their meaning.

And that's exactly the problem: good code is understandable with as little as possible context. Any context depending behaviour/meaning makes code less readable and less maintainable.

There is another great limitation of your suggested solution.

The offsets for the objects are bound at compile time.

While the record solution allows the offsets to be determined at run time.

Making the record solution a more flexible solution.

In other words objects need to specify their ancestor at compile time creating the inflexibility.

The make things even worse. For every possibility a new object declaration would be needed and finally it would be an unacceptable solution because this would probably add runtime type information to the objects thereby adding unwanted fields.

However there might be a different solution which might still be interesting:

1. Non-inherited objects.

2. Maybe empty objects ?

I shall investigate those later on.

Bye,
Skybuck.

Finally there is another question remaining:

Are objects always packed ?

If not then it could be a problem.

Something which records do allow.

Bye,
Skybuck.

Op Sun, 24 Feb 2008, schreef Skybuck Flying:

Finally there is another question remaining: Are objects always packed ?

No, to get packed objects you have to declare them packed. A record and object with the same field list have the same binary layout.

Daniël

There is another major drawback to your supposedly better method:

Object inheritance forces all fields to be accessable from the root:

SomeRoot.SomeField := ...;

While nesting has nice grouping:

SomeRoot.SomeHeader.SomeOtherHeader.SomeField := 5;

Bye,
Skybuck.

Op Fri, 29 Feb 2008, schreef Skybuck Flying:

I'd say it is a metter of taste. Anyway, you are free to use any method you like as both are valid code. End of discussion.

Daniël