www.digitalmars.com         C & C++   DMDScript  

c++.stlsoft - fixed_array, at, and NDEBUG

reply Neal Becker <ndbecker2 gmail.com> writes:
I believe that, contrary to the documentation, that 'at' uses assert, and
that assert is disabled if NDEBUG is defined.  So, if NDEBUG is defined,
then 'at' won't actually perform checking.  Note: I'm not complaining.  The
current behavior is what I want.  I just think the documentation should be
clarified.
Mar 20 2007
parent reply Matthew Wilson <no-one nowhere.no.com> writes:
Neal Becker Wrote:


 I believe that, contrary to the documentation, that 'at' uses assert, and
 that assert is disabled if NDEBUG is defined.  So, if NDEBUG is defined,
 then 'at' won't actually perform checking.  Note: I'm not complaining.  The
 current behavior is what I want.  I just think the documentation should be
 clarified.



AFAIK, the at() overloads only use assert in builds when exceptions are not
supported. When exception-support is on, they throw std::out_of_range.

Can you give me some context for your observations, so I can get a hold on what
precisely you're referring to?

Thanks

Matthew
Apr 06 2007
parent reply Neal Becker <ndbecker2 gmail.com> writes:
Matthew Wilson wrote:


 Neal Becker Wrote:
 

 I believe that, contrary to the documentation, that 'at' uses assert, and
 that assert is disabled if NDEBUG is defined.  So, if NDEBUG is defined,
 then 'at' won't actually perform checking.  Note: I'm not complaining. 
 The
 current behavior is what I want.  I just think the documentation should
 be clarified.



 AFAIK, the at() overloads only use assert in builds when exceptions are
 not supported. When exception-support is on, they throw std::out_of_range.
 
 Can you give me some context for your observations, so I can get a hold on
 what precisely you're referring to?
 




I'm testing on linux (fedora fc6 x86_64) with:

gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)
stlsoft-1.9.1.beta46

and as shown by gdb, it _is_ calling assert, not using exceptions.  Do I
need to configure something?
Apr 11 2007
parent reply "Matthew Wilson" <matthew hat.stlsoft.dot.org> writes:
"Neal Becker" <ndbecker2 gmail.com> wrote in message
news:evj5cu$1rj5$1 digitalmars.com...

 Matthew Wilson wrote:


 Neal Becker Wrote:


 I believe that, contrary to the documentation, that 'at' uses assert,










 that assert is disabled if NDEBUG is defined.  So, if NDEBUG is










 then 'at' won't actually perform checking.  Note: I'm not complaining.
 The
 current behavior is what I want.  I just think the documentation should
 be clarified.



 AFAIK, the at() overloads only use assert in builds when exceptions are
 not supported. When exception-support is on, they throw







 Can you give me some context for your observations, so I can get a hold







 what precisely you're referring to?




 I'm testing on linux (fedora fc6 x86_64) with:

 gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)
 stlsoft-1.9.1.beta46

 and as shown by gdb, it _is_ calling assert, not using exceptions.  Do I
 need to configure something?



This is all very odd.

I've just knocked this up and tested on Windows with both VC++8 and GCC3.4,
and on Mac OSX with GCC 4.0.

In all cases, I tested a debug variant (-D_DEBUG -DDEBUG -UNDEBUG) and a
released variant (-U_DEBUG -UDEBUG -DNDEBUG), and it all works just fine,
i.e. an instance of std::out_of_range is thrown and no assertions are fired.

Yours, confused

Matthew
Apr 11 2007
parent reply Neal Becker <ndbecker2 gmail.com> writes:
Matthew Wilson wrote:


 
 "Neal Becker" <ndbecker2 gmail.com> wrote in message
 news:evj5cu$1rj5$1 digitalmars.com...

 Matthew Wilson wrote:


 Neal Becker Wrote:


 I believe that, contrary to the documentation, that 'at' uses assert,










 that assert is disabled if NDEBUG is defined.  So, if NDEBUG is










 then 'at' won't actually perform checking.  Note: I'm not complaining.
 The
 current behavior is what I want.  I just think the documentation
 should be clarified.



 AFAIK, the at() overloads only use assert in builds when exceptions are
 not supported. When exception-support is on, they throw







 Can you give me some context for your observations, so I can get a hold







 what precisely you're referring to?




 I'm testing on linux (fedora fc6 x86_64) with:

 gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)
 stlsoft-1.9.1.beta46

 and as shown by gdb, it _is_ calling assert, not using exceptions.  Do I
 need to configure something?



 This is all very odd.
 
 I've just knocked this up and tested on Windows with both VC++8 and
 GCC3.4, and on Mac OSX with GCC 4.0.
 
 In all cases, I tested a debug variant (-D_DEBUG -DDEBUG -UNDEBUG) and a
 released variant (-U_DEBUG -UDEBUG -DNDEBUG), and it all works just fine,
 i.e. an instance of std::out_of_range is thrown and no assertions are
 fired.
 
 Yours, confused
 



assert is called from here:

    STLSOFT_MESSAGE_ASSERT("fixed array index out of range", i0 < m_d0);
#3  0x00000000004009d9 in stlsoft::fixed_array_1d<int, std::allocator<int>,
stlsoft::do_construction<int>, true>::operator[] (
    this=0x7fff01935f70, i0=11) at
/usr/local/src/stlsoft/include/stlsoft/containers/fixed_array.hpp:962

Are you saying that "STLSOFT_MESSAGE_ASSERT" should expand to throw rather than
assert?
It's hard to tell - twisty maze of macros (all different)
Apr 12 2007
next sibling parent Neal Becker <ndbecker2 gmail.com> writes:
It seems there are both STLSOFT_MESSAGE_ASSERT and STLSOFT_THROW_X used in
fixed_array.  Did you really want that?  Shouldn't this be using one or the
other consistently?

It seems that range_check uses throw.  at uses range_check.

at_unchecked uses assert?!!?  I'm really surprised by this.  I thought
unchecked meant, uh, unchecked??
Apr 12 2007
prev sibling parent reply "Matthew Wilson" <matthew hat.stlsoft.dot.org> writes:
"Neal Becker" <ndbecker2 gmail.com> wrote in message
news:evl4s6$2ffu$1 digitalmars.com...

 Matthew Wilson wrote:


 "Neal Becker" <ndbecker2 gmail.com> wrote in message
 news:evj5cu$1rj5$1 digitalmars.com...

 Matthew Wilson wrote:


 Neal Becker Wrote:


 I believe that, contrary to the documentation, that 'at' uses
















 and

 that assert is disabled if NDEBUG is defined.  So, if NDEBUG is










 then 'at' won't actually perform checking.  Note: I'm not
















 The
 current behavior is what I want.  I just think the documentation
 should be clarified.



 AFAIK, the at() overloads only use assert in builds when exceptions













 not supported. When exception-support is on, they throw







 Can you give me some context for your observations, so I can get a













 on

 what precisely you're referring to?




 I'm testing on linux (fedora fc6 x86_64) with:

 gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)
 stlsoft-1.9.1.beta46

 and as shown by gdb, it _is_ calling assert, not using exceptions.  Do










 need to configure something?



 This is all very odd.

 I've just knocked this up and tested on Windows with both VC++8 and
 GCC3.4, and on Mac OSX with GCC 4.0.

 In all cases, I tested a debug variant (-D_DEBUG -DDEBUG -UNDEBUG) and a
 released variant (-U_DEBUG -UDEBUG -DNDEBUG), and it all works just







 i.e. an instance of std::out_of_range is thrown and no assertions are
 fired.

 Yours, confused



 assert is called from here:

     STLSOFT_MESSAGE_ASSERT("fixed array index out of range", i0 < m_d0);
 #3  0x00000000004009d9 in stlsoft::fixed_array_1d<int,




     this=0x7fff01935f70, i0=11) at




Ok, now I'm even more confused. Well, non-technically, anyway. I thought we
were talking about at().

Probably my bad. ;-/

Certainly the subscript operator uses an assert ... as does at_unchecked().


 Are you saying that "STLSOFT_MESSAGE_ASSERT" should expand to throw rather




No. Not at all.


It comes down to the contracts of the various methods. (Please excuse me if
I'm telling you stuff you already know in the following <g>)

The contract for the subscript operator(s) is:
    Precondition: index < size()
    Postcondition: return of a reference (mutating or non-mutating) to the
element referred to by the index

It's exactly the same for at_unchecked() (and the newly added function call
operators(), in beta 48, just released), except that for _2d and above there
are multiple indexes.

The contract for at() is very different:
    Precondition:
    Postcondition: return of a reference  to the element referred to by the
index if index < size(). Throw an exception of std::out_of_range if index >=
size()

Since it's the responsibility of the caller to fulfil the precondition, it
means that use of subscript operator/at_unchecked/function call operator
must be passed an index in the range [0, size()). If not, the contract is
broken, the program is not well-formed.

With at(), the caller can provide *any* value for index, and the
precondition (which is empty) is satisfied, and the program is still
well-formed.


So, the only remaining question in this (as in any contract programming) is
to decide what, if any, enforcement of the contract is made. It's important
to remember that just because a contract is not, or may not be, enforced in
code, it still applies.

(Enforcement comprises Detection, Reporting and Response. Usually, in the
guise of an assert(), this comprises a conditional test, an fprintf() to
stderr, and invocation of exit().)

The question then comes down to what enforcement, if any, is employed. I
tend to adopt the common approach of use of assertions, which means that in
debug builds the enforcement is on, and in release builds enforcement is
off. Naturally, this relies on the (sometimes erroneous) assumption that all
code paths will be exercised in debug-mode testing.

To account for this not being so, I allow, via customisation of the STLSoft
asserts, for users to keep enforcement on in all builds. That's their
choice. (When building long lasting and complex systems, e.g. network
servers, I usually keep some/all of the enforcements on in production,
though usually just the ones in application code, rather than the low-level
stuff in classes such as the fixed arrays. That way, operation outside the
design of the software can be detected and reported early, and the response
is to kill the process immediately, before it can do, theoretically,
anything at all, which would usually be bad. <g>)

Anyway, the main points are: (i) the difference between the strict contract
for the at_unchecked()/op []/op () and the loose contract for at(), and (ii)
that whether or not the strict contract is enforced, it still applies.


So, I think we probably are misunderstanding each other in interpreting the
behaviour. As far as I've been able to determine, the software behaves in
accordance with my original intent: at() checks and throws, whereas
at_unchecked()/op []/op () assert on contract violations in debug builds and
do no checking at all in release builds.

Does this square with your observations? If so, all is well. If not, I need
to fix something.

HTH

Matthew
Apr 12 2007
next sibling parent "Matthew Wilson" <matthew hat.stlsoft.dot.org> writes:
 The contract for the subscript operator(s) is:
     Precondition: index < size()
     Postcondition: return of a reference (mutating or non-mutating) to the
 element referred to by the index




<snip>



 The contract for at() is very different:
     Precondition:
     Postcondition: return of a reference  to the element referred to by




 index if index < size(). Throw an exception of std::out_of_range if index
=
 size()




<snip>


 Anyway, the main points are: (i) the difference between the strict




 for the at_unchecked()/op []/op () and the loose contract for at(), and




 that whether or not the strict contract is enforced, it still applies.


 So, I think we probably are misunderstanding each other in interpreting




 behaviour. As far as I've been able to determine, the software behaves in
 accordance with my original intent: at() checks and throws, whereas
 at_unchecked()/op []/op () assert on contract violations in debug builds




 do no checking at all in release builds.

 Does this square with your observations? If so, all is well. If not, I




 to fix something.



Sorry, one last thing to add. When compiling without exception support, the
contract for at() becomes the same as that of op []/op ()/at_unchecked.

Hmmm. Having said that, now I'm thinking that it may be better to simply
remove at when !defined(STLSOFT_CF_EXCEPTION_SUPPORT).

Anyway, that doesn't affect any of the main argument in the previous post.

Matthew
Apr 12 2007
prev sibling parent reply Neal Becker <ndbecker2 gmail.com> writes:
Matthew Wilson wrote:

[...]


 
 So, I think we probably are misunderstanding each other in interpreting
 the behaviour. As far as I've been able to determine, the software behaves
 in accordance with my original intent: at() checks and throws, whereas
 at_unchecked()/op []/op () assert on contract violations in debug builds
 and do no checking at all in release builds.
 
 Does this square with your observations? If so, all is well. If not, I
 need to fix something.
 



Thanks so much for the excellent explanation.  Yes, the current behavior is
just what I want.

I do still find it a little odd that one path uses assert and the other
throw.  Not that it really matters.
Apr 12 2007
parent reply "Matthew Wilson" <matthew hat.stlsoft.dot.org> writes:
"Neal Becker" <ndbecker2 gmail.com> wrote in message
news:evlv3h$oa6$1 digitalmars.com...

 Matthew Wilson wrote:

 [...]


 So, I think we probably are misunderstanding each other in interpreting
 the behaviour. As far as I've been able to determine, the software







 in accordance with my original intent: at() checks and throws, whereas
 at_unchecked()/op []/op () assert on contract violations in debug builds
 and do no checking at all in release builds.

 Does this square with your observations? If so, all is well. If not, I
 need to fix something.



 Thanks so much for the excellent explanation.  Yes, the current behavior




 just what I want.



Cool.

So, have you been using the function call operators, as per your request,
from beta 48? Work fine? :-)
Apr 12 2007
parent reply Neal Becker <ndbecker2 gmail.com> writes:
Matthew Wilson wrote:

[...]

 So, have you been using the function call operators, as per your request,
 from beta 48? Work fine? :-)



of at_unchecked, DRY, but it's your code :)
Apr 13 2007
parent reply "Matthew Wilson" <matthew hat.stlsoft.dot.org> writes:
"Neal Becker" <ndbecker2 gmail.com> wrote in message
news:evo22q$1o58$1 digitalmars.com...

 Matthew Wilson wrote:

 [...]

 So, have you been using the function call operators, as per your







 from beta 48? Work fine? :-)



 of at_unchecked, DRY, but it's your code :)



Ah yes. Doh!

The perils of using temporary macros in one's IDE. ;-)

I'll fix it up.
Apr 13 2007
parent "Matthew Wilson" <matthew hat.stlsoft.dot.org> writes:
"Matthew Wilson" <matthew hat.stlsoft.dot.org> wrote in message
news:evon5o$1k8r$1 digitalmars.com...

 "Neal Becker" <ndbecker2 gmail.com> wrote in message
 news:evo22q$1o58$1 digitalmars.com...

 Matthew Wilson wrote:

 [...]

 So, have you been using the function call operators, as per your







 from beta 48? Work fine? :-)










 of at_unchecked, DRY, but it's your code :)



 Ah yes. Doh!

 The perils of using temporary macros in one's IDE. ;-)

 I'll fix it up.



Done. (And I've enhanced the unit-tests from their previous parlous coverage
<g>)

Thanks for the keen-eye and sharp brain!
Apr 13 2007