[fpc-devel] va(r)_arg vs open array

[Daniël Mantione]

Op Mon, 2 Oct 2006, schreef ik:

> > > 2. The usage of [].
> > 
> > Same. Penalty for being safe. It is also required being able to mix non
> > array of const and normal parameters.
> 
> What is the difference ? I mean, what is the difference between
> fnc(a,b,c,d,e,f,g,h,i,j);
> and
> fnc(a,[bcdefghij]);
> ?

It is fnc(a,[b,c,d,d,e,f,g,h,i,j]).

But let's separate the syntactic issue from the functionality:

* Syntactically, both methods can be safe.
* Syntactically, the FPC/Delphi one is more powerfull.
* Functionally, the C method is not safe, while the FPC/Delphi one is.
* Functionally, the FPC/Delphi method has more runtime overhead than the
  C one.

> The [] is the same as "InitbyObject". It's informative, but not really needed.

The [] is the mechanism that allows you to pass multiple arrays.

> > > 3. Even empty parameter must have [] instead of not calling it. It's
> > > like C that must have empty () when calling a function ...
> > 
> > C has no checking what so ever, we want to do better.
> 
> Cool, but if you want to do better, then lets get one step further and
> say that nil value does not need to be "0 amount of values" in the
> parameter usage itself. Why not just to check
> 
> if (not openarray = nil) then ...
> 
> ?

Huh, I don't understand this?

> > 
> > > 4. I can't add default values to that type of parameter.
> > 
> > Can you in C?
> 
> No, but Pascal is better then C imho ... :) and as long as we have
> "var", "const" or "value" we should have default value (if we wish)
> imho ...

Well, if it were to the Free Pascal developers, there would be no default 
values at all :) We heavily grumbled when we had to implement it to be 
Delphi compatible.

> Lets say I wish to have the following procedure:
> 
> Writeln
> 
> Now even if I do not have any value inside, I want a value to print,
> lets say #0, why should I start making "if" and checks to see the
> length of the openarray, when I can just "print" the value for
> example.

I don't understand this either. 

> > > 5. Feel like an hack.
> > 
> > Where do you get that feeling?
> 
> "OK, so I don't have a way to make a compiler voodoo magic, but I can
> use an open array to get the closer feeling", but as Daniel say, in
> order to complete the usage of such thing, I need a synthetic sugar,
> and that does not implemented... It does not feel native ... it feels
> like a patch/hack that was added to shout people up when they say "you
> do not have var args".

On the contrary. I think we can consider constant arrays native? Then 
there is nothing about bad about reusing the principle. IMHO. Feel free to 
differ, but I consider the [] solution much more elegant than the C 
varargs.


> > > 6. Try to explain that to a C developer... it easier to bash your
> > > head
> > > against the wall
> > 
> > Then don't do it. Let the C runtime solve his interface problem for him,
> > and
> > only provide (2) calls.
> 
> Well I'm going soon to raise my presentation in a Linux club (I still
> have to have an answer from the organisers of two of that Linux
> clubs), and one of the questions that someone will ask (actually
> tease) on many unsupported things... now try to face such questions
> that you can not escape from ... I can't answer such teasing when I
> think someone is right ... :(

Let me show you a very elegant use of the FPC language. We'll be 
implementing a printf style thing, but nicer:

type   help_type=type string;

operator :=(s:string):help_type;

begin
  result:=help_type(s);
end;

operator :=(s:longint):help_type;

begin
  val(s,result);
end;

procedure printf_improved(const s:string;args:array of help_type);

{This will format a string like 'We have $1 apples and $2 pears' and
 print it.}

begin
  {...}
end;

function localized_strings(var format,colour,thing:string);

begin
  if language=english then
    begin
      format:='A $1 $2';
      colour:='red';
      thing:='wine';
    end;
  if language=italiano then
    begin
      format:='Un $2 $1';  {In Italian the subject comes first.}
      colour:='vino';
      thing:='rosso';
    end;
end;

var format,colour,thing:string;

begin
  printf_improved('We have $1 apples and $2 pears',[1,5]);
  printf_improved('The value of variable b is',[b]);
  localized_strings(format,colour,thing);
  printf_improved(format,[colour,thing]);
end.


Now this example has many advantages over the C printf:
* It is type safe.
* It doesn't pull in unnecessary code into the executable, for example
  the boolean print code does not appear into the exe if we do not need 
  it.
* The parameters can swap positions, so it is much more powerfull for 
  translations.

Can you do this with C? I fear not. Show it to a C programmer and he'll be 
convinced Pascal has some amazingly powerfull features.

> > > 7. Require delphi/objfpc modes.
> > 
> > So? It is higher level functionality.
> 
> So, if I do not need OOP, I must do an overloading of
> fnc(a :..) ..
> fnc (a,b :..) ..
> fnc (a,b,c : ..) ..
> fnc (a,b,c,d : ...) ..
> 
> I think there is a function like this in the FPC core source.
> That's makes Pascal useless on such types of needs :( Or as someone
> told me "if you don't like this, just use C instead" . And that's not
> an answer I like to hear ... (when everything else fails, use
> assembly, not C! ;))

Actually I agree with you here.

> Back in the Delphi2-3 days (maybe its till exists), there was a hack
> that if a variable is from a range of 000000..111111 it is an integer,
> if the range of the memory is 222222..333333 the variable is float, if
> it's AAAAAA..FFFFFF it's a class etc.. you don't expect any developer
> to go that law to know such things ... specially, that it is not a
> constant thing on every OS and arch .

Huh?!! Again I am lost.

> So how good are we then the C developers, that pointers are like air
> to them, even on places no other language really needs them (including
> c++) ?
> 
> "Maybe we should use object like variable types ?" (don't even bother
> to answer, I don't want such a thing)

I don't think there is an alternative here. If you would pass an array of 
pointers, you would get into trouble when passing integers. (Pascal 
is type safe.) Record variants are the only sensible solution.

> > Basically all are "it is not both C and Java". Well, it isn't. It is
> > FPC/Delphi.
> 
> Yes, but while most C compilers does not fully support K&R syntax and
> supports, and uses a lot of hacks and "patches like" ways to do
> things, we the Pascal developers, are better, smarter (ahmmm most of
> you ;)), and can solve things in a much different way then the C
> developers.

This is exactly what we thought when coding this.

> > Even if you want to make a comparison, make one, and then also list the
> > disadvantages of the solution (like the horrible security model of C, or
> > the
> > runtime overhead of Java)
> 
> I don't want a C or Java like compiler, I want that people from C or
> Java will find out that Pascal is able to do things, they can only
> dream on, and they will try to take it for themself.
>
> Ours is not only bigger, but also better (on most things, but it's not
> perfect :( )

Sure! Just accept that sometimes things will work differently than in C, 
Pascal is not C, even if it is at least as powerfull.

Daniël