Bug in my C++ program seems really strange. (Update on debugging progress)

[mike3]

Hi.

I seem to have made some progress on finding that bug in my program. I
deactivated everything in the bignum package that was used except for
the returning of BigFloat objects. I even crippled all the
constructors. So now all the operations and constructors that were
used do is just return BigFloats but no memory is actually accessed at
any point, nor is any allocated. However, when I reenable those parts
of the constructor that allocate memory, and _then_ enable the part of
the _de_structor that _frees_ the memory, the bug appears. It only
seems when I go to allocate the "digits" buffer with (in constructor)

digits = new DIGIT32[length];

and free with (in destructor)

delete digits;

or:

(allocate in constructor) digits = (DIGIT32
*)malloc(length*sizeof(DIGIT32));

(free in destructor) free(digits);

When I don't call free or delete, though, the crash does not appear.
But it does not seem to be something needing the memory and then
accessing it as I tried it with none allocated in the first place and
"digits" set to a dummy pointer, and there was no bug nor any attempt
to access the memory as that would crash the program. It only happens
when you allocate memory in the constructor and free it in the
destructor. Freeing it immediately after allocation, in the
constructor, does not result in the crash bug.

What gives, anyway?

[mike3]

Ooops! Sorry about the double posting. Darn,
Google crashed...

[Gianni Mariani]

mike3 wrote:

On Aug 31, 10:32 pm, "Alf P. Steinbach" <[e-mail]:

....

http://www.mediafire.com/?cfmzd1y3yij

How does one build all that ?

[BobR]

mike3 <mi******@yahoo.comwrote in message...

>
digits = new DIGIT32[length];

and free with (in destructor)

// delete digits;

delete [] digits;

If you 'new', you 'delete'.
If you 'new[]', you 'delete[]'.

--
Bob R
POVrookie

[mike3]

On Sep 1, 10:17 am, "BobR" <[e-mail]:

mike3 <[e-mail] in message...

digits = new DIGIT32[length];

and free with (in destructor)

// delete digits;

delete [] digits;

If you 'new', you 'delete'.
If you 'new[]', you 'delete[]'.

Tried that, still crashes!

--
Bob R
POVrookie

[BobR]

mike3 <mi******@yahoo.comwrote in message...

On Sep 1, 12:57 am, "Alf P. Steinbach" <[e-mail]:

Changes to make it /compile/:

fracalg\computefrac.cpp(371):#if 0 file://APS
fracalg\computefrac.cpp(378):#endif file://APS
fracalg\computefrac.cpp(393):#if 0 file://APS
fracalg\computefrac.cpp(396):#else file://APS

Excuse me, why all this? Those were commented
out for debugging purposes to help minimalize
the code.

Then they should have been removed for posting. I would be pissed if I spent
good money to download it with my slow dial-up.

>

render\render.cpp(51): file://APS MessageBox(NULL, TEXT("Zorg."),
TEXT(""), MB_OK);
render\render.cpp(69): file://APS MessageBox(NULL, TEXT("Borg."),
TEXT(""), MB_OK);

Why couldn't it compile with those in?

It's windows code. GNU don't play that!

>

win32\CMainWnd.cpp(52): wcx.hCursor = LoadCursor(0,
IDC_ARROW); file://APS LoadCursor((HANDLE)NULL, IDC_ARROW); /* cursor */

win32\fg3dImageWindow.cpp(34): wcx.hCursor =
LoadCursor(0,IDC_ARROW); file://APS file://LoadCursor((HANDLE)NULL,

IDC_ARROW); /*

cursor */

win32\fg3dNewImageWzrd.cpp(18)://APS HWND gTmp;
win32\fg3dNewImageWzrd.cpp(32)://APS gTmp = hwndTmp;
main.h(108)://APS extern HWND gTmp;
fracgen3d.cpp(79):// APS

Plus, the WinMain function must be changed to something like

int WINAPI WinMain(HINSTANCE TheInstance, HINSTANCE LastInstance,
LPSTR lpszCmdLine, int iCmdShow){
__try{
return cppWinMain( TheInstance, LastInstance, lpszCmdLine,
iCmdShow );
}
__except(TRUE){
TCHAR szBuf[256];
StringCchPrintf(szBuf, 256, TEXT("EXCEPTION %08lX"),
GetExceptionCode());
OutputDebugString(szBuf);
return 0;
}
}

where cppWinMain contains the original code for that __try.

It's funny (is that the right word?) when the code contains C style
casts that makes it not compile, when all that's needed is to remove
those casts...

I must be using a really crappy C++ compiler then as
it allows that stuff.

Then set it up for standard compliance, and raise the warning levels.

>
So then it casts it automatically, you don't need all
that C-style stuff, then? Darn I'm too paranoid.

If you must, use the C++ casts so you get the proper warnings/errors.

>

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.

Did you check whether the pointer is valid during/after the 'call'?

If nothing else, try something like:
std::cout<<"pointer addr="<<pointer<<" calling:"<<*pointer;

If the pointer is invalid, that should cause a 'crash'. Then you'll know.

I've run into trouble in my own "spaghetti" code. Now days I separate the
GUI interface, C++ interface, and the work-horse code. Makes it much easier
to track problems, port to another OS, etc.. ( even wxWidgets needs some
'tweaking' between windows and GNU (GTK), but the underlying std C++ code
stays the same.)

--
Bob R
POVrookie

[mike3]

On Sep 1, 2:45 pm, "BobR" <[e-mail]:

mike3 <[e-mail] in message...

On Sep 1, 12:57 am, "Alf P. Steinbach" <[e-mail]:

Changes to make it /compile/:

fracalg\computefrac.cpp(371):#if 0 file://APS
fracalg\computefrac.cpp(378):#endif file://APS
fracalg\computefrac.cpp(393):#if 0 file://APS
fracalg\computefrac.cpp(396):#else file://APS

Excuse me, why all this? Those were commented
out for debugging purposes to help minimalize
the code.

Then they should have been removed for posting. I would be pissed if I spent
good money to download it with my slow dial-up.

Looking again at the changes he posted I'm not sure
what they were supposed to do, if they were to
remove undefines or add them in. I looked at my
package and there doesn't seem to be anything
commented out or otherwise removed. Perhaps he
could explain the problem that this was supposed
to remedy? I'm not sure what is going on there
now.

<snip>

Why couldn't it compile with those in?

It's windows code. GNU don't play that!

He was using GNU compilers? I thought there
were versions of the GNU compilers for Windows.
If his compiler, GNU or otherwise, was unable
to support Windows he couldn't have run the
program as the whole "main" thing, "wnd" stuff
was all Windows. I'm guessing his compiler did
support Windows since he was able to run it
without modifications _that_ extensive.

<snip>

I must be using a really crappy C++ compiler then as
it allows that stuff.

Then set it up for standard compliance, and raise the warning levels.

What compiler do you use, by the way? I've got a
version of the GNU compilers on my system too,
and I could feed the non-Windows stuff through
it. If you're using GNU compilers (as I've
assumed from your "GNU don't play that!" comment),
could you explain how you do this (the "set it up
for standard compilance" part. I already know
how to raise the warning level.).

>

So then it casts it automatically, you don't need all
that C-style stuff, then? Darn I'm too paranoid.

If you must, use the C++ casts so you get the proper warnings/errors.

Well I've been converting my main program to use
these.

>

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.

Did you check whether the pointer is valid during/after the 'call'?

Why the scare quotes around "call", anyway?

If nothing else, try something like:
std::cout<<"pointer addr="<<pointer<<" calling:"<<*pointer;

If the pointer is invalid, that should cause a 'crash'. Then you'll know.

I've run into trouble in my own "spaghetti" code. Now days I separate the
GUI interface, C++ interface, and the work-horse code. Makes it much easier
to track problems, port to another OS, etc.. ( even wxWidgets needs some
'tweaking' between windows and GNU (GTK), but the underlying std C++ code
stays the same.)

--
Bob R
POVrookie

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

On 2007-09-01 23:17, mike3 wrote:

On Sep 1, 2:45 pm, "BobR" <[e-mail]:

>mike3 <[e-mail] in message...

On Sep 1, 12:57 am, "Alf P. Steinbach" <[e-mail]:

<snip>

I must be using a really crappy C++ compiler then as
it allows that stuff.

Then set it up for standard compliance, and raise the warning levels.

What compiler do you use, by the way? I've got a
version of the GNU compilers on my system too,
and I could feed the non-Windows stuff through
it. If you're using GNU compilers (as I've
assumed from your "GNU don't play that!" comment),
could you explain how you do this (the "set it up
for standard compilance" part. I already know
how to raise the warning level.).

-std=c++98

--
Erik Wikström

[mike3]

On Sep 1, 5:06 pm, "Alf P. Steinbach" <[e-mail]:

* 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.

I use the Borland C++ Builder 5.5 Command line tools.

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

Gratis, really?

Is there a "stripped" version that has only the
C++ compilers, like with the Borland thing?

[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.

What if the operation though is something that returns
an error value instead? Oh and when I throw the exception
I also need to convert a pointer to give additional
information to whatever handler catches the exception,
(there's handlers in any area where exceptions may
get thrown out of) for example to show that an
operation on "a" failed.

Should there be _no_ functions that return error
values, and instead _always_ throw exceptions when
they fail (as that way you don't have to worry about
neglecting an error check around one, you can just
keep a few exception handlers at various levels,
etc.?)?

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

I actually do not have a function like that in my
program, but the situation shown in that minimal
function is often found in more complex functions
like the bignum routines, for example. So then
I'd need to create ad hoc variables specifically
for the purpose of converting?

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.

So then you have to typecast, right?

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

?

I meant, typecast to "long", sorry.

[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.

So then would a typecast be a good idea?

Or is does this do it, and is it "proper"?:

---
double DivideInts(int a, int b)
{
double adbl = a;
double bdbl = b;

return(adbl/bdbl);
}
---

(No typecasting)

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

I've got nearly all the casts converted, so now I
can start removing 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.

The structure, "FractalImage" has a real constructor,
but I only added the LockStatus flag in LATER, and FORGOT
to put it in the constructor! Dang!!!

It works now! The bug has been fixed!

The Init functions are *pnly* and I say again, *ONLY*
called in CONSTRUCTORS, period. And *always* called from
them. They're just there to save a bit of cutting-and-
pasting. At no point are they called anywhere else.

[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.

Could you tell me where my design is wanting, by the way?
I'd like to know so I can improve it.

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

I try to make sure it's all initialized, but as I add
more to the classes sometimes I forget to add something
(like the dilemma that caused this whole problem) to the
initializing procedures. That's called "human error",
and it's bound to happen eventually.

Cheers, & hth.,

- Alf

PS: *PLEASE DON'T QUOTE SIGNATURES!*

Signature snipped.

[Duane Hebert]

I use the Borland C++ Builder 5.5 Command line tools.

>

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

Gratis, really?

Is there a "stripped" version that has only the
C++ compilers, like with the Borland thing?

I think it just does c++ but it has an IDE. You can also get Borland's
Turbo
Explorer that's based on BDS2006. It has an IDE and a newer compiler
than 5.5. Or just get both and see what you like. Both are free.

[mike3]

On Sep 1, 5:20 pm, Erik Wikström <[e-mail]:

On 2007-09-01 23:17, mike3 wrote:

On Sep 1, 2:45 pm, "BobR" <[e-mail]:

mike3 <[e-mail] in message...
On Sep 1, 12:57 am, "Alf P. Steinbach" <[e-mail]:

<snip>

I must be using a really crappy C++ compiler then as
it allows that stuff.

Then set it up for standard compliance, and raise the warning levels.

What compiler do you use, by the way? I've got a
version of the GNU compilers on my system too,
and I could feed the non-Windows stuff through
it. If you're using GNU compilers (as I've
assumed from your "GNU don't play that!" comment),
could you explain how you do this (the "set it up
for standard compilance" part. I already know
how to raise the warning level.).

-std=c++98

Thanks.

--
Erik Wikström

[mike3]

On Sep 1, 6:25 pm, "Duane Hebert" <[e-mail]:

I use the Borland C++ Builder 5.5 Command line tools.

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

Gratis, really?

Is there a "stripped" version that has only the
C++ compilers, like with the Borland thing?

I think it just does c++ but it has an IDE. You can also get Borland's
Turbo
Explorer that's based on BDS2006. It has an IDE and a newer compiler
than 5.5. Or just get both and see what you like. Both are free.

What's it called, anyway?

[LR]

Alf P. Steinbach wrote:

Try to encapsulate low-level operations in some not-very-high-level
classes. For example, such encapsulation classes, or functions, do all
pointer stuff, translate from error codes to exceptions, etc. Just
getting that bug-inducing low level stuff /out of the way/, packaged.

Else-thread I have already mentioned another aspect of that high level
low level clash, that it would be a good idea to use std::vector instead
of raw arrays and pointers.

And don't over look the ease of use issues, for example, want to set all
the elements of a std::vector<intto zero?

std::vector<intt;
// ...more code here...
t.assign(t.size(),0);

I'd like to add that getting rid of all, or at least as much as you can,
the manipulation of char arrays and pointers by using std::string
instead might go some way to reducing work. String streams can be
pretty useful along those lines too.

Sure, the buffers you create are probably, most likely, expected to be,
big enough. But then you'll discover to your sorrow that they weren't.
Annoying that.

Also, I find that some simple things make code easier to deal with.

For example, if I have a function
void f(const int a);
that gets called a few dozen times with double, like so:
f((int)1.3); // or something
it's easier to just add another function (or ctor, or method, with
appropriate syntax accordingly) like
void f(const double a);
rather than doing all those casts, even if the second calls the first.
That'll still look a little cleaner.

And I'd like to repeat what has been already mentioned. Be careful with
those casts. Particularly with casting pointers to an integral type or
vice-versa, in general this is not wise.

LR

[mike3]

I still haven't heard any response yet.

But I would still really want to know what exactly to do
with improving the design. You suggested that I try
to add in "intermediate" levels of abstraction, with
low level classes to handle pointers, etc. Wouldn't I
then need to set up a class for each and every data type
I want to make an array? Or would using std::vector, etc.
be acceptable?

Would it be a good idea to, for example, with the BigFloat
thing, encapsulate the digits and all that into a separate
"RawInt" class that is essentially an integer type, from
which BigFloat would be made a derived class? This would
help get rid of the nasty Init functions that I heard were
such a bad idea (since even if their use is limited to
constructors, it is still possible one may accidentally
slip and call them from somewhere else), since then each
constructor for the different varieties of BigFloat would
not need those to initialize the digit array as that's
taken care of by RawInt's constructor. And the RawInt
routines would be able to do arithmetic of parts of the
RawInts to other parts, so that all the "pointer gymnastics"
seen in the floating point routines would be handled by
the lower-level RawInt, and then finally through the
safer and better std::vector arrays.

That would reorganize it to something like

class RawInt
{
protected:
std::vector<DIGITdigits; <--- note the use of std::vector!
int length;
public:
RawInt();
~RawInt();
<everything in rawint.cpp remade into member
functions, reworked to handle disparate lengths,
etc.>
}

and

class BigFloat : private RawInt
{
private:
u32 signexp; /* sign-exponent combination */
public:
<everything in bigfloat.cpp, etc.>
}

..

(and reworking all the arithmetic stuff appropriately,
of course.)

Does that sound like a good idea? I've already started
doing it since it looks good to me.

PS. I've also changed all instances of "DIGIT32" to
"DIGIT" in the full program in case I want to make
a 64-bit version for 64-bit processors when I get one,
and reworked it a bit so that 32-bit-specific things
have been turned into a few macros and defines that
can be easily changed to resize the digit being
used.

[Gianni Mariani]

mike3 wrote:

I still haven't heard any response yet.

I'm not sure what the requirements you're trying to achieve.

[mike3]

On Sep 6, 6:02 pm, Gianni Mariani <[e-mail]:

mike3 wrote:

I still haven't heard any response yet.

I'm not sure what the requirements you're trying to achieve.

If you read some of the earlier messages here you can see
what I was going after. I got a suggestion that the design
I had was more prone to having bugs, since it had an
"abstraction gap" with "mixing" low and high level stuff.

[mike3]

On Sep 6, 8:14 pm, mike3 <[e-mail]:

On Sep 6, 6:02 pm, Gianni Mariani <[e-mail]:

mike3 wrote:

I still haven't heard any response yet.

I'm not sure what the requirements you're trying to achieve.

If you read some of the earlier messages here you can see
what I was going after. I got a suggestion that the design
I had was more prone to having bugs, since it had an
"abstraction gap" with "mixing" low and high level stuff.

Any comment?

[mike3]

On Sep 8, 2:40 pm, mike3 <[e-mail]:

On Sep 6, 8:14 pm, mike3 <[e-mail]:

On Sep 6, 6:02 pm, Gianni Mariani <[e-mail]:

mike3 wrote:
I still haven't heard any response yet.

I'm not sure what the requirements you're trying to achieve.

If you read some of the earlier messages here you can see
what I was going after. I got a suggestion that the design
I had was more prone to having bugs, since it had an
"abstraction gap" with "mixing" low and high level stuff.

Any comment?

Hello?

[Gianni Mariani]

mike3 wrote:

On Sep 8, 2:40 pm, mike3 <[e-mail]:

>On Sep 6, 8:14 pm, mike3 <[e-mail]:

>>On Sep 6, 6:02 pm, Gianni Mariani <[e-mail]:
mike3 wrote:
I still haven't heard any response yet.
I'm not sure what the requirements you're trying to achieve.
If you read some of the earlier messages here you can see
what I was going after. I got a suggestion that the design
I had was more prone to having bugs, since it had an
"abstraction gap" with "mixing" low and high level stuff.

Any comment?

Hello?

I didn't go through all the postings to divine your requirements. I
probably won't have the time or desire to do that for you. If you'd
like me to look at it (or anyone else for that matter), I'd suggest
making it as easy as possible for them to understand what you're trying
to do.

[mike3]

On Sep 10, 7:19 pm, Gianni Mariani <[e-mail]:

mike3 wrote:

On Sep 8, 2:40 pm, mike3 <[e-mail]:

On Sep 6, 8:14 pm, mike3 <[e-mail]:

>On Sep 6, 6:02 pm, Gianni Mariani <[e-mail]:
mike3 wrote:
I still haven't heard any response yet.
I'm not sure what the requirements you're trying to achieve.
If you read some of the earlier messages here you can see
what I was going after. I got a suggestion that the design
I had was more prone to having bugs, since it had an
"abstraction gap" with "mixing" low and high level stuff.
Any comment?

Hello?

I didn't go through all the postings to divine your requirements. I
probably won't have the time or desire to do that for you. If you'd
like me to look at it (or anyone else for that matter), I'd suggest
making it as easy as possible for them to understand what you're trying
to do.

I explained briefly what it is, in my own posting above.
One of the people here said the program had an
"abstraction gap", in which it was said there was a
wide difference between high levels of abstraction like
bignums, and low levels like pointers and casting, and
it was suggested that I encapsulate pointers, and
coverting errors to exceptions, and other low level
stuff (which was not specified), into a set of low
level classes and functions. So what I was trying to do
here was smooth that gap out a bit. The reason for
this being objectionable is not that it *contains*
bugs, but that it is *prone* to bugs, which makes
the software harder to maintain.

If want to to read that post, and that one alone, without
hunting through the thread, here is a straight link to it:

http://groups.google.com/group/comp....6278b77597d648

Here's a quote:

"Try to encapsulate low-level operations in some not-very-high-level
classes. For example, such encapsulation classes, or functions, do
all
pointer stuff, translate from error codes to exceptions, etc. Just
getting that bug-inducing low level stuff /out of the way/, packaged.
Else-thread I have already mentioned another aspect of that high
level
low level clash, that it would be a good idea to use std::vector
instead
of raw arrays and pointers. "

So therefore what I was trying to do with my program was
to replace the slew of "raw integer" routines with a RawInt
class, and use std::vector<for arrays/pointers. This
std::vector<would then initialize/free the memory for
the digits, eliminating the need for "Init" functions that
were said to be bad since there's no way to guarantee you
might not use them out of negligence is places where
they should not be used, even if intended to be called only
from constructors. In addition, I think it would smooth
that gap I mentioned to some degree. As then instead of
having this:

direct arrays < BigFloat

we have

direct arrays < std::vector < RawInt < BigFloat.

Does this help?

[LR]

mike3 wrote:

[snip long explanation]

Does this help?

I'm having some trouble understanding what you want.

Do you have a question that you want answered?

LR

[mike3]

On Sep 10, 7:40 pm, mike3 <[e-mail]:

On Sep 10, 7:19 pm, Gianni Mariani <[e-mail]:

mike3 wrote:

On Sep 8, 2:40 pm, mike3 <[e-mail]:
>On Sep 6, 8:14 pm, mike3 <[e-mail]:

>>On Sep 6, 6:02 pm, Gianni Mariani <[e-mail]:
>>>mike3 wrote:
>>>>I still haven't heard any response yet.
>>>I'm not sure what the requirements you're trying to achieve.
>>If you read some of the earlier messages here you can see
>>what I was going after. I got a suggestion that the design
>>I had was more prone to having bugs, since it had an
>>"abstraction gap" with "mixing" low and high level stuff.
>Any comment?

Hello?

I didn't go through all the postings to divine your requirements. I
probably won't have the time or desire to do that for you. If you'd
like me to look at it (or anyone else for that matter), I'd suggest
making it as easy as possible for them to understand what you're trying
to do.

I explained briefly what it is, in my own posting above.
One of the people here said the program had an
"abstraction gap", in which it was said there was a
wide difference between high levels of abstraction like
bignums, and low levels like pointers and casting, and
it was suggested that I encapsulate pointers, and
coverting errors to exceptions, and other low level
stuff (which was not specified), into a set of low
level classes and functions. So what I was trying to do
here was smooth that gap out a bit. The reason for
this being objectionable is not that it *contains*
bugs, but that it is *prone* to bugs, which makes
the software harder to maintain.

If want to to read that post, and that one alone, without
hunting through the thread, here is a straight link to it:

http://groups.google.com/group/comp....6278b77597d648

Here's a quote:

"Try to encapsulate low-level operations in some not-very-high-level
classes. For example, such encapsulation classes, or functions, do
all
pointer stuff, translate from error codes to exceptions, etc. Just
getting that bug-inducing low level stuff /out of the way/, packaged.

Else-thread I have already mentioned another aspect of that high
level
low level clash, that it would be a good idea to use std::vector
instead
of raw arrays and pointers. "

So therefore what I was trying to do with my program was
to replace the slew of "raw integer" routines with a RawInt
class, and use std::vector<for arrays/pointers. This
std::vector<would then initialize/free the memory for
the digits, eliminating the need for "Init" functions that
were said to be bad since there's no way to guarantee you
might not use them out of negligence is places where
they should not be used, even if intended to be called only
from constructors. In addition, I think it would smooth
that gap I mentioned to some degree. As then instead of
having this:

direct arrays < BigFloat

we have

direct arrays < std::vector < RawInt < BigFloat.

Does this help?

Did you get my post?

[mike3]

On Sep 10, 7:40 pm, mike3 <[e-mail]:

On Sep 10, 7:19 pm, Gianni Mariani <[e-mail]:

mike3 wrote:

On Sep 8, 2:40 pm, mike3 <[e-mail]:
>On Sep 6, 8:14 pm, mike3 <[e-mail]:

>>On Sep 6, 6:02 pm, Gianni Mariani <[e-mail]:
>>>mike3 wrote:
>>>>I still haven't heard any response yet.
>>>I'm not sure what the requirements you're trying to achieve.
>>If you read some of the earlier messages here you can see
>>what I was going after. I got a suggestion that the design
>>I had was more prone to having bugs, since it had an
>>"abstraction gap" with "mixing" low and high level stuff.
>Any comment?

Hello?

I didn't go through all the postings to divine your requirements. I
probably won't have the time or desire to do that for you. If you'd
like me to look at it (or anyone else for that matter), I'd suggest
making it as easy as possible for them to understand what you're trying
to do.

I explained briefly what it is, in my own posting above.
One of the people here said the program had an
"abstraction gap", in which it was said there was a
wide difference between high levels of abstraction like
bignums, and low levels like pointers and casting, and
it was suggested that I encapsulate pointers, and
coverting errors to exceptions, and other low level
stuff (which was not specified), into a set of low
level classes and functions. So what I was trying to do
here was smooth that gap out a bit. The reason for
this being objectionable is not that it *contains*
bugs, but that it is *prone* to bugs, which makes
the software harder to maintain.

If want to to read that post, and that one alone, without
hunting through the thread, here is a straight link to it:

http://groups.google.com/group/comp....6278b77597d648

Here's a quote:

"Try to encapsulate low-level operations in some not-very-high-level
classes. For example, such encapsulation classes, or functions, do
all
pointer stuff, translate from error codes to exceptions, etc. Just
getting that bug-inducing low level stuff /out of the way/, packaged.

Else-thread I have already mentioned another aspect of that high
level
low level clash, that it would be a good idea to use std::vector
instead
of raw arrays and pointers. "

So therefore what I was trying to do with my program was
to replace the slew of "raw integer" routines with a RawInt
class, and use std::vector<for arrays/pointers. This
std::vector<would then initialize/free the memory for
the digits, eliminating the need for "Init" functions that
were said to be bad since there's no way to guarantee you
might not use them out of negligence is places where
they should not be used, even if intended to be called only
from constructors. In addition, I think it would smooth
that gap I mentioned to some degree. As then instead of
having this:

direct arrays < BigFloat

we have

direct arrays < std::vector < RawInt < BigFloat.

Does this help?

Any response?

[mike3]

On Sep 10, 7:40 pm, mike3 <[e-mail]:

On Sep 10, 7:19 pm, Gianni Mariani <[e-mail]:

mike3 wrote:

On Sep 8, 2:40 pm, mike3 <[e-mail]:
>On Sep 6, 8:14 pm, mike3 <[e-mail]:

>>On Sep 6, 6:02 pm, Gianni Mariani <[e-mail]:
>>>mike3 wrote:
>>>>I still haven't heard any response yet.
>>>I'm not sure what the requirements you're trying to achieve.
>>If you read some of the earlier messages here you can see
>>what I was going after. I got a suggestion that the design
>>I had was more prone to having bugs, since it had an
>>"abstraction gap" with "mixing" low and high level stuff.
>Any comment?

Hello?

I didn't go through all the postings to divine your requirements. I
probably won't have the time or desire to do that for you. If you'd
like me to look at it (or anyone else for that matter), I'd suggest
making it as easy as possible for them to understand what you're trying
to do.

I explained briefly what it is, in my own posting above.
One of the people here said the program had an
"abstraction gap", in which it was said there was a
wide difference between high levels of abstraction like
bignums, and low levels like pointers and casting, and
it was suggested that I encapsulate pointers, and
coverting errors to exceptions, and other low level
stuff (which was not specified), into a set of low
level classes and functions. So what I was trying to do
here was smooth that gap out a bit. The reason for
this being objectionable is not that it *contains*
bugs, but that it is *prone* to bugs, which makes
the software harder to maintain.

If want to to read that post, and that one alone, without
hunting through the thread, here is a straight link to it:

http://groups.google.com/group/comp....6278b77597d648

Here's a quote:

"Try to encapsulate low-level operations in some not-very-high-level
classes. For example, such encapsulation classes, or functions, do
all
pointer stuff, translate from error codes to exceptions, etc. Just
getting that bug-inducing low level stuff /out of the way/, packaged.

Else-thread I have already mentioned another aspect of that high
level
low level clash, that it would be a good idea to use std::vector
instead
of raw arrays and pointers. "

So therefore what I was trying to do with my program was
to replace the slew of "raw integer" routines with a RawInt
class, and use std::vector<for arrays/pointers. This
std::vector<would then initialize/free the memory for
the digits, eliminating the need for "Init" functions that
were said to be bad since there's no way to guarantee you
might not use them out of negligence is places where
they should not be used, even if intended to be called only
from constructors. In addition, I think it would smooth
that gap I mentioned to some degree. As then instead of
having this:

direct arrays < BigFloat

we have

direct arrays < std::vector < RawInt < BigFloat.

Does this help?

No comments yet?