Thread: Manually reading an integer literal

Originally Posted by awsdert

You'll see in my folowing post in a minute, just look for 'void printNum'.

Yeah, I still can't see why you're trying to hide details using typedef. In this:

Code:

int rdNum( int_c_pvoid_t getchr, void *source, int c, num_out_t *out )

c_pvoid_t getchr means nothing to me (what is a c_pvoid_t?) and I have to look around in the code to try and work it out when you could just have it right there as a function pointer and I wouldn't have to go searching. Why? I honestly cannot see the benefit of this.

Some asides:
1) If you must use a typedef (and in this case I think you don't because it's, in my opinion, damaging) it's probably a good idea not to use the suffix _t because POSIX reserves that. It's asking for trouble.
2) I'd get rid of the nested functions; the code is barely readable. It's a convoluted mess to be quite honest
3) What is the point of the BASE_NUM, BASE_a2z etc directives when all you use them for is declaring some string constants? (which should probably have static linkage and be const qualified anyway)
4) Are you writing C in this manner because you think the executable will be faster? Premature optimisation is the root of all evil

I'm sure you have reasons for everything I've pointed out, but if I was handed this code to maintain I'd, honestly, throw it out and start again. I can't understand what it's doing and there's no reason -- that I can see -- for writing it this way.

Anyhow, good luck. Hopefully someone with more skill than me can give more constructive critique

still at work so will make it short, compare fgetc, my function sgetc and how getchr is used and you should be able to connect the dots, I'll check back after work

k I'm back now, in case you still don't get it I was abstracting away unneeded information, a function that reads integer literals should at no point need to know where characters fed to it are coming from, only what the next character is and whether to use it or return it.