No boundschecking?

[mike3]

[snip]

So if my compiler doesn't inline that, then that
doesn't indicate poor code, it indicates a poor
compiler, which I should throw out and substitute
a better one for, right?

Or possibly it is your expectations that are faulty.

Questions that include such terms as "adequate"
and "best" mean you have a spec. I didn't see
one posted in this thread. So, it *looks* like
your spec is "I want my code good."

If you have a spec, code to it. If a particular
way of doing stuff does not meet that, find another
way of doing it.

If you don't have a spec, or if it does not include
specific performance levels you have to meet, then
you should relax. Do things "standard" rather than
worrying about getting them "best."

Also, you *need* a spec. How can you ever know if
some proposed solution is "adequate" if you have
not defined adequate?

There is no "best" way to do things. In this context,
"best" is the enemy of the good. Worrying about "best"
will simply cause you to develop poor coding habits.
"Oh, you shouldn't use that, it's not 'best.'"
Socks

So should I just run with what I posted in my first
post on this thread, and just document that it does not
boundscheck? Or is that a bad idea?

The goal here is to alleviate the design problems that
were found with the first attempt of the program, and
were pointed out here:

http://groups.google.com/group/comp.lang.c++/msg/a66278b77597d648?dmo...

QUOTE:
"The main design problem I saw, with just a cursory look at the code,
was
a mix of very high level (abstract operations) and low level
(pointers,
casting), an abstraction gap, indicating one or more missing
intermediate levels.

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 I'm trying to make this new version to address
these issues.

Any comment?

 

[James Kanze]

Sorry I know this is slightly OT, but could anyone tell me how to turn
on the debug options when using glibc/gcc. I remember finding out
about them last year, but now can`t find the #define for the life of
me.

-D_GLIBCXX_CONCEPT_CHECKS -D_GLIBCXX_DEBUG -
D_GLIBCXX_DEBUG_PEDANTIC

If I understand correctly, the first affects compile time
checking (e.g. will cause a compile time error if you attempt to
instantiation std::list over a class which doesn't support
assignment), the other two more or less runtime checking. I
just systematically use all three, and don't worry about it.
(And no, I don't know where they are documented. I heard about
them through the grapevine myself.)

Note that they (or probably only the last two) change the size
of certain data structures, so code compiled with them isn't
compatible with code compiled without them.

 

[mike3]

[snip]
So if my compiler doesn't inline that, then that
doesn't indicate poor code, it indicates a poor
compiler, which I should throw out and substitute
a better one for, right?
Or possibly it is  your expectations that are faulty.
Obviously, looking at this there are no "perfect"
solutions (not a surprise, though.). This therefore
raises the question of whether any of the solutions
here are adequate for the purposes at hand.
The whole point of the routines I've been struggling
so hard to craft here was to try and minimize the
bug-susceptibility of my code, but I also need high
performance. Therefore, the question comes up of
what the best way is to code these core routines,
like the adder I posted. What is it?
Questions that include such terms as "adequate"
and "best" mean you have a spec. I didn't see
one posted in this thread. So, it *looks* like
your spec is "I want my code good."
If you have a spec, code to it. If a particular
way of doing stuff does not meet that, find another
way of doing it.
If you don't have a spec, or if it does not include
specific performance levels you have to meet, then
you should relax. Do things "standard" rather than
worrying about getting them "best."
Also, you *need* a spec. How can you ever know if
some proposed solution is "adequate" if you have
not defined adequate?
There is no "best" way to do things. In this context,
"best" is the enemy of the good. Worrying about "best"
will simply cause you to develop poor coding habits.
"Oh, you shouldn't use that, it's not 'best.'"
Socks

So should I just run with what I posted in my first
post on this thread, and just document that it does not
boundscheck? Or is that a bad idea?

The goal here is to alleviate the design problems that
were found with the first attempt of the program, and
were pointed out here:

QUOTE:
"The main design problem I saw, with just a cursory look at the code,
was
a mix of very high level (abstract operations) and low level
(pointers,
casting), anabstraction gap, indicating one or more missing
intermediate levels.

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 I'm trying to make this new version to address
these issues.

Any comment?

I still haven't heard anything about this point, and
now I've discovered that by trying to fill the abstraction
gap with various abstracted operations, I'm paying a goodly
performance penalty. Is there any way to get around that?

 

[mike3]

[snip]
So if my compiler doesn't inline that, then that
doesn't indicate poor code, it indicates a poor
compiler, which I should throw out and substitute
a better one for, right?
Or possibly it is  your expectations that are faulty.
Obviously, looking at this there are no "perfect"
solutions (not a surprise, though.). This therefore
raises the question of whether any of the solutions
here are adequate for the purposes at hand.
The whole point of the routines I've been struggling
so hard to craft here was to try and minimize the
bug-susceptibility of my code, but I also need high
performance. Therefore, the question comes up of
what the best way is to code these core routines,
like the adder I posted. What is it?
Questions that include such terms as "adequate"
and "best" mean you have a spec. I didn't see
one posted in this thread. So, it *looks* like
your spec is "I want my code good."
If you have a spec, code to it. If a particular
way of doing stuff does not meet that, find another
way of doing it.
If you don't have a spec, or if it does not include
specific performance levels you have to meet, then
you should relax. Do things "standard" rather than
worrying about getting them "best."
Also, you *need* a spec. How can you ever know if
some proposed solution is "adequate" if you have
not defined adequate?
There is no "best" way to do things. In this context,
"best" is the enemy of the good. Worrying about "best"
will simply cause you to develop poor coding habits.
"Oh, you shouldn't use that, it's not 'best.'"
Socks
So should I just run with what I posted in my first
post on this thread, and just document that it does not
boundscheck? Or is that a bad idea?
The goal here is to alleviate the design problems that
were found with the first attempt of the program, and
were pointed out here:
http://groups.google.com/group/comp.lang.c++/msg/a66278b77597d648?dmo....
QUOTE:
"The main design problem I saw, with just a cursory look at the code,
was
a mix of very high level (abstract operations) and low level
(pointers,
casting), anabstraction gap, indicating one or more missing
intermediate levels.
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 I'm trying to make this new version to address
these issues.

Any comment?

I still haven't heard anything about this point, and
now I've discovered that by trying to fill the abstraction
gap with various abstracted operations, I'm paying a goodly
performancepenalty. Is there any way to get around that?

Just got an email on this.

And I've also resolved the problem.

Thanks for the answers, everyone.