Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Testing Program Question

Reply
Thread Tools

Testing Program Question

 
 
Nick Keighley
Guest
Posts: n/a
 
      02-16-2010
On 13 Feb, 02:16, Immortal Nephi <(E-Mail Removed)> wrote:

<snip as you didn't appear to be replying to anything I wrote>

> Is _DEBUG_ERROR from Microsoft specification?


yes


>*It is written in vector header.


it's in *microsoft's* vector header. They stuck an underscore on the
front, that generally means it's implementaion specific.


>*I think that Microsoft wrote vector header [on] their own. *


someone has to


> Do C++ Standard Library use cerr or clog to display error message instead
> of _DEBUG_ERROR.


they might. Better to throw an exception I'd have thought. I very much
doubt the C++ standard specifies that library routines write to cerr
or clog when errors occur (apart from things like perror and assert!).


> I plan to write error message in the debug version.


ok. I thought you wanted them in dialog boxes? I often write to a
dialog box /and/ a log file.

> The error message
> is able to detect argument in the function's parameter before it
> triggers to warn or alert the programmer.


can't parse that


>*For example, the argument
> in the function's parameter should be in the range between 0 and 10.
> If it exceeds 10, then error message is displayed to the screen.
>
> The error message procedure is similar to vector and string like out
> of range.


fine. Might be better to throw an exception or even to assert...


--
Nick Keighley



 
Reply With Quote
 
 
 
 
Nick Keighley
Guest
Posts: n/a
 
      02-16-2010
On 14 Feb, 11:51, James Kanze <(E-Mail Removed)> wrote:
> On Feb 13, 12:41 pm, "Leigh Johnston" <(E-Mail Removed)> wrote:
>
> > > Asserts are a sort of life jacket, to prevent things from
> > > ****ing up too much when you screwed up. *Removing them from
> > > production code is akin to wearing a life jacket when
> > > practicing in the harbor, but taking it off when you go to
> > > sea. *Sometimes, it's necessary to remove asserts for
> > > performance reasons, and for some particular applications
> > > (games?), it's probably preferrable to remove them
> > > completely (in which case, you do have to study what happens
> > > when they are removed---there's no point in removing an
> > > assert if you're just going to get a crash three statements
> > > later).

>
> > I disagree, why do you think assert was designed to do nothing
> > for NDEBUG?

>
> So that you can turn it off when you have to. *The designed use
> would be to use some application specific macro, defined (or
> not) in the command line, and then to wrap the (few) critical
> functions in something like:
>
> * * #ifdef PRODUCTION
> * * #undef NDEBUG *// Just in case.
> * * #define NDEBUG
> * * #include <assert.h>
> * * #endif
> * * void critical_function()
> * * {
> * * * * // *...
> * * }
> * * #undef NDEBUG
> * * #include <assert.h>
>
> Why do you think you're allowed to include <assert.h> multiple
> times, with it's meaning depending each time on the current
> definition of NDEBUG?


ah! One of the best answers I've seen to "asserts must only be used
whilst debugging"!

> > Asserts were designed to be used as a debugging tool so should
> > do nothing in released production code *unless* a higher
> > degree of defensiveness is required.

>
> That's your opinion. *It doesn't correspond to the design of the
> feature, nor good programming practices.


quite. Almost sig snarfable. Note leaving lots of asserts in as the
only error handling strategy probably *isn't* acceptable for high
degrees of defensiveness. Anti-lock brakes?

<snip>
 
Reply With Quote
 
 
 
 
Nick Keighley
Guest
Posts: n/a
 
      02-16-2010
On 16 Feb, 01:20, "Alf P. Steinbach" <(E-Mail Removed)> wrote:
> * Alf P. Steinbach:
>
>
>
>
>
> > * James Kanze:

>
> >> In fact, the fact that running out of stack cannot be gracefully
> >> caught means that we do have to do something. *But don't confuse
> >> the cause and the effect.

>
> > Another angle is to focus on prevention rather than detection.

>
> > A semi-portable way to check for available stack space is to use the de
> > facto standard 'alloca', which it seems has the same behavior on a wide
> > range of platforms, returning NULL if there isn't enough space.

>
> > Curiously, I've never used that solution; what it solves seems to not be
> > that big a problem in practice, i.e. it's probably a solution looking
> > for a problem?

>
> > And I can imagine that on some systems the alloca that I mentioned here
> > might cause virtual allocated address space to be mapped to actual memory.

>
> > Which might slow down things.

>
> Oh, discovery:
>
> the reason that I've never used the alloca technique that I mention above seems
> to be that alloca *is not* consistently defined on different platforms.
>
> * *<url:http://www.mkssoftware.com/docs/man3/alloca.3.asp>
> * *guarantees 0 on error,
>
> * *<url:http://msdn.microsoft.com/en-us/library/wb1s57t5%28VS.71%29.aspx>
> * *guarantees a "stack overflow exception" on error, and
>
> * *<url:http://www.kernel.org/doc/man-pages/online/pages/man3/alloca.3.html>
> * *says the error behavior is undefined.
>
> Perhaps the group can benefit from this info.



I understand it doesn't "play well" with C99's vararray. How well does
it interact with new/delete?
 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      02-16-2010
* Nick Keighley:
> On 16 Feb, 01:20, "Alf P. Steinbach" <(E-Mail Removed)> wrote:
>> * Alf P. Steinbach:
>>
>> the reason that I've never used the alloca technique that I mention above seems
>> to be that alloca *is not* consistently defined on different platforms.
>>
>> <url:http://www.mkssoftware.com/docs/man3/alloca.3.asp>
>> guarantees 0 on error,
>>
>> <url:http://msdn.microsoft.com/en-us/library/wb1s57t5%28VS.71%29.aspx>
>> guarantees a "stack overflow exception" on error, and
>>
>> <url:http://www.kernel.org/doc/man-pages/online/pages/man3/alloca.3.html>
>> says the error behavior is undefined.
>>
>> Perhaps the group can benefit from this info.

>
>
> I understand it doesn't "play well" with C99's vararray.


Didn't know that but it stands to reason; they compete for the same resource.


> How well does it interact with new/delete?


I can't see any reason why the features should interact in any way. alloca
adjusts the stack pointer. new/delete allocate from some heap.

At least in Windows programming a major usage of alloca is to allocate strings
efficiently for conversion between char strings and wchar_t strings.

And there's no problem with that, when used correctly, but alloca is a very
fragile low-level mechanism.


Cheers,

- Alf
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      02-16-2010
On Sat, 2010-02-13, James Kanze wrote:
> On 12 Feb, 21:50, "Leigh Johnston" <(E-Mail Removed)> wrote:
>> > It's not clear what types of errors you have in mind.
>> > Programming errors are generally best handled by immediately
>> > aborting, at least in production code, at least in most
>> > application domains. Depending on circumstances, other
>> > errors are best handled with exceptions or return codes.

>
>> Programming errors are best handled by fixing them,

>
> Programming errors are best handled by preventing them in the
> first place: carefully specifying each function, and reviewing
> the code which uses the function against the specification.
>
>> assert can help in this endeavour but *usually* only in debug
>> builds: release build asserts are best suited only where a
>> higher level of defensiveness is required, not for your
>> typical desktop application.

>
> Asserts are a sort of life jacket, to prevent things from
> ****ing up too much when you screwed up.


I see them as a self-destruct device (like the termonuclear wristwatch
in the action movie /Predator/) but it amounts to the same thing ...

(I see there is a long debate further down in the thread. I'll try
to ignore it; I stated my views in a similar thread a year ago or so.)

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      02-17-2010
On Feb 16, 11:49 am, "Leigh Johnston" <(E-Mail Removed)> wrote:
> >> It is a nonsense to say that virtual functions shouldn't be
> >> public: a public virtual destructor is fine if you want to
> >> delete through a base class pointer.


> > The destructor is an obvious exception. But most experts today
> > generally agree that virtual functions should usually be either
> > protected or private.


> > Again, there are exceptions, and I have classes with only public
> > virtual functions. (Callbacks are a frequent example.) But
> > they're just that: exceptions.


> You are talking garbage sorry: saying "print" is an exception
> or callbacks (abstract interfaces) are an exception is just
> wrong.


Print may be an exception, but I'm not convinced. I think
various call inversion sequences are a definite exception. But
a lot of the experts disagree with me, and do insist that
virtual functions never be public. (Look at the std::streambuf
hierarchy, for example.)

> These are only "exceptions" to some stupid rule that
> only a subset of the C++ community happen to agree with
> including yourself.


The "subset" includes most of the experts. People like Herb
Sutter, for example.

> As I disagree with this rule they are not exceptions in but
> simply normal C++ coding practice.


Normal for inexperienced programmers, perhaps, or those who
don't care about quality.

--
James Kanze
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      02-17-2010
On Feb 16, 12:00 pm, "Leigh Johnston" <(E-Mail Removed)> wrote:
> > Most people would disagree with you in general, concerning a
> > compiler. Why should it have an artificial hard limit?


> > In fact, the fact that running out of stack cannot be gracefully
> > caught means that we do have to do something. But don't confuse
> > the cause and the effect.


> A hard limit and graceful abort and/or user notification in
> anticipation of what would be a stack fault is more desirable
> than an actual stack fault.


I agree but...

> It is not that difficult to determine a hard limit, it will be
> proportional to the size of your stack.


To determine the limit, you have to know how much stack you are
using, and how much stack is available. In general, you know
neither.

--
James Kanze
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      02-18-2010
On Feb 17, 9:14 pm, "Leigh Johnston" <(E-Mail Removed)> wrote:
> Slightly off-topic but C# (Windows Forms) uses public virtual
> functions extensively it seems so again are people at
> Microsoft not experts nor care about quality? C# is supposed
> to be the latest and greatest.


C# is not C++, so I wouldn't expect the same idioms to apply.
And I'm not sure I'd consider Microsoft as an example when it
comes to quality.

--
James Kanze
 
Reply With Quote
 
Brian
Guest
Posts: n/a
 
      02-19-2010

On Feb 17, 3:14 pm, "Leigh Johnston" <(E-Mail Removed)> wrote:
>C# is supposed to be the latest
>


C++0x is the latest in terms of being in the oven a long time.


> and greatest.


My efforts are aimed at adding automated marshalling support
to C++ as is available in C#. I go further though than C#/Java
and make that support available on line.


Brian Wood
http://webEbenezer.net
(651) 251-9384
 
Reply With Quote
 
Brian
Guest
Posts: n/a
 
      02-19-2010
On Feb 15, 6:49 pm, James Kanze <(E-Mail Removed)> wrote:
> On Feb 14, 2:08 pm, "Leigh Johnston" <(E-Mail Removed)> wrote:
>
>
>
> > "James Kanze" <(E-Mail Removed)> wrote in message
> >news:(E-Mail Removed)...
> > > On Feb 13, 12:41 pm, "Leigh Johnston" <(E-Mail Removed)> wrote:
> > >> > Asserts are a sort of life jacket, to prevent things from
> > >> > ****ing up too much when you screwed up. Removing them
> > >> > from production code is akin to wearing a life jacket
> > >> > when practicing in the harbor, but taking it off when you
> > >> > go to sea. Sometimes, it's necessary to remove asserts
> > >> > for performance reasons, and for some particular
> > >> > applications (games?), it's probably preferrable to
> > >> > remove them completely (in which case, you do have to
> > >> > study what happens when they are removed---there's no
> > >> > point in removing an assert if you're just going to get a
> > >> > crash three statements later).
> > >> I disagree, why do you think assert was designed to do
> > >> nothing for NDEBUG?
> > > So that you can turn it off when you have to. The designed use
> > > would be to use some application specific macro, defined (or
> > > not) in the command line, and then to wrap the (few) critical
> > > functions in something like:
> > > #ifdef PRODUCTION
> > > #undef NDEBUG // Just in case.
> > > #define NDEBUG
> > > #include <assert.h>
> > > #endif
> > > void critical_function()
> > > {
> > > // ...
> > > }
> > > #undef NDEBUG
> > > #include <assert.h>
> > > Why do you think you're allowed to include <assert.h> multiple
> > > times, with it's meaning depending each time on the current
> > > definition of NDEBUG?
> > >> Asserts were designed to be used as a debugging tool so should
> > >> do nothing in released production code *unless* a higher
> > >> degree of defensiveness is required.
> > > That's your opinion. It doesn't correspond to the design of the
> > > feature, nor good programming practices.

> > Sorry but I disagree with your opinion.

>
> For the most part, I'm not stating opinion. Look closely at the
> design of assert, and the guarantees it gives you.
>
> > Different software has different requirements regarding how
> > defensive you should be. A typical application should not be
> > using assert to terminate in a released product.

>
> A typical application in what domain. It's clear that any
> critical software must terminate as soon as it is in doubt. And
> I've pointed out why this is true for an editor (and the same
> logic also holds for things like spreadsheets). I also
> recognize that there are domains where it isn't true. I'm not
> sure, however, what you consider "typical".
>
> > A released product should be using exceptions for errors which
> > are valid during runtime. Assert is used for catching
> > programming errors, not valid runtime errors or bad user
> > input.

>
> There's no disagreement on that.
>
>
>
> > >> I disagree that only games are an exception,
> > > They're certainly not the only exception. But such exceptions
> > > are just that, exceptions. Most software should ship with
> > > asserts turned on, *if* they can afford the performance impact.
> > > (An awful lot of software is IO bound, so the performance impact
> > > can be ignored.)
> > >> I would also argue that such defensiveness is not required for
> > >> a typical office application for example (e.g. a word
> > >> processor).
> > > It depends on whether you consider trashing the users work
> > > acceptable or not. And what the other costs are---since it
> > > costs nothing to leave it, assuming no performance problems, and
> > > requires extra work to remove it, it's more or less stupid to
> > > choose the less robust solution.

> > Programmers should get into the habit of adequately testing
> > their software prior to release (assert helps with this) and
> > users should get into the habit of regularly backing up their
> > important data.

>
> It would help if you'd read what was written, before disagreeing
> with it. No one is arguing against testing. And it's not the
> user who's backing up his data, it's the editor---all of the
> editors I know to day regularly checkpoint their data in case
> they crash. The whole point is that if there is a programming
> error, and the editor continues, it's liable to overwrite the
> checkpoint with corrupt data (or the user, not realizing that
> the data is corrupt, is liable to overwrite his own data).
>
> > >> The amount of software which requires less defensiveness
> > >> probably outnumbers the amount of software that requires
> > >> increased defensiveness. If you are worried about cosmic
> > >> rays hitting your ram chips then perhaps you should use
> > >> assert more!
> > > You should always use assert liberally. We're talking about
> > > whether you should turn it off in production code. In other
> > > words, whether you should take an additional, explicit action
> > > (defining NDEBUG) to render the software less robust.

> > Using assert liberally is fine (I have no problem with this)
> > but this (in most cases) is an aid during development only,
> > rather creating hundreds of crash points in a released product
> > (in most cases).

>
> If you've tested correctly, leaving the asserts active creates
> zero crash points in the released product. And if you've missed
> a case, crashing is the best thing you can do, rather than
> continuing, and possibly destroying more data.
>
> [...]
>
> > >> This is the usual argument put forward in favour of more
> > >> defensive programming but in my opinion having an assert after
> > >> every other line of code is overkill for a typical office
> > >> application as I have already said.
> > > I've never seen assert's used that heavily. And how often or
> > > where you write an assert is a different question---in general,
> > > a minimum would be to assert preconditions for a function, at
> > > least when that function is called from other modules, and
> > > post-conditions for a virtual function, when the derived classes
> > > may be called from other modules. (This means, of course, that
> > > your virtual functions shouldn't be public. But that's a pretty
> > > well established rule anyway.)

> > I am sorry but you are wrong, you should either be extremely
> > defensive or not defensive at all, somewhere in-between is
> > pointless.

>
> When someone starts issuing statements as ridiculous as that, I
> give up. It's not humanly possible to be 100% defensive.
>
> > Extremely defensive means at least one assert at some point
> > after call a function which has side effects (which could be a
> > precondition check before a subsequent function call). This
> > is overkill for typical desktop applications for example.
> > It is a nonsense to say that virtual functions shouldn't be
> > public: a public virtual destructor is fine if you want to
> > delete through a base class pointer.

>
> The destructor is an obvious exception. But most experts today
> generally agree that virtual functions should usually be either
> protected or private.
>
> Again, there are exceptions, and I have classes with only public
> virtual functions. (Callbacks are a frequent example.) But
> they're just that: exceptions.
>
> > Bjarne Stroustrup's first virtual function example in TC++PL
> > is a public Employee:rint() method, I see no problem with
> > this.

>
> For teaching, neither do I. (For that matter, a print function
> might be an exception. It's hard to imagine any reasonable pre-
> or post-conditions.)
>
> > You are probably thinking of virtual functions which are
> > called as part of some algorithm implemented in a base class,
> > such virtual functions need not be public as it makes no sense
> > for them to be but it does not follow that this is the case
> > for all virtual functions.

>
> No, I'm not thinking of the template method pattern. I'm
> thinking of programming by contract.
>
>


After considering this I find in my own work reasons for
making virtual functions private/protected. At first
I was a little skeptical as it does involve more work/
infrastructure, but find a couple of reasons to adopt
this approach: primarily it allows users a customization
point that otherwise wouldn't be there. Previously the
framework directly called a generated Send function.
Now I'm replacing a sometimes virtual and always
computer generated Send function with a never virtual
and not computer generated, by me at least, Send
function. Then I'm adding two virtual functions --
a private SendTypeNum, and a protected SendMemberData.
http://webEbenezer.net/rbtree/rbtree_marshalling.hh
has examples of this.

A sample implementation of a user-written Send
function looks like:

void
Send(SendBuffer* buf, bool sendType) const
{
if (sendType) {
SendTypeNum(buf);
}
SendMemberData(buf);
}

The value for sendType is determined by
checking the context. If I find a pointer
use, vector<Shape*>, I'll set it to true.
I'll also set it to true for boost::intrusive
uses. rbtree<Base>, for example, can hold either
Base or derived types. Other than that I think
it's set to false. So if you want to marshall a
vector<Triangle>, type numbers won't be included
in the stream. (It's possible that the Triangle
instances are intended to be received in an
rbtree<Shape> container and you actually want the
type numbers. In that case though, you would have
to change your marshalling interface. Another
possibility would be to let users override the
default process for determining the sendType
value. Something like (vector<Triangle> @type_nums).)

Another benefit that I notice is the approach, while
a little more difficult to put in place, makes it
more difficult for someone to mess things up once
it is in place.


Brian Wood
Ebenezer Enterprises
http://webEbenezer.net
(651) 251-9384
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
testing testing 123 neville Computer Support 7 06-28-2005 05:06 PM
testing testing neville Computer Support 16 06-05-2005 09:02 PM
testing testing neville Computer Support 2 05-27-2005 09:57 AM
testing testing 123 daniel edwards Computer Support 4 05-20-2004 10:36 PM
testing--news2004--testing Boomer Computer Support 3 09-24-2003 06:54 PM



Advertisments