Re: [Alephmodular-devel] Random rumblings on files and errors

[Br'fin <br...@ma...>]

On Thursday, January 30, 2003, at 10:47  AM, Woody Zenfell, III wrote:

> I'm going to try to not get very involved with this one since you've 
> got other people actually making comments now ;)  but one random 
> thought:

Now now, all the input has been good.  :)

> Wouldn't it be good to have at least one of those 'int'-type fields be 
> 32 bits wide so that an error code returned by an existing API like 
> DirectX etc. could be stuffed in there?  Maybe I'm missing some info 
> again... I suppose yeah every time a DirectX routine is called, the 
> caller should examine the error return and remap it to some sort of AM 
> error-code or something for consistency - but is anybody _really_ 
> going to do that?  Probably having AM realize that the overall 
> operation failed - so it can tell the user or take corrective action - 
> and then spewing out the raw error code number into a log or something 
> is sufficient?

You're probably right on the 32bit wide, I was just starting with the 
16bit values that game_error.h was using. Which admittedly fits into 
the same sort of int size as a MacOS OSErr. Imagine that.

Well, people should be checking the error codes of things to begin 
with. And to a certain degree, as long as error codes don't clash, the 
remapping could be to itself. Or be generic.
It should at least be formatted into type='systemError', 
error_code='your sound card hates you', at which point a place for the 
actual platform specific code could indeed be good.


> Also while I'm at it, I appreciate the idea of having a totally 
> standard calling convention etc., but isn't this 
> least-common-denominator approach really sort of more inconvenient 
> than it's worth?  I mean, it sounds like a lot of things are just 
> going to return a pointer - is it really so bad to return a NULL on 
> failure and a good pointer on success?

One of the books I was reading suggested always using return parameters 
for important information. It's harder to ignore a return parameter 
than a return value.

So while
	create_foo(); // Returns NULL or new object

is legal and the compiler won't stop you, it is definitely wrong. I 
don't really see it as a least common denominator approach either.


> And on using foo*& outFoo as a parameter rather than foo**: isn't the 
> latter more familiar and thus more comfortable to most programmers?  
> Is there any advantage to the former other than the programmer not 
> having to type an extra & when the variable is passed?  I'd even argue 
> that having to put that & there is somewhat of an advantage - at least 
> every time you do so you are explicitly reminded that the value of 
> what you're passing could be changed.

On one hand I'm kind of mixed and ambiguous on this. On the other, the 
C++ FAQ tends to recommend the use of references, and actually mentions 
that converting a derived** to a base** can be flagged as a compiler 
warning or error.

[21.2] Converting Derived* -> Base* works OK; why doesn't Derived** -> 
Base** work?
http://geneura.ugr.es/~jmerelo/c++-faq/proper-inheritance.html#faq-21.2

[8.6] When should I use references, and when should I use pointers?
http://www.parashift.com/c++-faq-lite/references.html#faq-8.6


> And indeed, there's an advantage to the latter: code can be written to 
> ignore NULL passed in there, so if the programmer doesn't need some 
> returned values, he can just pass in NULL rather than make a dummy 
> variable that clutters things up.
>
> But maybe I'm wrong.  :)
>
If we find a situation where we're ditching the return value like that, 
then I would think our API or the function trying to call it like that 
needs tweaking.

I'm going to accept that even once I'm done with things like the file 
abstraction, that something will turn up down the road where I missed X 
or I missed Y. We shouldn't try to work around this kind of situation, 
we should fix it.

-Jeremy Parsons