• Sean Kelly (12/12) Jul 16 2004 I've been running into more and more problems with typeid while implemen...
• Sean Kelly (7/7) Jul 16 2004 One possible fix would be to allow access specifiers for varargs, ie.
• Berin Loritsch (17/26) Jul 16 2004 Java 1.5 just added support for varargs, and the way it was done works

Sean Kelly <sean f4.ca> writes:

I've been running into more and more problems with typeid while implementing
scanf.  The problems seem to stem from the fact that scanf parameters must be
pointers, and typeid doesn't seem to differentiate between pointer types.  For
example, float*, double*, and real* all have the same typeid.  Is there any hope
of this changing?  It has me considering re-implementing length specifiers just
so I can handle precision correctly.  Right now I'm defaulting to the smallest
precision value in most cases just to have the code work, which kind of sucks.

Another unrelated issue is with static arrays vs. dynamic arrays and C pointers.
In order to deal with static arrays I am currently stuck passing them this way:
&val[0], ie. converting them to a pointer type.  When I don't use this method
the value isn't set correctly.  Is there any way around this?


Sean

Sean Kelly <sean f4.ca> writes:

One possible fix would be to allow access specifiers for varargs, ie.

void func( char[] p1, inout ... )
{

}

This would change the calling syntax for scanf but would allow types to be
determined correctly.


Sean

Berin Loritsch <bloritsch d-haven.org> writes:

Sean Kelly wrote:

 One possible fix would be to allow access specifiers for varargs, ie.
 
 void func( char[] p1, inout ... )
 {
 
 }
 
 This would change the calling syntax for scanf but would allow types to be
 determined correctly.

Java 1.5 just added support for varargs, and the way it was done works 
pretty well.

The parameter ... is accessed as an Object[], so there isn't any worries 
about exceeding bounds and such.

It really helps in situations where you have a bunch of info to format 
or in dealing with reflection code.

In essence the ... is shortcut for something like this:

Method meth = klass.getMethod("foo", new Class[] {Bar.class,
                               Baz.class});

It can be called like this:

Method meth = klass.getMethod("foo", Bar.class, Baz.class);

I know its Java baggage, but going from not having it to having it is 
really nice.

It does make the implementation a bit easier.  All you have to do is
understand the ... and encapsulate it in the dyn array within the
compiler.  All is well and not too much to implement it.