* mike3:
>
> What would be a better compiler, by the way? I've only
> got this one since I didn't have to pay money for it
> and I do not have a lot of money.

It seems you forgot to state which compiler you're using.

However, seeing as this is Windows programming, Visual C++ 8.0 is fairly
good and gratis. Including an IDE, which, unfortunately, is crappy.

[snip]
> Then I'd be curious to know. Does this require a cast,
> to get the value of the pointer for our error information?:
>
> FG3DError SomeRoutine(BigFloat *a)
> {
> FG3DError err;
>
> <blah blah blah>
>
> if(<some operation on "a" failed>)
> return(FG3DError(<Error code>, a)); <--- here
> else
> return(FG3DError(FG3D_SUCCESS));
> }

Do something like

void someRoutine( BigFloat const& a )
{
// some operation on "a"
}

If "some operation" fails it will throw an exception.

Notice how extremely much simpler this is, in addition to be much more safe.


> And this?
>
> long MultiplyShorts(short b, short c)
> {
> long a;
>
> a = b*c;
>
> return(a);
> }

Here you need conversion:

inline long productOf( short a, short b )
{
long aLong const = a;
return aLong*b;
}

or

inline long productOf( short a, short b )
{
return (a+0L)*b;
}

Since this function is evidently intended to be used in expressions, the
name has been changed to indicate the result rather than the operation
(like, instead of "computeSin", just "sin").


> Will this give the full "long" result

No, in the code you showed the arguments would be promoted to int, the
computation done as int, and only then the result converted to long.


> or
> do I need to typecast b and c to "short"?

?


[snip]
> double DivideInts(int a, int b)
> {
> double t;
>
> t = a/b;
>
> return(t);
> }
>
> Does that give a full floating-point double-
> precision quotient of a and b or an integer one?

Integer.


> By the _C++ standard_, remember. See, in all
> three of these situations I've used a cast, and
> it is these situations that account for the vast
> majority of my cast use.

No need to use casts in any of the code you've shown.

By not using casts needlessly, and using the C++ style casts (like
static_cast, reinterpret_cast, dynamic_cast, const_cast) where you
absolutely need one, you make it possible to /search/ for casts.

Searching for casts can be relevant because casts are a main source of
bugs -- which is the main reason to avoid them. ;-)


>>>> Having done all the above the program crashes on using an invalid
>>>> pointer txtrptr in [render.cpp] at line 62, which is due to using an
>>>> uninitialized member "d3dlr" (presumably there should have been an
>>>> earlier call to FractalImage::LockRectangle, but no such).
>>> That is uninitialized? It calls LockRectangle() right
>>> in there @ line 46.
>> I'm just reporting what it did. There was no actual call to that
>> function at run-time, before the crash. As to why that should happen,
>> well. :-)
>>
>
> Uh oh...
>
> Why wouldn't it call? That does not make any sense! It
> calls on my machine.

Checking...

This happens with menu choice "New fractal...".

Oops, I said something wrong (hasty me). LockRectangle /is/ called, but
the section of code there that initializes the "d3dlr", where I
naturally placed the breakpoint, is within

if(LockStatus == FALSE) { ... }

and LockStatus has a non-zero value, apparently uninitialized.

Summing up, I think it would really help if you tried very hard to do
/guaranteed/ initialization. Not calling Init-functions. Using
constructors that either initialize everything successfully, or throw.


[snip]
> The constructors do throw exceptions if they cannot initialize
> something
> completely and successfully. So it would be OK to remove all
> initialization
> checks except the exception throwing, then?

Yes, when the other aspects are fixed. By that I mean, not calling
Init-functions that call other functions... Using just constructors,
and even introducing dummy private base classes to do this.

Now as mentioned that isn't ideal. It's just a technical fix. Ideal
would be some redesign.

But by limiting yourself to a very harsh initialization regime, you'll
avoid pitfalls that otherwise could and probably would strand you (until
you gain more experience with initialization concerns in C++).

Cheers, & hth.,

- Alf


PS: *PLEASE DON'T QUOTE SIGNATURES!*


--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?