Thread overview
problems with typeid (for scanf)
Jul 16, 2004
Sean Kelly
Jul 16, 2004
Sean Kelly
Jul 16, 2004
Berin Loritsch
July 16, 2004
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


July 16, 2004
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


July 16, 2004
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.