Thread overview | |||||
---|---|---|---|---|---|
|
July 16, 2004 problems with typeid (for scanf) | ||||
---|---|---|---|---|
| ||||
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 Re: problems with typeid (for scanf) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | 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 Re: problems with typeid (for scanf) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | 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.
|
Copyright © 1999-2021 by the D Language Foundation