May 30, 2002
"Pavel Minayev" <evilone@omen.ru> wrote in news:ad4d3a$83g$1 @digitaldaemon.com:

> "Walter" <walter@digitalmars.com> wrote in message news:ad3pg0$2hgm$1@digitaldaemon.com...
> 
>> The proper way to do it would be to create a variant type, and then have variable parameter lists be passed as arrays of variants.
> 
> So, what about variants?

I would vote for a basic variant type too.

May 30, 2002
"Walter" <walter@digitalmars.com> wrote in message news:ad3pg0$2hgm$1@digitaldaemon.com...
>
> "Matthew Wilson" <mwilson@nextgengaming.com> wrote in message news:ad1mcg$2bir$1@digitaldaemon.com...
> > Walter,
> >
> > Even though I'm the last fan of C#, I do think its params implementation
> is
> > good. Would the performance be prohibitive? Do you have any figures/impressions as to how much it would cost?
>
> The proper way to do it would be to create a variant type, and then have variable parameter lists be passed as arrays of variants.

With the a basic variant type and the "array of variants" approach, every type is always a valid parameter type.  Same with the C/C++ varargs approach.

May I direct your attention? news://news.digitalmars.com/ad2ead$a6i$1@digitaldaemon.com

With my approach the compiler will enforce legal argument types; but if you want to code up a universal Variant class and use it, you may.

IMHO I'd rather avoid having "variant" be a basic type in the language.

--
Richard Krehbiel, Arlington, VA, USA
rich@kastle.com (work) or krehbiel3@comcast.net  (personal)



May 30, 2002
"Richard Krehbiel" <rich@kastle.com> wrote in message news:ad53sp$1847$1@digitaldaemon.com...

> With the a basic variant type and the "array of variants" approach, every type is always a valid parameter type.  Same with the C/C++ varargs approach.

Yes, but it is typesafe, and simple to implement.



May 30, 2002
C# is not interpreted... it's always JIT compiled.

It should in theory be able to be as fast as C++.

Sean

"cblack01" <cblack01@cox.net> wrote in message news:ad0rbq$88q$1@digitaldaemon.com...
> Hey,
>
> A quick question.  I like C#'s implementation of reflection. Does D do
> reflection?
> Also, Does D do variable parameters?  C# has a good convention for
variable
> parameters using the params keyword like this:
>
> void Print(params string stuffToPrint[])
> {
>     foreach(oneThing in stuffToPrint) System.Console.WriteLn(oneThing);
> }
>
> Then you would call it like this:
>
> Print("Printing ", "variable ", "parameters");
>
> I know it seems like I'm bragging on C#, but I'm not really.  I would
never
> use it since I do a lot of scientific applications that are too computationally intensive for an interpreted language.  C# is too slow. I've used it.  I do think that C# has beautiful syntax, though.
>
> Thanks,
>
> Craig



May 30, 2002
"Pavel Minayev" <evilone@omen.ru> wrote in message news:ad5kht$1hlr$1@digitaldaemon.com...
> "Richard Krehbiel" <rich@kastle.com> wrote in message news:ad53sp$1847$1@digitaldaemon.com...
>
> > With the a basic variant type and the "array of variants" approach,
every
> > type is always a valid parameter type.  Same with the C/C++ varargs approach.
>
> Yes, but it is typesafe, and simple to implement.

My version is "stronger" (it can enforce vararg parameter types at compile time; the variant accepts every type) and I fail to see how injecting a basic type as disruptive as "variant" would be simpler.

variant a, b, c;
a = b + c;

Integer, or floating point math?  Vector sum?  Can't tell.  The compiler must generate code to sense types and perform every valid operation at run time.  Or else, call it illegal to perform operatins on "variant," and rule that they must be converted to real types before anything can be done with them.

--
Richard Krehbiel, Arlington, VA, USA
rich@kastle.com (work) or krehbiel3@comcast.net  (personal)



May 31, 2002
"Richard Krehbiel" <rich@kastle.com> wrote in message news:ad5sul$2q3r$1@digitaldaemon.com...

> My version is "stronger" (it can enforce vararg parameter types at compile time; the variant accepts every type) and I fail to see how injecting a basic type as disruptive as "variant" would be simpler.
>
> variant a, b, c;
> a = b + c;
>
> Integer, or floating point math?  Vector sum?  Can't tell.  The compiler

Forbid such things at all. Variants are not for math, they are to store (and pass to functions) values of diffenrent types, varying at run-time. Variant math should clearly be forbidden, and explicit cast required for such cases:

    variant a, b, c;
    a = cast(int)b + cast(int)c;


May 31, 2002
"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ad5q85$2mv2$1@digitaldaemon.com...

> C# is not interpreted... it's always JIT compiled.

AFAIK, there are three modes: JIT-compilation (default), complete
precompilation,
and straight interpretation.

> It should in theory be able to be as fast as C++.

As long as it uses COM, I doubt it will be as fast even when programs are precompiled into native code.


June 03, 2002
"Pavel Minayev" <evilone@omen.ru> wrote in message news:ad7b97$1sis$1@digitaldaemon.com...
> "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ad5q85$2mv2$1@digitaldaemon.com...
>
> > C# is not interpreted... it's always JIT compiled.
>
> AFAIK, there are three modes: JIT-compilation (default), complete
> precompilation,
> and straight interpretation.
>
> > It should in theory be able to be as fast as C++.

Mmmm....
Java also uses JIT compiling doesn't it?
It takes every lame little Java program an age to
start because of this....It is definitely not as
fast as native code!


>
> As long as it uses COM, I doubt it will be as fast even when programs are precompiled into native code.
>

COM is not slow. Even DirectX uses COM and they would never do that if it really were slow. Ofcourse when you use COM to build a remote component to be accessed over the internet that's slow... :) But when you just use a .dll it is fast.


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail



June 03, 2002
> 
> COM is not slow. Even DirectX uses COM and they would never
> do that if it really were slow. Ofcourse when you use COM
> to build a remote component to be accessed over the internet
> that's slow... :) But when you just use a .dll it is fast.
> 

And its deprecated.

> 
> --
> Stijn
> OddesE_XYZ@hotmail.com
> http://OddesE.cjb.net
> _________________________________________________
> Remove _XYZ from my address when replying by mail
> 
> 
> 


June 04, 2002
"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:adgi89$276q$1@digitaldaemon.com...

> COM is not slow. Even DirectX uses COM and they would never do that if it really were slow. Ofcourse when you use COM to build a remote component to be accessed over the internet that's slow... :) But when you just use a .dll it is fast.

DX doesn't really uses COM to its fullest. It provides
functions to create DX objects fast, without using the
slow-as-hell COM/Automation mechanisms (CoCreateInstance
etc). It does not use dual interfaces, as far as I know.
It does not use SAFEARRAY and BSTR. Etc etc etc.

Just compare DX VB library (COM!) to DX C++ library (COM?),
and see the difference in speed...