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

[Woody Z. I. <woo...@sb...>]

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:

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?

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?

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.  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.  :)

Woody


On Thursday, January 30, 2003, at 09:01  AM, Br'fin wrote:

> class CError
> {
> 	private:
> 		std::string error;
> 		uint16 type;
> 		uint16 error_code;