Testing Program Question

[Jorgen Grahn]

The article which brought the idea into mainstream programming
is http://www.gotw.ca/publications/mill18.htm, by Herb Sutter. ....

Thanks!


There's nothing wrong with run-time polymorphism, when it solves
the problem at hand. Like everything else, however, it's not a
silver bullet. It adds complexity, and if that complexity
doesn't buy you something more valuable in return, you shouldn't
introduce it.

Yes. I *do* use it when it makes sense; it's just that it makes sense
to me more seldom than it seems to do for many others. (But I don't
think the issue Sutter raised is a main reason for that.)

/Jorgen

 

[James Kanze]

49 am, "Leigh Johnston" <[email protected]> wrote:

[...]

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.
I don't want to get involved in an old argument, but James,
where can I read more about the reasoning behind this? It was
a new opinion to me; I don't think I've come across it before.

The article which brought the idea into mainstream programming
ishttp://www.gotw.ca/publications/mill18.htm, by Herb Sutter.

That article says, "Don't derive from concrete classes."

Citing another document which explains why.

I don't know of a better way to support multiple versions
of a client. The versioning that some well-known
serialization libraries tout encourages people to use one
class and conditionals to support multiple versions within
the class. I think that approach is very weak and that
deriving from a concrete class is the better alternative.

I'm not sure. I've never seen an implementation of verionning
which used derivation. I'm not sure it can be made to work, but
perhaps I'm just misunderstanding what you're proposing.

 

[James Kanze]

Do you have any evidence that this idea is in the "mainstream"
and not just the personal viewpoint of a select group of
individuals including yourself?

For better or for worse, what Herb Sutter recommends is the
"mainstream". He's that influential.

You seem to like name dropping, I believe Scott Meyers
disagreed with Herb Sutter on this.

It's not name dropping to cite a reference to an article when
asked for one. And I'd be interested in seeing where Scott
Meyers recommended otherwise (in a publication later than
Herb's).

 

[Alf P. Steinbach]

* Leigh Johnston:

Do you have any evidence that this idea is in the "mainstream" and not
just the personal viewpoint of a select group of individuals including
yourself? You seem to like name dropping, I believe Scott Meyers
disagreed with Herb Sutter on this.

Hey, this not [comp.lang.scriptlanguage]. James has /never/ used an authority
argument as long as I can remember. It's just that when it's a matter of
judgement for large scale development, then the people that one knows about
advancing the state of the art are bound to be known, it's sort of self evident
that it must be so.

Perhaps not self evident: somewhere else, I don't recall if it was in this
thread (probably it was), you checked up on your own argument when discussing
things with me, and found inline code in the Microsoft COM IUnknown interface. I
thought that was pretty decent of you to tell in public! But you may not be
aware that it's fairly recent code, and that Herb most likely was chief
architect of the Visual C++ team at the time that that code was introduced.

I'm suspecting a connection... ;-)


Cheers,

- Alf

 

[James Kanze]

In a single threaded program the maximum stack size is usually
a linker setting. Stack size *is* *usually* deterministic.

How many different platforms do you know? I've worked on quite
a few, and I'm only aware of two where stack size is set at link
time: Windows and HP/UX. On most systems (at least since the
PDP-11), in a single threaded program, stack size is more or
less open, and determined at runtime: the code goes at the
bottom, followed by the static data, and the start of the heap,
which grows up; the stack goes at the top, and grows down. And
you run out of stack when the two meet. Except that on a
modern, 64 bit machine, you'll run out of virtual memory a lot
earlier.

 

[James Kanze]

Under Linux at least, the maximum stack size can be set. AFAIK
it is set by the administrator and can be redefined per shell.
The linker may requires a specific amount of stack but I don't
see how it could control the maximum size.

ulimit -s unlimited

works on all of the Linux systems I've been exposed to (although
I'm pretty sure that the administrator can configure some lower
upper limit).

 

[Brian]

]
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.
I don't want to get involved in an old argument, but James,
where can I read more about the reasoning behind this?  It was
a new opinion to me; I don't think I've come across it before.
The article which brought the idea into mainstream programming
ishttp://www.gotw.ca/publications/mill18.htm, by Herb Sutter.

That article says, "Don't derive from concrete classes."

Citing another document which explains why.

I don't know of a better way to support multiple versions
of a client.  The versioning that some well-known
serialization libraries tout encourages people to use one
class and conditionals to support multiple versions within
the class.  I think that approach is very weak and that
deriving from a concrete class is the better alternative.

I'm not sure.  I've never seen an implementation of verionning
which used derivation.  I'm not sure it can be made to work, but
perhaps I'm just misunderstanding what you're proposing.

I've taken this from one of my pages. It ammounts
to guidelines for handling multiple versions rather
than any type of version support.


release
1.1 1.2 1.3 1.4
-----------------------------------------------------------
class name Account Account Account_13 Account_13

The class name incorporates the release in which it was
last changed. Let's say that the 1.3 version of the server
is required to support 1.1 clients. To do this the server is
built with both the Account and Account_13 definitions.

When only additions to Account are needed between releases,
the software might be structured like this:

AccountBase
|
Account
|
Account_13

If data members need to be relocated out of Account
in the 1.3 release, the hierarchy might be:

AccountBase
/ \
Account Account_13


There's some terminology for different approaches
to version support, but at the moment I'm not
remembering it. Boost's approach might be called
internal version support and mine might be called
external(do-it-yourself) -- advice. I'm of the
opinion that no matter how minor a change to the
data members of a class, you should introduce a new
name for that class. Boost versioning support is
in my opinion best avoided. What it amounts to is
changing 1.1 code in order to support 1.3. If you
do that, I think you're more likely to introduce
problems for 1.1 users. My approach uses unchanged
1.1 code (in the 1.3 release) to support 1.1 users.
Also, the Boost approach uses one big class to
support both 1.1 and 1.3 users. That is inefficient
when it comes to supporting 1.1 users; the 1.3
fields are there whether you need them or not.
There are also inefficiencies that come from
frequent testing of the version number with the
Boost approach.


Brian Wood
http://webEbenezer.net
(651) 251-9384

 

[Brian]

I've taken this from one of my pages.  It ammounts
to guidelines for handling multiple versions rather
than any type of version support.

                           release
               1.1     1.2          1.3            1.4
-----------------------------------------------------------
class name    Account  Account     Account_13    Account_13

The class name incorporates the release in which it was
last changed.  Let's say that the 1.3 version of the server
is required to support 1.1 clients. To do this the server is
built with both the Account and Account_13 definitions.

When only additions to Account are needed between releases,
the software might be structured like this:

AccountBase
     |
  Account
     |
 Account_13

If data members need to be relocated out of Account
in the 1.3 release, the hierarchy might be:

   AccountBase
     /     \
Account Account_13

There's some terminology for different approaches
to version support, but at the moment I'm not
remembering it.  Boost's approach might be called
internal version support and mine might be called
external(do-it-yourself) -- advice.  I'm of the
opinion that no matter how minor a change to the
data members of a class, you should introduce a new
name for that class.  Boost versioning support is
in my opinion best avoided.  What it amounts to is
changing 1.1 code in order to support 1.3.  If you
do that, I think you're more likely to introduce
problems for 1.1 users.  My approach uses unchanged
1.1 code (in the 1.3 release) to support 1.1 users.
Also, the Boost approach uses one big class to
support both 1.1 and 1.3 users.  That is inefficient
when it comes to supporting 1.1 users; the 1.3
fields are there whether you need them or not.
There are also inefficiencies that come from
frequent testing of the version number with the
Boost approach.

While technically the Boost approach allows one
to fulfil the advice of not deriving from a
concrete type, the negative side effects of the
Boost approach outweigh the advantages.



Brian Wood
http://webEbenezer.net
(651) 251-9384

 

[Jerry Coffin]

"Don't derive from concrete classes"? Oh the fucking lulz. Some of the
garbage spouted in this newsgroup beggars belief. What utter, absolute
drivel.

Interestingly, as far as I know Scott Meyers first wrote about that
idea, first published (at least AFAIK) in the July/August 1994 issue
of the _C++ Report_.

He wrote a rather long post about some of the argument and discussion
that prompted, still available (Google willing) at:

http://groups.google.com/group/comp.lang.c++/browse_frm/thread/ad091a
9b469a5c05/dc1a601560ba8dcf