Future of C++
Abhishek
This is a non-technical off topic post, so please excuse me for that.
I wanted to understand from the Gurus of C++ out here about their opinion on
the future of C++. I have spent eight plus years in the software industry
working in applications programming on C++/ Windows. My current company is
now moving big time towards Java/ J2EE based technologies. Most of the other
companies which are writing application software are also moving (or have
alreadt moved) to J2EE or to .Net. So is there no future for C++ in
application software? What do the people on this group feel about it?
I understand that Systems side and Embedded are still the areas where C++ is
being used well. But is that all? What do the people who have invested time
and energy in C++ should do? Learn Java or C# because a significant majority
of other developers (apparently) could not free the pointers and found
garbage collector to be a great idea.
Thoughts/ Suggestions/ Criticism?
Regards
Abhishek
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Mathias Gaunard
> Hi All,
> This is a non-technical off topic post, so please excuse me for that.
>
> I wanted to understand from the Gurus of C++ out here about their opinion on
> the future of C++.
The future is decided by the ISO standardization committee.
You can go and look at their working papers, they're open. The next
standard is expected to arrive in a few years, with some parts already
implemented in some compilers, such as GCC.
> I have spent eight plus years in the software industry
> working in applications programming on C++/ Windows. My current company is
> now moving big time towards Java/ J2EE based technologies. Most of the other
> companies which are writing application software are also moving (or have
> alreadt moved) to J2EE or to .Net. So is there no future for C++ in
> application software? What do the people on this group feel about it?
I personally use C++ because I think it's a fairly well-designed
language, that can as safe as any while still having a backdoor for
when you want to use tricks, and that doesn't add overhead when you
don't need it.
I especially like being able to abstract anything as values (redefine
copying, moving, assignment, construction and destruction) and its
deterministic destruction system coupled with exceptions makes it the
best language to deal with resources in my opinion.
Also, C++ can do meta-programming and limited forms of static
reflection, which makes it one of the most interesting generic
programming platform.
> I understand that Systems side and Embedded are still the areas where C++ is
> being used well. But is that all?
As far as I know, the game development community uses it a lot, albeit
not a very modern dialect (I clearly said from my experience it's
ugly, hacky and C-ish in another thread).
Apart from that I don't know about any stereotypical part of the
industry that makes use of it.
Like with most languages, some use C++, some don't. It's a matter of
taste, of existing work that can be reused, of efficiency...
> What do the people who have invested time
> and energy in C++ should do? Learn Java or C# because a significant majority
> of other developers (apparently) could not free the pointers and found
> garbage collector to be a great idea.
"Free the pointers"? What kind of C++ have you been using? C?
In C++, you certainly do not need to manually free resources. You have
RAII for that, which is much more robust than garbage collection.
Pointers shouldn't be used at all in my opinion.
HumbleWorker
> "Free the pointers"? What kind of C++ have you been using? C?
> In C++, you certainly do not need to manually free resources. You have
> RAII for that, which is much more robust than garbage collection.
> Pointers shouldn't be used at all in my opinion.
{ Edits: quoted clc++m banner removed. It's /automatically/ appended to every
article, including this one, and thus, does not need to be quoted. -mod }
Hey !
C++ is a philosophy. You cannot really understand other languages
without knowing C++. Then, C++ has a productivity un-paralleled
elsewhere. .NET/Java can be good for small scale applications but
large scale applications are invariably written in C++. You are forced
to depend on somebody to write a .NET/Java wrapper before you can come
out with a product. With C++ you have a tremendous freedom to design
your appication. Yes, there is one thing, if you think you can be
productive and efficient with raw C++, then you are wrong. You do need
to have your own API wrappers around common tasks which your area of
specialization requires.
Languages have come and gone, will continue to come, but C++ has
stayed on the scene. I cannot think of a software world without C++.
No OS can afford to expose APIs without caring for C/C++. You have
Symbian, you have UNIX, you have Windows, and many more, but they
cannot afford to ignore the common language called C++. Can you, for
example, fathom a world without the English language ?
I have been a C++ programmer ever since, and till today companies
approach me for writing their solutions in C++, when they have hosts
of programmers in VB/Java/.NET on their rolls, because the performance
of C++ compells them.
TO MY FRIEND ABHISHEK: Please hang on with C++, the demand supply
theory says you can earn more if lesser people stay in competition.
HW
ManicQin
wrote:
> I wanted to understand from the Gurus of C++ out here about their opinion on
> the future of C++. I have spent eight plus years in the software industry
> working in applications programming on C++/ Windows. My current company is
> now moving big time towards Java/ J2EE based technologies. Most of the other
> companies which are writing application software are also moving (or have
> alreadt moved) to J2EE or to .Net. So is there no future for C++ in
> application software? What do the people on this group feel about it?
I'm a fairly new player in this game... 5 or 6 years in the industry.
and as a c++\.Net programmer only 3 years (on and off)
When I look at the companies that I used to work in\with
(C^3 \ communication \ cellular \ video \ Retail \ Hardware and much
more)
They were all using C++ and I know that they are going to keep on
using it.
The problem of C++ from my P.O.V. is that people learn the basics in
high school
and they stay there, many companies prefer working with C & classes
rather than
working with complete OO. until they meet .Net\Java that forces them
to
work by the OO paradigm.
People don't understand that the principals that Java and .Net are
infrastructured
upon already exist in C++. In the new languages they are only wrapped
in a prettier
wrapper that's all.
The most significant advantage of .Net & Java over C++ is the
GUI'd applications BUT C++ gives a good fight with infrastructures
such as QT.
But again this types of infrastructures are not known enough.
Because C++ allows you to work C & Objects people are missing the
point
the new standard will keep on missing the point and people will keep
on working as always... but nevertheless C++ will keep on living.
Jurko Gospodnetić
> Pointers shouldn't be used at all in my opinion.
Hmmm... maybe I'm taking this sentence out of context but... seems
rather harsh does it not?
Until somone invents an 'assignable reference' (i.e. a pointer that
is never null) I do not think it is possible to program without
pointers. And, sometime you really want to have a 'reference variable'
that points to nothing, which is something you can do only with pointer
or additional variables and more complex code.
I guess you meant - there should be no need for manual heap based
memory deallocation in application code. There must be some in
library/infrastructure code of course...
Best regards,
Jurko Gospodnetić
Joshua...@gmail.com
> The future is decided by the ISO standardization committee.
Sadly, no. They have a great deal of influence, but if the industry
moves away from it, there's nothing they can do to prevent its
demise.
On Aug 4, 10:28 pm, Mathias Gaunard <loufo...@gmail.com> wrote:
> "Free the pointers"? What kind of C++ have you been using? C?
> In C++, you certainly do not need to manually free resources. You have
> RAII for that, which is much more robust than garbage collection.
> Pointers shouldn't be used at all in my opinion.
As you, I can't speak for the entire industry, but sadly my impression
is similar to Abhishek's. At the software engineering career fair I
went to in school before I obtained my current job, most were working
in Java. At the company I currently work at, several years ago the
majority of the code was in C with classes / hackish C++ code. Now
it's mostly Java.
When I talk to people in my company, there are several reasons for
this trend towards Java in our company.
Firstly, Java is actually platform independent. We compile and sell
our code on pretty much every server platform there is. HP-UX,
windows, linux, unix, etc. Java actually works on all of them with
very little effort on our part, whereas some of these systems have
outdated C++ compilers. Each of the C++ compilers has their own little
quirks, especially with newer features, like templates and exceptions.
I appreciate open source software, but sometimes I wish a "benevolent"
company like Sun owned the copyrights to C++, and they ran it like
they do Java. If you advertise yourself as Java X, and you're not Java
X, they'll sue you, like they did to Microsoft. It enforces everyone
to actually follow the standard. As of this writing, I don't know any
compiler which actually follows the entire standard. Comeau is close,
but I think they still have one or two minor problems. (There was a
thread here a little while ago about some template problem which
Comeau and Visual Studios had.)
The second most important reason is the belief that most programmers
have a higher productivity in Java, and specifically, they'll write
code with less errors. Sadly, I again might have to give this point to
the Java people. Most of the errors result in memory issues, and
garbage collection removes this problem. I really like RAII, but the
bugs in a program tend to be memory related, so the Java code s
probably less buggy with its garbage collection, built in bounds
checking, null pointer checking, etc.
Another thing they claim is that there are more free third party
libraries to use written in Java than C++. Analogous is their liking
for built in Java libraries, like regular expressions, xml, zip
utilities, asynchronous / simultaneous IO, etc. Threading, for
example. I am definitely glad the new standard will add threading to
the standard c++, but how long will it take for all compilers to
actually support it? 5 years? And all of those obscure systems that we
support? I don't know how well maintained their C / C++ compilers
are.
The last reason is the, possibly mistaken, belief that most / all
programs written in Java are about as fast as C++. For certain
applications, I can give this to them. However, our company does
number crunching, and other data intensive work, which is one of those
areas which I think it's generally accepted by the Gurus that C++ is
faster, significantly.
Overall, for C++ to survive IMHO, compiler writers need to actually
follow the standard. They do, eventually, but people are moving to
Java in the meantime, and basic libraries must be available, like
threading. Without these, I still see very performance critical
applications still written in C++, like games, but a vast amount of
other programs will move to Java, and that makes me sad, because I
really like C++.
The other thing which would help is if people actually knew the
correct idioms for C++. Writing good C++ code is not that error prone,
but most of my colleagues write C With Classes code, because they
don't know any better. I'd like to think the education I've received
was one of the better ones in the US, but even then, RAII was not
mentioned. Argument dependent lookup was not mentioned. Very critical
concepts were left out. One learns about this only when going out on
your own, or if you happen to be in one of the more knowledgeable
companies.
Rafał
> time and energy in C++ should do? Learn Java or C# because a significant
> majority of other developers (apparently) could not free the pointers and
> found garbage collector to be a great idea.
Good C++ do need marketing.
There are GC's for C++.
No need to "free pointers" in C++, just user boost shared_ptr/weak_ptr or
others (or GCs).
Apparently the people you describe should
1. get a clue
2. learn modern C++.
As I said... C++ used correctly (with boost etc) do need some marketing.
Francis Glassborow
> Hi Mathias.
>
>> Pointers shouldn't be used at all in my opinion.
>
> Hmmm... maybe I'm taking this sentence out of context but... seems
> rather harsh does it not?
>
> Until somone invents an 'assignable reference' (i.e. a pointer that
> is never null) I do not think it is possible to program without
> pointers. And, sometime you really want to have a 'reference variable'
> that points to nothing, which is something you can do only with pointer
> or additional variables and more complex code.
Pointers are a low level feature that are necessary to a language such
as C++ that aims to be a broad spectrum language including close to
assembler level programming up to highly abstracted application level
programming.
However naked pointers are largely unnecessary at application level.
Almost always pointers should be encapsulated into some higher level
library type.
--
Note that robinton.demon.co.uk addresses are no longer valid.
carl.s...@gmail.com
> being used well. But is that all?
Hi,
Look around you: how many electronic devices do you see? Chances are
most of them are some kind of embedded system. My guess is that it
won't be long before the number of embedded systems programmers
becomes comparable to that of, say, programmers working on shelfware.
And I think I even remember seeing somewhere that the industry is
exactly were C++ is gaining market share [citation needed].
So my guess is that C++ skills will still have value for some time.
Cheers,
Carl
Jiang
> On 4 aoūt, 23:57, "Abhishek" <nospam_abhishekpan...@yahoo.com> wrote:
>
First, I am not Guru as you expected, but
> > I wanted to understand from the Gurus of C++ out here about their opinion on
> > the future of C++.
>
I think Gurus here were tired of answering this kind of questions
and perhaps you won't get their opinions anymore :-)
> The future is decided by the ISO standardization committee.
> You can go and look at their working papers, they're open. The next
> standard is expected to arrive in a few years, with some parts already
> implemented in some compilers, such as GCC.
According to Abhishek's post, this is irrelative at all.
Also please note in the sense of "language's life cycle", no one can
decide the future of C++ language.
> > I have spent eight plus years in the software industry
> > working in applications programming on C++/ Windows. My current company is
> > now moving big time towards Java/ J2EE based technologies. Most of the other
> > companies which are writing application software are also moving (or have
> > alreadt moved) to J2EE or to .Net.
Would you please give a list of "the other companies" ?
> > So is there no future for C++ in
> > application software? What do the people on this group feel about it?
>
So please define "no future".
In the middle 90's of last century, it is said Java will kill C++
easily within
just 2 years.
It is false, obviously.
> I personally use C++ because I think it's a fairly well-designed
> language, that can as safe as any while still having a backdoor for
> when you want to use tricks, and that doesn't add overhead when you
> don't need it.
> I especially like being able to abstract anything as values (redefine
> copying, moving, assignment, construction and destruction) and its
> deterministic destruction system coupled with exceptions makes it the
> best language to deal with resources in my opinion.
> Also, C++ can do meta-programming and limited forms of static
> reflection, which makes it one of the most interesting generic
> programming platform.
>
> > I understand that Systems side and Embedded are still the areas where C++ is
> > being used well. But is that all?
>
IMHO, find what C++ can not do is easier.
> As far as I know, the game development community uses it a lot, albeit
> not a very modern dialect (I clearly said from my experience it's
> ugly, hacky and C-ish in another thread).
>
Things changed quite a lot these days.
Take a look at engines like Ogre, Irrlicht, cs, bullet, wildmagic...
please.
> Apart from that I don't know about any stereotypical part of the
> industry that makes use of it.
For a very short list:
http://www.research.att.com/~bs/applications.html
> Like with most languages, some use C++, some don't. It's a matter of
> taste, of existing work that can be reused, of efficiency...
>
> > What do the people who have invested time
> > and energy in C++ should do?
Learning Java or .Net if it is the best tool for your job at hand.
I don't see any reason that your C++ background will be an obstacle.
On the country, I believe you will find the switching it is easier.
(Not true for the reverse :-) )
> > Learn Java or C# because a significant majority
> > of other developers (apparently) could not free the pointers and found
> > garbage collector to be a great idea.
Or, show them the Boehm garbage collector?
So you see the degree of freedom is different.
Add garbage collection to C++ language is possible, however I
don't believe you and run your great cross-platform Java programs
without JVMs.
BTW, Java, together with .Net are not merely a programming language.
They are also religions/weapons. C++ language does not have such
a property.
> "Free the pointers"? What kind of C++ have you been using? C?
> In C++, you certainly do not need to manually free resources. You have
> RAII for that, which is much more robust than garbage collection.
> Pointers shouldn't be used at all in my opinion.
For both educational and technical aspects, the above statement is
too strong in my mind.
Jiang
Mathias Gaunard
> Until somone invents an 'assignable reference' (i.e. a pointer that
> is never null) I do not think it is possible to program without
> pointers.
Resetable references are different from pointers.
A resetable reference is always initialized from an object it must
reference and doesn't allow pointer arithmetic.
That enough makes it much safer than pointers, and a good reason to
use them instead.
> And, sometime you really want to have a 'reference variable'
> that points to nothing
Do you mean like an optional object? Just take an optional<T>, or a
variant<T, null_type>.
francis_r
> being used well. But is that all? What do the people who have invested time
> and energy in C++ should do? Learn Java or C# because a significant majority
> of other developers (apparently) could not free the pointers and found
> garbage collector to be a great idea.
On the desktop C++ has been losing ground mostly to web applications.
And it is there that Java and C# have their playground. But when it
comes to desktop applications C++ is still the standard choice. How
many popular programs do you know are written in Java/C#? (I am not
aware of many.)
restor
> most of them are some kind of embedded system. My guess is that it
> won't be long before the number of embedded systems programmers
> becomes comparable to that of, say, programmers working on shelfware.
> And I think I even remember seeing somewhere that the industry is
> exactly were C++ is gaining market share [citation needed].
>
> So my guess is that C++ skills will still have value for some time.
There is one more interesting application for C++: writing virtual
machines for Java and similar. Obviously, for efficiency reason they
have to be written in C/C++.
Regards,
&rzej
Alex
> On Aug 4, 10:28 pm, Mathias Gaunard <loufo...@gmail.com> wrote:
>
> > The future is decided by the ISO standardization committee.
>
> Sadly, no. They have a great deal of influence, but if the industry
> moves away from it, there's nothing they can do to prevent its
> demise.
That's true, but in spite of Sun trying really hard for over a decade,
there are no signs of that happening. Java was supposed to cause the
demise of C++ about 10 years ago. According to Tiobe (definitely not
perfect but the only metric that I know of that gives some idea of
where the programming languages are going - http://tinyurl.com/5thays
), in 2005 they were still tied. Currently, Java is a bit ahead
(again).
>
> On Aug 4, 10:28 pm, Mathias Gaunard <loufo...@gmail.com> wrote:
>
> > Pointers shouldn't be used at all in my opinion.
This is extreme position. Of course they should be used where
appropriate. Very carefully.
On Aug 5, 10:28 am, JoshuaMaur...@gmail.com wrote:
> Firstly, Java is actually platform independent.
In theory, yes. And, as we know, theory and practice are the same. In
theory. But not in practice.
Certain Eric Bruno ( see
http://dobbscodetalk.com/index.php?option=com_myblog&show=Targeting-Specific-Java-Versions-and-using-javap--559.html&Itemid=29
for details) starts his blog with this sentence:
"I recently worked on a project where it became necessary to determine
the version of the compiler that individual class files were compiled
with."
One would think he's talking about C or C++. Surprise, surprise - the
post is actually about Java and joys of targeting different VMs.
Or "What Are Your Java ME Pain Points, Really?" post on Artima:
"The main painpoint for Java ME is that it isn't 'write once, run
anywhere'."
(from http://www.artima.com/forums/flat.jsp?forum=106&thread=205707 )
So, the pipe dream called WORA is slowly dissolving. At the same time,
modern C++ compilers are at quite good compliance level. So 'write
once, compile anywhere' is not a pipe-dream anymore.
> they do Java. If you advertise yourself as Java X, and you're not Java
> X, they'll sue you, like they did to Microsoft. It enforces everyone
> to actually follow the standard.
Except that there is no such thing as "Java standard". What people
call standard is actually what Sun decides. Speaking of which, it is
interesting to learn how Java got pushed out the door and missed some
important opportunities to do things right. See "Seeking the Joy in
Java":
http://www.artima.com/weblogs/viewpost.jsp?thread=173229
Hard to believe, but three years after STL was approved for the
upcoming standard, Sun did not see fit to put parameterized types in
the language. The rest is history (as described by said Eric Bruno).
> As of this writing, I don't know any
> compiler which actually follows the entire standard. Comeau is close,
> but I think they still have one or two minor problems. (There was a
> thread here a little while ago about some template problem which
> Comeau and Visual Studios had.)
Funny as it is, in spite of all that, Sun decided to actually
implement their HotSpot in - C++. Also, see the quote from blog above.
> The second most important reason is the belief that most programmers
> have a higher productivity in Java, and specifically, they'll write
> code with less errors. Sadly, I again might have to give this point to
> the Java people.
Without any intent to insult anyone and knowing that it is impossible
in practice, I think it would be really interesting to obtain a
cumulative capability/productivity indicator for programming language
communities. I have some serious doubts Java would beat C++ programmer
population, in spite of very likely much higher head count.
Admittedly, there is way too much lousy C++ code around, though.
> Another thing they claim is that there are more free third party
> libraries to use written in Java than C++. Analogous is their liking
> for built in Java libraries, like regular expressions, xml, zip
> utilities, asynchronous / simultaneous IO, etc. Threading, for
> example. I am definitely glad the new standard will add threading to
> the standard c++, but how long will it take for all compilers to
> actually support it? 5 years? And all of those obscure systems that we
> support? I don't know how well maintained their C / C++ compilers
> are.
The main problem with C++ libraries is not scarcity. If you add C libs
to the mix, you have anything you want. The problem, rather, is the
"too wide variety of look-and-feel" syndrome. Also, there's a lot of
reinventing the wheel (e.g. string, containers) stuff around. We've
been trying to address those particular issues with POCO ( http://pocoproject.org
).
> Overall, for C++ to survive IMHO, compiler writers need to actually
> follow the standard. They do, eventually, but people are moving to
> Java in the meantime, and basic libraries must be available, like
> threading. Without these, I still see very performance critical
> applications still written in C++, like games, but a vast amount of
> other programs will move to Java, and that makes me sad, because I
> really like C++.
People are also moving from Java at the same time. People move around
a lot when they have different needs or until they realize that there
is no such thing as one true language. I'd be happy if Java was that,
but it's not. Neither is C#.
> The other thing which would help is if people actually knew the
> correct idioms for C++. Writing good C++ code is not that error prone,
> but most of my colleagues write C With Classes code, because they
> don't know any better. I'd like to think the education I've received
> was one of the better ones in the US, but even then, RAII was not
> mentioned. Argument dependent lookup was not mentioned. Very critical
> concepts were left out. One learns about this only when going out on
> your own, or if you happen to be in one of the more knowledgeable
> companies.
Well, someone said "Those who know how to do, do. Those who don't -
teach.". With all the goofiness, often there is truth to that
statement and you may have fallen victim to some of those folks.
And, for the end, a (unrelated but abstractly appropriate ;-) quote
from OpenBSD creator Theo de Raadt ( http://kerneltrap.org/node/6550
):
"Nor do I think it is a newer and better or brighter or has less
calories; everything we build is turds, we just move them around or
shine them or have a different view on which way they should be
rolled."
Cheers,
Alex
Le Chaud Lapin
On Aug 4, 4:57 pm, "Abhishek" <nospam_abhishekpan...@yahoo.com> wrote:
> Hi All,
> I wanted to understand from the Gurus of C++ out here about their opinion on
> the future of C++. [snip]
I think C++ is under attack from multiple factions, but will survive
ultimately.
I am not going to talk about the technical intricacies of C++ versus
other languages, since several responders have done that. Instead, I
would like to talk about what I believe is the crux of the issue:
Competence.
There is a peculiar social dynamic at play in, and C++ is at the
center of this dynamic.
But first some notes:
1. There is great value in software products.
2. Software has zero material cost, so waste of material during
construction is essentially impossible.
3. Producers recognize that software has zero material cost and that,
if they could simply get employees to produce, untold riches await.
[Think Bill Gates, Larry Ellison, etc versus billionaires who waited
300 years through hard work.]
4. Employees recognize that the barrier to entry to computer
programming is relatively low and the pay is extreme.
5. There is an insufficient number of real software engineers
available to create the products.
6. Two engineers, both with same base name in title ("Software
Engineer I/Software Engineer V") can often the found less than 10
meters away from each other, with incommensurate correlation between
pay and competence. The "Software Engineer I" might not be an engineer
at all, but someone who haphazardly gained a minimal level of
knowledge to enter field and get foot in door. By contrast, there is
no such thing as a "Neurosurgeon I" who was formerly the technician
who operated the CAT Scanner, but managed to get "Surgeon" placed in
his/her title by staying with company and being obedient and good-
natured for 5 years.
7. Managers are frustrated with the gap between requisite competence
and available competence and seek, in vain, a silver bullet that will
make it possible for programmers to be simultaneously incompetent and
highly productive.
8. Incompetent programmers are frustrated at the gap between requisite
competence and their own incompetence and seek, in vain, a silver bull
that will make it possible to be simultaneously incompetent and highly
productive.
9. Certain right-brained individuals entered the field of software
engineering for several reasons, which just happened to include
excellent pay. They have started a Class War, where there goal is to
blur the distinction between those that are predisposed to think like
engineers and those who are not. [Those of you reading this in the
USA, with children, might be aware of the recent "There Is No Right
Answer, Only How You Feel When You Respond Matters" trend in
elementary mathematics courses.] These right-brained individuals tend
to create programming languages that cater to a sloppy, meandering,
will-do-it-when-we-get-there mode of thinking. Google "social
programming language" to see which languages are guilty. [Ruby
anyone]?
10. Large corporations learned that pseudo-engineers, despite their
sloppiness, are actually very good for the balance sheet. In fact, it
is the very nature of the sloppy, sprawling, unwieldly, soup-like
systems that require expensive tools to (hopefully) de-slop them.
Enter .COM, .NET, C#, ASP...list is endless. Incompetent programmers
are being sold an illicit drug and the detox solution simultaneously.
[Also, the CEO of Top-4 software company once said at company
meeting...'You know, making our product a mess is not such a bad idea.
The more the customer is confused, the more likely they are to
overbuy'.]
What does this all mean for future of C++?
C++ is not going anywhere for a long, long time. It will likely
outlast FORTRAN. If FORTRAN is 52 as of 2008, C++ will probably last
more than 100 years.
So the reason C++ will stay put has very little to do with virtual
functions, exceptions, operator overloading...It has more to do with
the dynamic that I described above. C++ cannot be compared to other
languages like one would compare one pair of shoes to another.
Knowledge of C++, versus knowledge of another language, real
knowledge, not just syntax & semantics, implies something more
fundamental - that s/he who speaks the language is competent in the
world of software engineering.
As long as managers of projects need competence, those who are
competent will be needed, and the competent generally choose the tool
that allows them to be most effective in the system space, and right
now, that tool is C++.
In the meantime, we have to wait for the notion of Comptence-Not-
Required to expire naturally, just as we waited for the Responsibility-
Not-Required notion of the Hippie Movement of 1960's and 1970's
movement to expire. We have to wait until everyone realizes that Fred
Brooks was right -
There is no silver bullet. [http://en.wikipedia.org/wiki/
No_Silver_Bullet]
Note that the incompentent engineers that I speak of would refute
vigorously what Fred Brooks has to say about them: . They would also
destroy C++ altogether if they could, even if they were never required
to be associated with it, as their goal is not simply to write
software, but to create a world in which the gap between how they are
regarded, and how the comptent are regarded, is all but eliminated.
Microsoft is currently preying upon an acute understanding of this
mentality with its cadre of .NET technologies.
-Le Chaud Lapin-
Le Chaud Lapin
> > I understand that Systems side and Embedded are still the areas where C++ is
> > being used well. But is that all? What do the people who have invested time
> > and energy in C++ should do? Learn Java or C# because a significant majority
> > of other developers (apparently) could not free the pointers and found
> > garbage collector to be a great idea.
>
> On the desktop C++ has been losing ground mostly to web applications.
> And it is there that Java and C# have their playground. But when it
> comes to desktop applications C++ is still the standard choice. How
> many popular programs do you know are written in Java/C#? (I am not
> aware of many.)
I am proud to say that I have never written a line of Java or .NET
code, and now that I am finally the boss, I probably never will. ;)
But I have worked with people who write code in these languages, and
oddly, I help them from time to time without understanding exactly
what I am doing (Java/.NET syntax), by transferring concepts of C++.
The one problem that I have seen invariably is that the garbage
collector is not doing something at the moment they want it to happen,
and to force it to behave, they have to change their code but do not
know how to change it without breaking other things.
One day, while sitting in office of two Java gurus debating whether
the new component of a $500+ million product should be written in C++
or Java, I thought I would play the sycophant and promote Java, even
though I knew that there was a strong chance that the architecture
would be a disaster if written as such, as they would inevitably have
to bind to significant chunk of the code to C++ anyway. Also, the
entire system was time-critical. So I said, "Why don't we write it in
Java?"
They both laughed. I didn't get it.
They explained:
"Every Java programmer knows that you don't write this kind of
software in Java."
I can't remember if they were referring to a client or server, but
they were pretty sure of themselves. They mentioned something about
the resource consumption being so massive, no user would want to
download it to their computer.
In any case, I have never had to make such an embarrassing assertion
about _my_ favorite language. :)
-Le Chaud Lapin-
Felipe Magno de Almeida
> On Aug 5, 2:28 pm, Mathias Gaunard <loufo...@gmail.com> wrote:
>
> > On 4 aoūt, 23:57, "Abhishek" <nospam_abhishekpan...@yahoo.com> wrote:
[snip]
> > As far as I know, the game development community uses it a lot, albeit
> > not a very modern dialect (I clearly said from my experience it's
> > ugly, hacky and C-ish in another thread).
>
> Things changed quite a lot these days.
> Take a look at engines like Ogre, Irrlicht, cs, bullet, wildmagic...
> please.
I don't know the rest of the list, but I find Ogre to be exactly
what Mathias said: Ugly, Hacky and C-ish.
I even found a virtual member function for some bases which
returned std::type_info. They were overriden in the derived
class.
I couldn't help but laugh. Whoever wrote that didn't even
knew how typeid works.
[snip]
Oncaphillis
Abhishek wrote:
> I wanted to understand from the Gurus of C++ out here about their opinion
> on the future of C++. I have spent eight plus years in the software
> industry working in applications programming on C++/ Windows. My current
> company is now moving big time towards Java/ J2EE based technologies. Most
> of the other companies which are writing application software are also
> moving (or have alreadt moved) to J2EE or to .Net. So is there no future
> for C++ in application software? What do the people on this group feel
> about it?
That's the way it goes. The industry always goes toward the largest
marketplace. For some that means (a) following the "evil empire" and
stick with desktop applications. Since as far as I know they still
don't own/haven't invented the internet yet. (b) For others that means
changing the business model and head towards the
internet-(frenzy|bubble) 2.0 in which the applications is assumed to be
pushed through the net and feed you with some KFC adds while you type
the word "chicken" in your "on line wordprocessor" when writing your
thesis paper about "chicken diseases in industrial food production".
For case (a) you currently have to follow .NET and C#,VC#, VB# and
what have you. But they could as well have proclaimed that every code
has to be written in hex machine-code and developers would have to
follow as well.
For the latter case you need a well structured application-server
framework and right now it seems J2EE dominates the scene for
large applications.
I do JAVA since almost 10 years now. It is well structured and I really
love interfaces. (I know it is possible to do similar stuff in C++,
but it's not as easily done). I still remember the enthusiasm it
triggered within the community. The funny thing is that most of this
exaltation was due to the "Runs on every platform" promise which
enabled you to write web applications. It was the reinvention of the
P-Code (If anyone remembers this).Curiously this task has been taken
over by Javascript and DOM manipulation and it really happened without
a big bang. It was almost fully recognized when it was there already.
Now JAVA lives on the server side which is kind of a contradiction to
me since you really wouldn't need the "runs on every platform"
guarantee if you have full control over the platform.
Actually the same holds true for .NET It was thrown into the ring by MS
with the idea of
"Hey we have our own byte-code format but we do not have the performance
penalty since our byte-code is finally compiled towards for the target
platform"
But there is only one fully supported platform for the .NET framework
AFAIK it's based on MFC. But calling it '.o' libraries that have to be
translated before binding wouldn't have sound so sexy.
AFAICT Java isn't so popular due to its language features but due to
the rich associated set of good interacting libraries. There wasn't
any problem I had to solve for which I couldn't find the building
blocks within the java.* or javax.* namespace AWK, Swing, JDBC, XML
you name it. And that is something where C++ really lags behind. May
be boost comes to the rescue but that isn't clear for now.
But when I look into my private little crystal ball I see J2EE on the
decline. (Don't bash me). When evangelists almost automatically
reiterate the mantra that it's "the only framework in which you can
build and maintain an industry size web application" and they get this
glare in their eyes it becomes suspicious for me. In the mean while
real-world programmers are drowning in a sea of JAVA-Code-snips and
XML definitions which have to be kept in sync in order to keep the
application rolling. This is boring and error-prone.
People (at least creative once) tend to avoid boring
things. Unfortunately that doesn't always hold true for error-prone
things. That's the reason why there are always some kind of
circumvention strategies at work. The first C-Language for example was
merely a platform independent Macro-Assembler. All of the discipline
in using the language had to stick in your head not in the
language. Then there came the software crises and clever people came up
with more structured and type save languages. Up to the extend that
developers started to discuss what the language "allows" them instead
of discussing the best and most performand approach to a real-world
problem.
And then out of a sudden someone shows up on the scene and says:
"Hey I have this wonderfull language called Perl. It doesn't have any
real type beside string and you may write your good'o spaghetti
code without ever declaring a function. May be we make it OO later but
it has regex build in already"
I guess it was never meant to replace C/C++ but a lot of developers
adopted the language because it allowed them to be "quick and dirty"
again. They loved the "dirty" part and their employers loved the
"quick" part, until the whole system blows up.
Now it almost seems like we're seeing a similar J2EE->Ruby/RAILS
transition. Ruby is a good candidate for being the Perl of the
21century. Ok -- it's OO right from the beginning but via mixins and
heavy runtime reflection you may mutate your objects towards anything
and the properties of your objects may be spread all over your project
which AFAICT may become a maintainers nightmare. But it allows the
developer to be "quick and dirty" again and the fast track to the
market right now seems to be most importand once again. And the
database binding via ActiveRecords and AJAX encapsulation is a good
argument for RAILS in this respect.
So how does C++ fit into the picture ? I really don't know, but my
personal assumption is that we will see a renaissance of languages
which produce effective native code for their target platform.
I know there are JAVA compilers but they still seem to have
performance problems which are intrinsic within the language
(but I'm not an expert on that). The only thing I know is that
some code of mine when handling a large number of objects where almost
frozen for minutes when the GC entered the scene. But that might have
changed.
Up until now it seemed valid to throw more and faster hardware at a
problem. But that doesn't have to stay that way. When the service
providers analyze their big server farms they might find out that they
waste a lot of energy (aka money) by letting their CPUs chew on
JVM or interpreted code and ruby right now is a real bad
example for that. This transition may occur by providing more and more
compiled code within the framework already there, or it may be written in
C,C++,D or X.
> I understand that Systems side and Embedded are still the areas where C++
> is being used well. But is that all? What do the people who have invested
> time and energy in C++ should do? Learn Java or C# because a significant
> majority of other developers (apparently) could not free the pointers and
> found garbage collector to be a great idea.
The transition from C++ to JAVA for me was quite simple but I guess it's
not that easy the other way around. My knowledge about C# is too limited
to comment on that, but my impression is that in most of the cases it's much
more complicated to learn a new framework and not the language you use to
interface with it.
So -- from my point of view the language in which you express your
algorithms isn't actually so importand -- the next buzz word language
is just around the corner. It's more about your own discipline
to structure and decompose problems to be solved.
O.
Jiang
<felipe.m.alme...@gmail.com> wrote:
> On Aug 5, 2:28 pm, Jiang <goo.mai...@yahoo.com> wrote:
>
> > On Aug 5, 2:28 pm, Mathias Gaunard <loufo...@gmail.com> wrote:
[...]
> > > As far as I know, the game development community uses it a lot, albeit
> > > not a very modern dialect (I clearly said from my experience it's
> > > ugly, hacky and C-ish in another thread).
>
> > Things changed quite a lot these days.
> > Take a look at engines like Ogre, Irrlicht, cs, bullet, wildmagic...
> > please.
>
> I don't know the rest of the list, but I find Ogre to be exactly
> what Mathias said: Ugly, Hacky and C-ish.
May I ask why?
> I even found a virtual member function for some bases which
> returned std::type_info. They were overriden in the derived
> class.
IIRC, std::type_info is used only in OgreAny (AnyCast).
And I do not see how this example support your above
statement.
> I couldn't help but laugh. Whoever wrote that didn't even
> knew how typeid works.
>
After laughing at others, please check Boost.Any or any
other any_cast variants to make sure you understand
how typeid works.
What I see is, well, they know C++ better than you. :-)
Greg Comeau
<Joshua...@gmail.com> wrote:
>... whereas some of these systems have
>outdated C++ compilers. Each of the C++ compilers has their own little
>quirks, especially with newer features, like templates and exceptions.
>I appreciate open source software, but sometimes I wish a "benevolent"
>company like Sun owned the copyrights to C++, and they ran it like
>they do Java. If you advertise yourself as Java X, and you're not Java
>X, they'll sue you, like they did to Microsoft. It enforces everyone
>to actually follow the standard. As of this writing, I don't know any
>compiler which actually follows the entire standard. Comeau is close,
>but I think they still have one or two minor problems. (There was a
>thread here a little while ago about some template problem which
>Comeau and Visual Studios had.)
I know you have a point here, but the above does not really reach
any serious conclusion IMO. To wit, yes, Comeau does have "one or
two minor problems" :) But so does Java X, certainly many previous
versions did over the years when I looked. Simply put, 100.00%
compliance to a standard is mythology, even to Sun's specs.
Heck, even the standards themselves have bugs. That said,
C++-wise, products such as Comeau C++ and Dinkumware's libraries
really "are there" with support of C++98, C++03 and even of many
C++0x features (although I agree ink is still wet) as well as C89, C99,
etc. and on multiple platforms. I suspect that your point is that there
is still too much diversity, still too much catch-up, still too many
legacy compilers, etc. That may be true, but a very different point
than the above came across (to me at least).
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
kalman
wrote:
> free the pointers
Right, do you see where the point is? You wrote: "I have spent eight
plus
years in the software industry working in applications programming on C
++",
and still after 8 years you still talk about: "free pointers". In C++
you
"delete" pointers and usually you do not use plain pointers, RAII is
your
friend.
Regards
Gaetano Mendola
Razvan Cojocaru
> the future of C++. I have spent eight plus years in the software industry
> working in applications programming on C++/ Windows. My current company is
> now moving big time towards Java/ J2EE based technologies. Most of the other
> companies which are writing application software are also moving (or have
> alreadt moved) to J2EE or to .Net. So is there no future for C++ in
> application software? What do the people on this group feel about it?
The list of legacy software that has already been implemented with C++
is almost endless. I've heard Bjarne Stroustrup speak at the PACT 2007
conference in Brasov, Romania, about the many places where C++ is being
the first choice. He also lists many big-name solutions implemented with
C++ on his website, and he makes an interesting argument about where,
and how much, C++ is being currently used. There are even more of BS'
thoughts in a relatively recent article covered on Slashdot, where you
might also be interested in the user comments, as some of them do
express their opinions on the direction and present status of C++:
http://developers.slashdot.org/article.pl?sid=08/06/25/139219
Personally, I'm convinced that the future of C++ as a "living language"
is secure, regardless of whatever local trend you might be seeing around
at the moment.
> I understand that Systems side and Embedded are still the areas where C++ is
> being used well. But is that all? What do the people who have invested time
> and energy in C++ should do? Learn Java or C# because a significant majority
> of other developers (apparently) could not free the pointers and found
> garbage collector to be a great idea.
I don't feel that the garbage collector is the main reason why some
prefer Java or C# to C++. I've been "in the trenches" designing and
implementing non-trivial, large-scale UNIX C++ software for over 6
years, and I can testify that sometimes less is more. Languages such as
C# or Java simply make it harder for a programmer to make mistakes,
because they are easier to learn.
For example, with C++ you need to remember to have a virtual destructor
for every class that you intend to ever use as a base class, so that
nasty things won't happen if you ever delete a derived class object
through a pointer to base class. Apparently enough consensus has not
been achieved in the standardization committee for introducing the
following common-sense rule of thumb to C++0x: if a class has at least
one virtual member function, have the compiler magically make the
destructor virtual.
And you need to always remember to explicitly specify how copy
constructors and assignment operators should behave for classes that
handle their own allocated resources.
And then there are templates. Templates are a totally different style of
designing software. And you can achieve relatively similar things with
templates and object-oriented designs (see template policy classes vs.
the Template design pattern with plain-old overriden virtual class
member functions).
So C++ could mean a number of things. It's a multiparadigm language.
When you end up maintaining C++ software, you might have template code,
object-oriented class hierarchies, or simple C-style procedural
programming. Or, the latest and greatest, template metaprogramming,
wherein you are actually piggybacking the C++ syntax to write Lisp.
It takes longer to master C++. It's still too easy to make mistakes with
C++. You need to know much more about computer science in general to be
able to master C++ than you'd normally do with C# or Java (for example,
how to think of a member function call as a regular C call with an extra
"this" pointer parameter, primitive data sizes that are platform
dependent, etc.).
The upside? There's more power to C++ software. And C++ is an ISO
standard, unlike C# and Java. You can look around and see what Microsoft
is doing to Visual Basic - it's basically gone. Learning VB# is almost
learning C#, and it's about the same effort, so you'd go straight to C#.
My point? Learning C++ is safer in the long term because no company owns
it. You can't be sure for how long the C# or Java compilers will be
maintaned, and on what future platforms they will run, but the sheer
number of great C++ compilers should give you a taste of the forseeable
future.
In the end, I'd like to point out that IMHO there is no such thing as
"The One True Language (TM)". Perhaps the reason you're seeing some
shops going from C++ to another language is simply that the other
programming language suits their projects better. I wouldn't want to use
C++ for things that I usually use Perl or Python for.
--
Razvan Cojocaru
KeyID: 1024D/04CA34DE
Felipe Magno de Almeida
> On Aug 6, 11:25 pm, Felipe Magno de Almeida
>
[snip]
> > I even found a virtual member function for some bases which
> > returned std::type_info. They were overriden in the derived
> > class.
>
> IIRC, std::type_info is used only in OgreAny (AnyCast).
> And I do not see how this example support your above
> statement.
It is been like two years ago. The code was something like this:
struct base
{
virtual std::type_info& get_type() const = 0;
};
struct derived1
{
std::type_info& get_type() const { return typeid(*this); }
};
struct derived2
{
std::type_info& get_type() const { return typeid(*this); }
};
> > I couldn't help but laugh. Whoever wrote that didn't even
> > knew how typeid works.
>
> After laughing at others, please check Boost.Any or any
> other any_cast variants to make sure you understand
> how typeid works.
I know very well how boost.any works and I don't know
what it has to do with what I wrote.
> What I see is, well, they know C++ better than you. :-)
That's probably the case for some of them.
> Jiang
>
> --
--
Felipe Magno de Almeida
Eugene Gershnik
>
> For example, with C++ you need to remember to have a virtual destructor
> for every class that you intend to ever use as a base class, so that
> nasty things won't happen if you ever delete a derived class object
> through a pointer to base class. Apparently enough consensus has not
> been achieved in the standardization committee for introducing the
> following common-sense rule of thumb to C++0x: if a class has at least
> one virtual member function, have the compiler magically make the
> destructor virtual.
Nonsense. First of all there is nothing wrong with having a non-
virtual *protected* destructor in a base class. Second introducing
such change will immediately break every Windows COM component ever
written.
--
Eugene
--
marlow...@googlemail.com
> I am proud to say that I have never written a line of Java or .NET
> code, and now that I am finally the boss, I probably never will. ;)
I am proud to say that I use both C++ and java and I like them both.
> The one problem that I have seen invariably is that the garbage
> collector is not doing something at the moment they want it to happen,
IMO one of the strengths of C++ is RAII where the resource is not
necessarily memory.
> One day, while sitting in office of two Java gurus debating whether
> the new component of a $500+ million product should be written in C++
> or Java, I thought I would play the sycophant and promote Java
[snip]
> They both laughed. I didn't get it.
> They explained:
> "Every Java programmer knows that you don't write this kind of
> software in Java."
I work in the City (London) where financial programming is done in C++
and java. The bits that have to be very fast tend to be done in C++.
Sometimes these require 3rd party libraries that are only available in
C++ (sometimes you see these libs wrapped using JNI but not very
often). The high powered maths used by quants tend to be done in C++,
e.g solving PDEs.
Stuff that uses a RDBMS tends to use java these days, from what I've
seen.
Also, the GUIs tend to be in java, either directly or via JSPs. An
example of a popular GUI app written in java is argoUML, a free
software project for drawing various kinds of UML diagram.
RDBMSs and GUI are areas where C++ had no portable solution. There are
lots of open source projects that address this now but none have
emerged as std (not even wxWidgets). Maybe this is one of the reasons
why people that program in these areas go straight to java.
Regards,
Andrew Marlow
Razvan Cojocaru
>> for every class that you intend to ever use as a base class, so that
>> nasty things won't happen if you ever delete a derived class object
>> through a pointer to base class. Apparently enough consensus has not
>> been achieved in the standardization committee for introducing the
>> following common-sense rule of thumb to C++0x: if a class has at least
>> one virtual member function, have the compiler magically make the
>> destructor virtual.
>
> Nonsense. First of all there is nothing wrong with having a non-
> virtual *protected* destructor in a base class. Second introducing
> such change will immediately break every Windows COM component ever
> written.
Is it? How does a protected base class destructor solve the following
problem?
class Base {
public:
virtual perform() = 0;
protected:
~Base() {} // non-virtual destructor
};
class Derived : public Base {
public:
Derived() { rh_ = allocate_resource(); }
~Derived() { deallocate_resource(rh_); }
virtual perform() { /* implement me */ }
private:
// we're handling resources, careful with asignment
Derived(const Derived&);
Derived& operator=(const Derived&);
private:
resource_handle_t rh_;
};
int main()
{
std::auto_ptr<Base> pb(new Derived);
pb->perform();
// other code here...
}
When pb goes out of scope, it will only call Base::~Base(), thus failing
to deallocate the resource allocate by Derived's constructor. Had
Base::~Base() been virtual, this problem would have been solved, as it
would have caused Derived::~Derived() to be virtual in turn, and the
proper destructor would have been selected via the vtable pointers.
So really, I don't see how an access specifier added to Base's
destructor would make any difference (unless perhaps the specifier is
"private", in which case the problem gets unnecessarily complicated and
somewhat academic).
As for messing all COM+ legacy code up, I'm not a COM+ expert but I
don't see why that would be the case.
--
Razvan Cojocaru
KeyID: 1024D/04CA34DE
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Bo Persson
No, it doesn't. Because the Base destructor is protected, auto_ptr is
unable to call it, and the compiler will tell you so.
As usual, "C++ is a multi paradigm language", and not everyone uses
delete through pointer to base class. The compiler might very well
warn you that a virtual destructor is needed, but it shouldn't just
add one by itself.
Bo Persson
--
Eugene Gershnik
>
[Restoring attribution]
> Eugene wrote:
> > Nonsense. First of all there is nothing wrong with having a non-
> > virtual *protected* destructor in a base class. Second introducing
> > such change will immediately break every Windows COM component ever
> > written.
>
> Is it? How does a protected base class destructor solve the following
> problem?
>
> class Base {
> public:
> virtual perform() = 0;
>
> protected:
> ~Base() {} // non-virtual destructor
>
> };
>
> class Derived : public Base {
[snip]
>
> };
>
> int main()
> {
> std::auto_ptr<Base> pb(new Derived);
[snip]
This shouldn't compile since std::auto_ptr<Base> cannot call Base dtor
(via delete operator).
Unlike Java, 'protected' in C++ only gives access to derived classes.
Theoretically, you *can* construct pathological code where Derived
tries to destroy an instance of *itself* via Base destructor. However,
I doubt you'll ever find such code in practice.
> As for messing all COM+ legacy code up, I'm not a COM+ expert but I
> don't see why that would be the case.
Because COM relies on virtual table layout to achieve binary
interoperability between code written by different people in different
languages. If you silently change vtable layout of existing code it
will fail to talk to code built with an earlier compiler.
--
Eugene
--
Pete Becker
>
> Is it? How does a protected base class destructor solve the following
> problem?
>
> class Base {
> public:
> virtual perform() = 0;
>
> protected:
> ~Base() {} // non-virtual destructor
> };
>
> class Derived : public Base {
> public:
> Derived() { rh_ = allocate_resource(); }
> ~Derived() { deallocate_resource(rh_); }
>
> virtual perform() { /* implement me */ }
>
> private:
> // we're handling resources, careful with asignment
> Derived(const Derived&);
> Derived& operator=(const Derived&);
>
> private:
> resource_handle_t rh_;
> };
>
> int main()
> {
> std::auto_ptr<Base> pb(new Derived);
Error here: can't access Base::~Base().
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)
Andre Kaufmann
> On Aug 6, 12:58 pm, Razvan Cojocaru <razva...@gmx.net> wrote:
>> For example, with C++ you need to remember to have a virtual destructor
>> for every class that you intend to ever use as a base class, so that
>> nasty things won't happen if you ever delete a derived class object
>> through a pointer to base class. Apparently enough consensus has not
>> been achieved in the standardization committee for introducing the
>> following common-sense rule of thumb to C++0x: if a class has at least
>> one virtual member function, have the compiler magically make the
>> destructor virtual.
>
> Nonsense. First of all there is nothing wrong with having a non-
> virtual *protected* destructor in a base class. Second introducing
But what it's good for (not to make it virtual) - besides having perhaps
a smaller vtable ?
IMHO the problem in C++ is that the rare case is commonly default.
E.g. if a class contains a virtual function, the compiler should throw a
diagnostic message if the destructor isn't virtual. If the (rare case)
destructor mustn't be virtual for what reason ever, then it has to be
marked to be explicitly non-virtual (which I can't currently in C++).
On the other side in some cases I have no simple way to tell my
intention to the compiler:
E.g
class Base
{
public:
virtual void Foo(unsigned int z) { printf("Foo:Base\r\n"); }
typedef Base BaseType;
};
template<typename T>
class NewFunction : public T
{
virtual void Foo(int z) /* C++ doesn't support override */
{
printf("Foo:NewFunction\r\n");
}
};
int main()
{
typedef NewFunction<Base> ObjectType;
ObjectType::BaseType* base = new ObjectType();
base->Foo(1); // My intention was that Foo(int z) should
// override the base class virtual function
}
> [...]
Eugene Gershnik
> Eugene Gershnik wrote:
>
> > Nonsense. First of all there is nothing wrong with having a non-
> > virtual *protected* destructor in a base class. Second introducing
>
> But what it's good for (not to make it virtual) - besides having perhaps
> a smaller vtable ?
You might want to have an interface that is destroyed through some
means different from 'delete'. A classical example is intrusive
reference counting:
class Base
{
public:
virtual void add_ref() const = 0;
virtual void sub_ref() const = 0;
protected:
Base() {}
~Base() {}
};
class Derived
{
public:
static Base * get_instance()
{ return new Derived(); }
void add_ref() const
{ ++m_ref_count; }
void sub_ref() const
{ if (--m_ref_count == 0) delete this; }
private:
Derived() : m_ref_count(1)
{}
Derived(const Derived &);
void operator=(const Derived &);
private:
mutable int m_ref_count;
};
The idea is to make sure that Derived lifetime is only manipulated via
add_ref/sub_ref and nobody accidentally delete-s it.
--
Eugene
Razvan Cojocaru
>> public:
>> virtual perform() = 0;
>>
>> protected:
>> ~Base() {} // non-virtual destructor
>>
>> };
>>
>> class Derived : public Base {
>
> [snip]
>
>> };
>>
>> int main()
>> {
>> std::auto_ptr<Base> pb(new Derived);
>
> [snip]
>
> This shouldn't compile since std::auto_ptr<Base> cannot call Base dtor
> (via delete operator).
> Unlike Java, 'protected' in C++ only gives access to derived classes.
> Theoretically, you *can* construct pathological code where Derived
> tries to destroy an instance of *itself* via Base destructor. However,
> I doubt you'll ever find such code in practice.
Indeed, I stand corrected. I should have taken the time to try to
compile the code to test my assumption, at least with the excellent free
online Comeau compiler. Mea culpa.
BUT, since we're talking code you'd be likely to see in the real world,
neither will you see abstract base classes with protected destructors.
They are _meant_ to be used for using derived class objects through
pointers (or references) to base class types - such as Object, in Java.
So it wouldn't work to simply make the destructor protected, as that
would break the whole basic object-oriented design.
Furthermore, you might be interested in reading these slides written by
Bjarne Stroustrup in the early stages of debate over C++0x:
http://www.research.att.com/~bs/C++0x_panel.pdf
I quote: "Remove embarrassments – Frequent questions, frequent novice
errors: [...] Give a class with virtual functions a virtual destructor
by default". You'll find that comment on the last page, page 8 of the slide.
There's also this nice passage in "Thinking in C++", Vol. 2, by Bruce
Eckel, where _exactly_ your protected destructor example is being discussed:
Again, quote: "It is evident that this is not a standalone class because
its constructor is protected; it requires a friend or a derived class to
use it. It is important that the destructor is virtual, because it is
called only from the delete this statement in detach( ), and we want
derived objects to be properly destroyed.[122]"
So there we have a "delete this;" issue, that I believe
_you_will_encounter_in_real_life_ often enough. Clicking on note [122]
will further carry us to this: "[122] Even more importantly, we don't
want undefined behavior. It is an error for a base class not to have a
virtual destructor."
So if I'm wrong, and having virtual destructors for all of your base
classes is "nonsense", at least I'm in good company ;-).
> Because COM relies on virtual table layout to achieve binary
> interoperability between code written by different people in different
> languages. If you silently change vtable layout of existing code it
> will fail to talk to code built with an earlier compiler.
COM+ works with _interfaces_. Interfaces, being only specifications for
how data should behave, do not emply destructors one way or the other (I
believe COM+ objects do whatever cleanup they need to do upon calling
Release()). It's very fishy to ponder C++ destructors in the context of
a binary component framework such as COM+ or CORBA.
I'll admit that I don't know for sure how the change might affect legacy
COM+ code (though even finding that it does, there are usually compiler
switches that allow deprecated behaviour) - but it might be (and it is,
with some compilers) that the destructors are the last entry in the
vtable, and simply adding one entry at the end would not significantly
change anything in a vptr/vtable-based approach to "binary
interoperability" (since you'd work with the same offsets for all your
old functions).
--
Razvan Cojocaru
KeyID: 1024D/04CA34DE
gas...@hotmail.com
Your point is that c++ has many pitfalls and that you have to remember
a lot of this dirty details. Being a local guru at my company in the
past 10 years I had to solve a lot of these suprising issues. In fact
a day ago I posted one here. If I had the energy I could make a book
out of it. In fact other people already make a living out of this
(i.e. Sutter and Meyer). To name a few: difference between reference
init and assignment, static integral variables may also be initialised
in the header, A a() is interpreted as a function declaration,
overloaded function and conversion rules, space between > > in
template declarations, virtual functions can not be called in
constructors, required typename when using a type dependent on a
template argument, const members can only be initialised in the
initialiser list).
Working on a large application it would help that c++ would automate
90% of the non performance critical classes (mostly 'bunsiness like'
classes), by having a default virtual destructor, forbid implicit
conversion, block assignment and copyable as well, probaly default
initialisation of variables, and especially gc would also help
(although one can come quite far with shared_ptr's).
I have just read a book about c#, and I must admit that a lot of
things are easier in c# /.Net, just because the language has an easier
model. The basic rule of value and reference classes is small and
should be easy to understand (at least for a c++ programmer). Imo the
best improvements of c# compared to c++ are the gc and the properties,
but also other features are quite handy. One would almost think that
they are experienced c++ programmers, fixing a lot 'unhandy' c++
features.
Stroustrup btw. remarks about computer languages that they start
clean, but become infected when more features are added over time.
I am not sure if c++ would survive for main stream projects. There are
still people working with Fortran, Cobol and Algol.
I have invested 10 years in c++, so if the market is going to shift, I
could flush a large part of this knowledge (since it is library
knowledge, especially boost and STL, template tricks and known c++
problems). That would be pity for me.
--
Pete Becker
>
> BUT, since we're talking code you'd be likely to see in the real world,
> neither will you see abstract base classes with protected destructors.
> They are _meant_ to be used for using derived class objects through
> pointers (or references) to base class types - such as Object, in Java.
That is true in Java, but not in C++.
> So it wouldn't work to simply make the destructor protected, as that
> would break the whole basic object-oriented design.
Not at all. It breaks some particular notion of how to implement an
object oriented design, but there are many other ways of doing things.
>
> Furthermore, you might be interested in reading these slides written by
> Bjarne Stroustrup in the early stages of debate over C++0x:
>
> http://www.research.att.com/~bs/C++0x_panel.pdf
>
> I quote: "Remove embarrassments - Frequent questions, frequent novice
> errors: [...] Give a class with virtual functions a virtual destructor
> by default". You'll find that comment on the last page, page 8 of the
> slide.
>
> There's also this nice passage in "Thinking in C++", Vol. 2, by Bruce
> Eckel, where _exactly_ your protected destructor example is being
> discussed:
>
> http://www.linuxtopia.org/online_books/programming_books/c++_practical_programming/c++_practical_programming_221.html
Again,
>
> quote: "It is evident that this is not a standalone class because
> its constructor is protected; it requires a friend or a derived class to
> use it. It is important that the destructor is virtual, because it is
> called only from the delete this statement in detach( ), and we want
> derived objects to be properly destroyed.[122]"
Yup: he chose a particular way of using this class, and that particular
approach requires a virtual destructor.
>
> So there we have a "delete this;" issue, that I believe
> _you_will_encounter_in_real_life_ often enough. Clicking on note [122]
> will further carry us to this: "[122] Even more importantly, we don't
> want undefined behavior. It is an error for a base class not to have a
> virtual destructor."
>
> So if I'm wrong, and having virtual destructors for all of your base
> classes is "nonsense", at least I'm in good company ;-).
Hmm, I don't recall anyone saying that having virtual destructors for
all of your base classes is nonsense. Seems to me the discussion was
about whether every base class *must* have a virtual destructor. If you
wan't 'em, feel free. But don't insist that I have to follow your
design approach and apply the techniques that it necessitates. There
are more things in heaven and Earth, Horatio, than are dreamt of in
your philosophy.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Bo Persson
No, it does not. It only removes the possibility of deleting through a
pointer to base.
There are many cases where you might want to adhere to an interface,
without dynamically allocating the derived classes.
[ Some examples deleted]
> So if I'm wrong, and having virtual destructors for all of your base
> classes is "nonsense", at least I'm in good company ;-).
Having virtual destructors for some, or even many, base classes is s
good idea. Having it for everything, whether you need it or not, is a
less good idea.
>
>
>> Because COM relies on virtual table layout to achieve binary
>> interoperability between code written by different people in
>> different languages. If you silently change vtable layout of
>> existing code it will fail to talk to code built with an earlier
>> compiler.
>
> COM+ works with _interfaces_. Interfaces, being only specifications
> for how data should behave, do not emply destructors one way or the
> other (I believe COM+ objects do whatever cleanup they need to do
> upon calling Release()). It's very fishy to ponder C++ destructors
> in the context of a binary component framework such as COM+ or
> CORBA.
>
> I'll admit that I don't know for sure how the change might affect
> legacy COM+ code (though even finding that it does, there are
> usually compiler switches that allow deprecated behaviour) - but it
> might be (and it is, with some compilers) that the destructors are
> the last entry in the vtable, and simply adding one entry at the end
> would not
> significantly change anything in a vptr/vtable-based approach to
> "binary interoperability" (since you'd work with the same offsets
> for all your old functions).
Adding an entry at the end would affect derived classes. The number of
virtual functions in the interface is important.
Bo Persson
--
Alex
<felipe.m.alme...@gmail.com> wrote:
> It is been like two years ago. The code was something like this:
>
> struct base
> {
> virtual std::type_info& get_type() const = 0;
>
> };
>
> struct derived1
> {
> std::type_info& get_type() const { return typeid(*this); }
>
> };
>
> struct derived2
> {
> std::type_info& get_type() const { return typeid(*this); }
>
> };
You have probably meant
struct derived1 : public base { ... }
and possibly
const std::type_info& get_type() const { ... }
Given that, could you explain what exactly is the problem with the
example you have provided above? To me, it looks like a logical thing
to do when you want to discover the derived type and you only have
access to the base pointer or reference. It is usually faster than
dynamic_cast.
> I know very well how boost.any works and I don't know
> what it has to do with what I wrote.
Here's a snippet from boost::any:
class any
{
...
const std::type_info & type() const
{
return content ? content->type() : typeid(void);
}
...
template<typename ValueType>
class holder : public placeholder
{
...
virtual const std::type_info & type() const
{
return typeid(ValueType);
}
...
};
};
Since OgreAny is a carbon-copy of boost::any, it seems to have a lot
with what you wrote.
See
http://www.ogre3d.org/docs/api/html/OgreAny_8h-source.html
http://svn.boost.org/svn/boost/trunk/boost/any.hpp
Alex
Maciej Sobczak
> Because COM relies on virtual table layout
No problem - the standard does not define what is a "virtual table
layout", so it cannot introduce any conflicts there.
If this would be a problem for Microsoft, then it is only because they
have gone the cheapest way in the past and bound the specification of
COM binary interface with the implementation details of their
compiler. This is formally not a C++ problem.
Another way to look at it: it is possible to implement a COM component
in plain C, which means that virtual tables are not necessarily
involved there. In other words, you can piggy-back COM on existing
vtable mechanics (as Microsoft did in the past), but you don't have
to.
--
Maciej Sobczak * www.msobczak.com * www.inspirel.com
Andre Kaufmann
> On Aug 7, 8:58 am, Razvan Cojocaru <razva...@gmx.net> wrote:
>
> [Restoring attribution]
>> Eugene wrote:
>
> Because COM relies on virtual table layout to achieve binary
Commonly code written for the the VC compiler uses the proprietary
attribute for a classs - novtable, specifying that the object mustn't
have a vtable.
I think you mean changing the abstract COM interfaces, would break the
compatibility - that is true - but the destructor commonly isn't part of
the abstract COM interfaces.
> [...]
Andre
RyanMcCoskrie
> being used well. But is that all? What do the people who have invested time
> and energy in C++ should do? Learn Java or C# because a significant majority
> of other developers (apparently) could not free the pointers and found
> garbage collector to be a great idea.
On Linux/BSD (and trying to break into Windows as well) the K Desktop
Environment (*NIX style
OS's the interfaces are interchangeable) is pretty big and that's
entirely C++ (though troltech's
QT library adds several new features using "enchanted" macros and
specialized pre-processor).
If you want to keep up with C++ jump systems.
Andre Kaufmann
> On Aug 7, 12:11 pm, Andre Kaufmann <akfmn...@t-online.de> wrote:
>> Eugene Gershnik wrote:
>>
>>> Nonsense. First of all there is nothing wrong with having a non-
>>> virtual *protected* destructor in a base class. Second introducing
>> But what it's good for (not to make it virtual) - besides having perhaps
>> a smaller vtable ?
>
> You might want to have an interface that is destroyed through some
> means different from 'delete'. A classical example is intrusive
> reference counting:
> The idea is to make sure that Derived lifetime is only manipulated via
> add_ref/sub_ref and nobody accidentally delete-s it.
That's because the destructor is protected. But what is the advantage of
the protected non virtual destructor compared to a protected virtual
one ? I see only a slightly smaller vtable in the base class ?
Andre
Eugene Gershnik
>
> BUT, since we're talking code you'd be likely to see in the real world,
> neither will you see abstract base classes with protected destructors.
See my reply to Andre Kaufmann.
> They are _meant_ to be used for using derived class objects through
> pointers (or references) to base class types - such as Object, in Java.
> So it wouldn't work to simply make the destructor protected, as that
> would break the whole basic object-oriented design.
Sorry but this again makes no sense whatsoever. Whether destructor is
public or protected is completely orthogonal to the concept of
interface or ABC.
The access control of the destructor answers one simple design
question: how objects of this type are supposed to be destroyed. If
the dtor is public you are supposed to use
delete pObject;
if it is protected then you do somethings else such as rely on
intrusive reference counting, some external collector etc.
> Furthermore, you might be interested in reading these slides written by
> Bjarne Stroustrup in the early stages of debate over C++0x:
>
> http://www.research.att.com/~bs/C++0x_panel.pdf
This argument is nothing but an "appeal to authority". The slides
provide no context or discussion about the issue.
> There's also this nice passage in "Thinking in C++", Vol. 2, by Bruce
> Eckel, where _exactly_ your protected destructor example is being discussed:
Check the discussion carefully. It has nothing to do with "my"
protected destructor.
> COM+ works with _interfaces_. Interfaces, being only specifications for
> how data should behave, do not emply destructors [....]
I can only suggest that you research how COM (without +) works, how OO
interfaces are idiomatically implemented in C++ and how compilers lay
out virtual function tables for class hierarchies.
--
Eugene
--
Razvan Cojocaru
> without dynamically allocating the derived classes.
Perhaps, but it's very dangerous to assume that that will always be the
case, and the next source code maintainer or library users will feel the
same way and not use the heap. It's wiser to impose behaviour
constraints upfront by design, than to write 100 pages coding style
documents telling your programmers not to use the heap.
>> So if I'm wrong, and having virtual destructors for all of your base
>> classes is "nonsense", at least I'm in good company ;-).
>
> Having virtual destructors for some, or even many, base classes is s
> good idea. Having it for everything, whether you need it or not, is a
> less good idea.
I meant virtual destructors for all base classes with at least one
virtual member function. Although it is arguably not a bad idea to add
virtual destructors to all base classes anyway (the function call
indirection would not make the call noticeably slower, and the vtable is
not a huge chunk of data, and other than that I don't really see what
the problem might be), it is not what I meant. I admit I've phrased it
somewhat confusing.
> Adding an entry at the end would affect derived classes. The number of
> virtual functions in the interface is important.
As Maciej Sobczak observed in a previous reply, the standard is silent
about the virtual table layout. All talk about it is bound to be
speculative, and IMHO largely irrelevant, so I'd rather not try to solve
an imaginary problem.
--
Razvan Cojocaru
KeyID: 1024D/04CA34DE
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Razvan Cojocaru
>> neither will you see abstract base classes with protected destructors.
>> They are _meant_ to be used for using derived class objects through
>> pointers (or references) to base class types - such as Object, in Java.
>
> That is true in Java, but not in C++.
It will also be true in C++ if you intend to use the most important
aspect of object-oriented programmin, which is polymorphism (try to
count how many design patterns in the Gang of Four's book make sense
without polymorphism). You might not call your most abstract class
"Object", or you might have several such top base classes, but the
principle remains the same.
> Not at all. It breaks some particular notion of how to implement an
> object oriented design, but there are many other ways of doing things.
Indeed there are, however merely being able to do something does not
imply the wisdom of doing so. I would further argue that since the
central notion of pure object-oriented programming is the class
hierarchy (subtyping), and you cannot in good faith assume that your
classes' users will refrain from using the heap, you have to follow the
principle of least surprise.
> Hmm, I don't recall anyone saying that having virtual destructors for
> all of your base classes is nonsense. Seems to me the discussion was
> about whether every base class *must* have a virtual destructor. If you
> wan't 'em, feel free. But don't insist that I have to follow your
> design approach and apply the techniques that it necessitates. There
> are more things in heaven and Earth, Horatio, than are dreamt of in
> your philosophy.
Every base class that _has_at_least_one_virtual_member_function_ should
have a virtual destructor. Because obviously there's some polymorphism
going on there. Putting in a virtual member function and then making the
destructor protected is a very suspect way of dodging the issue.
_All_ base classes _with_at_least_one_virtual_member_function_ should
have a virtual destructor. You never know. Might be that a source code
maintainer will use the heap like that. Might be that you're writing a
library and some libary user will want to use a container of base class
pointers to derived classes objects. That sort of thing happens all the
time in GUI libraries (the Composite pattern).
I've done my best to show with examples why I believe that's a very
strong candidate for a "default" rule of thumb in any software shop's
coding style / coding policy manual.
I leave it to you to show me some examples where having a virtual
destructor for your base class with at least one virtual member function
would make your code worse in some way. Please exclude the "legacy code
that's been written like that" argument - that code can be recompiled,
or we can compile our applications in "deprecated mode". You keep saying
there are sometimes better ways but have yet to enlighten us with such
an example.
--
Razvan Cojocaru
KeyID: 1024D/04CA34DE
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Bart van Ingen Schenau
> On Aug 7, 7:01 am, Felipe Magno de Almeida
> <felipe.m.alme...@gmail.com> wrote:
>
>> It is been like two years ago. The code was something like this:
>>
>> struct base
>> {
>> virtual std::type_info& get_type() const = 0;
>>
>> };
>>
>> struct derived1
>> {
>> std::type_info& get_type() const { return typeid(*this); }
>>
>> };
>>
>> struct derived2
>> {
>> std::type_info& get_type() const { return typeid(*this); }
>>
>> };
>
> You have probably meant
>
> struct derived1 : public base { ... }
>
> and possibly
>
> const std::type_info& get_type() const { ... }
>
> Given that, could you explain what exactly is the problem with the
> example you have provided above? To me, it looks like a logical thing
> to do when you want to discover the derived type and you only have
> access to the base pointer or reference. It is usually faster than
> dynamic_cast.
Why all the complication, when you can simply do
typeid(*pb); /* where pb is a pointer to the base class */
The standard guarantees that this yields the type_info for the most
derived class, if the base class is polymorphic.
>
>> I know very well how boost.any works and I don't know
>> what it has to do with what I wrote.
>
> Here's a snippet from boost::any:
>
> class any
> {
> ...
> const std::type_info & type() const
> {
> return content ? content->type() : typeid(void);
> }
> ...
> template<typename ValueType>
> class holder : public placeholder
> {
> ...
> virtual const std::type_info & type() const
> {
> return typeid(ValueType);
> }
> ...
> };
> };
>
> Since OgreAny is a carbon-copy of boost::any, it seems to have a lot
> with what you wrote.
There is a subtle, but important difference in the two examples.
In the example given by Felipe, the derived class returns the type_info
of *itself*. This is completely useless, as the client code can obtain
the exact same information without a virtual function call.
In the boost::any code, the holder class returns the type_info for *the
class it contains* and is instantiated upon. This information is not
obtainable in any other way.
>
> See
>
> http://www.ogre3d.org/docs/api/html/OgreAny_8h-source.html
> http://svn.boost.org/svn/boost/trunk/boost/any.hpp
>
> Alex
>
Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://c-faq.com/
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/
Alex
> I have just read a book about c#, and I must admit that a lot of
> things are easier in c# /.Net, just because the language has an easier
> model.
The main problem with C# it is its proprietary nature. With C++, any
interested party has roughly the same amount of influence on the
development of the language. Not so with C# (or Java, for that
matter). C# shall progress as MS sees fit, this will at some point no
doubt involve breaking code and discontinuing support for it (think
VB6.0/VB.Net). Although C++'s keeping backward compatibility affects
the language in negative ways, breaking large code bases is much worse
than that.
> I am not sure if c++ would survive for main stream projects. There are
> still people working with Fortran, Cobol and Algol.
Depends what you mean by "main stream". Embedded is a large, fast
growing market segment and C++ has everything needed to be very
successful there. Additionally, online trading, telephony, industrial
automation, games, HPC are all perfect and strong market segments for C
++.
What's hurting C++ are several things:
- C people say its bloated
- Java/C# people say it leaks memory
- dynamic languages people say it is rigid
- functional language people say it has side effects
- it has the steepest learning curve
Some of the above are obviously myths and misconceptions. Or better to
say, anecdotal - it is, of course, possible to write bloated and
memory leaking C++ code. Some are facts - C++ does have side effects
and is more rigid (both for a reason, though) than dynamic languages.
And it is probably the hardest mainstream language to master. It's
good to see that the new standard will address some issues and that
Bjarne Stroustrup is writing a book for beginners.
> I have invested 10 years in c++, so if the market is going to shift, I
> could flush a large part of this knowledge (since it is library
> knowledge, especially boost and STL, template tricks and known c++
> problems). That would be pity for me.
I personally don't think there will be major shift any time soon. As I
mentioned in a previous post, Java was supposed to "kill" C++ a decade
ago. Don't hold your breath to see that happening, though ;-). I think
your investment is safe.
Alex
Le Chaud Lapin
> BUT, since we're talking code you'd be likely to see in the real world,
> neither will you see abstract base classes with protected destructors.
> They are _meant_ to be used for using derived class objects through
> pointers (or references) to base class types - such as Object, in Java.
> So it wouldn't work to simply make the destructor protected, as that
> would break the whole basic object-oriented design.
[snip]
> So if I'm wrong, and having virtual destructors for all of your base
> classes is "nonsense", at least I'm in good company ;-).
Base classes or abstract base classes?
There might be a rare situation where base class must not incur the
overhead of a pointer for the vtable such that...
struct Base {type1 field1; type2 field2; ...; protected : ~Base();} ;
sizeof(Base) == (sizeof(type1) + sizeof(type2) + ...)
struct Derived : Base {};
Base might represent overlay struct in memory-mapped I/O region, a set
of control registers perhaps, where placement new() is used to place
the struct, destruction involves freeing of some resource, global
delete must not be allowed, but Derived is a larger, similar struct
that inherits from Base that needs to invoke non-virtual destructor of
Base from within ~Derived().
-Le Chaud Lapin-
--
Razvan Cojocaru
>> neither will you see abstract base classes with protected destructors.
>
> See my reply to Andre Kaufmann.
I've seen it. I've also seen Andre Kaufmann's reply, to which I have
nothing else to add: your example does not prove that even in that case
there is any advantage to not having a virtual destructor. You don't
even have the excuse of wanting to not generate a vtable, since you
already have two virtual member functions, so all you're saving is a
simple pointer to an additional member function - the destructor.
> Sorry but this again makes no sense whatsoever. Whether destructor is
> public or protected is completely orthogonal to the concept of
> interface or ABC.
> The access control of the destructor answers one simple design
> question: how objects of this type are supposed to be destroyed. If
> the dtor is public you are supposed to use
>
> delete pObject;
Well, the "concept of interface" doesn't have anything to do with
destructors either. BUT, the concept of C++ interfaces (or abstract base
classes) does have something to do with destructors, and it is this:
A. if you wish to employ polymorphism with C++, you will have a top
class in you class hierarchy, with an interface that derived classes
will implement.
B. you will usually handle derived objects through base class pointers
or references, which is the whole point.
C. it's very probable that, at least at some point in time, someone will
put one of these derived class objects on the heap, and use it through a
base class pointer. Hence, we need to worry about the destructors, and
the only and best way for a destructor to be in this case, is virtual.
Also, please note that I hadn't added the "protected vs. public
destructor" to the discussion: that is your contribution. I've just
tried to show that having the destructor protected
_in_order_to_hack_around_the_issue_ of calling the wrong destructor when
it's not virtual is just that: a hack.
And since having the destructor protected also stops you from being able
to use derived class objects through base class pointers (as I have
learned the hard way thanks to this thread :-) ), it effectively
prevents you from completely using textbook polymorphism with C++.
>> http://www.research.att.com/~bs/C++0x_panel.pdf
>
> This argument is nothing but an "appeal to authority". The slides
> provide no context or discussion about the issue.
Alas, it was simply an appeal to reason. I had hoped that you would at
least take a well respected expert's opinion on the issue less lightly
than you would have, deservedly, taken my humble one. As I've said, and
this is obviously a truism, if Bjarne Stroustrup is wrong then I am
wrong as well, which is definitely a posibility. I try to leave room for
error in my life so that my friends will buy me cake when I get it right
:-).
>> There's also this nice passage in "Thinking in C++", Vol. 2, by Bruce
>> Eckel, where _exactly_ your protected destructor example is being
discussed:
>
> Check the discussion carefully. It has nothing to do with "my"
> protected destructor.
Not "your protected destructor", "your protected destructor example", as
the above quote testifies.
If you'll inspect the class Countable source code, you'll find that the
destructor is private, albeit virtual. Note [122] which I had quoted
explains why it has been made virtual. It is basically a class with a
protected destructor that still needed to be virtual - hence yet another
example that it does not suffice to make your regular destructor
protected and go around the issue. Perhaps it's also noteworthy that the
example deals with reference-counting, a domain that you seem to have
singled out for protected non-virtual destructors only.
> I can only suggest that you research how COM (without +) works, how OO
> interfaces are idiomatically implemented in C++ and how compilers lay
> out virtual function tables for class hierarchies.
Like I've said in an earlier reply to Pete Becker, which, as I'm typing
this, has not yet gone through the newsgroup moderation queue, I'd
rather not speculate about issues unspecified in the C++ ISO standard,
issues that are, after all, compiler-dependent.
The vtable layout is not specified in the standard. So COM (with or
without the +), is at this very moment very much compiler-dependent. I'm
sure that if the nice people working at Microsoft CL compiler had to
implement this new requirement they would be able to find a way out of
the predicament. After all, the vtable layout is what they decide the
vtable layout is.
Also, as many of our newsgroup colleagues have noticed, COM(-+?) should
be accesible from C code and Visual Basic code, so we really should not
get hung up on vtable issues related to COM(-+).
So I'll quit talking about this imaginary problem now.
--
Razvan Cojocaru
KeyID: 1024D/04CA34DE
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Eugene Gershnik
> On 7 Sie, 21:09, Eugene Gershnik <gersh...@gmail.com> wrote:
>
> > Because COM relies on virtual table layout
>
> No problem - the standard does not define what is a "virtual table
> layout", so it cannot introduce any conflicts there.
True but the standard cannot ignore implementation realities.
> If this would be a problem for Microsoft, then it is only because they
> have gone the cheapest way in the past and bound the specification of
> COM binary interface with the implementation details of their
> compiler. This is formally not a C++ problem.
The reason Microsoft (as well as Mozilla and many others) went this
way is because C++ standard decided that binary interoperability is
formally not a C++ problem. Other than sticking to platform's C ABI
there is AFAIK no other way to make C++ objects produced by different
compilers to directly use each other.
> Another way to look at it: it is possible to implement a COM component
> in plain C, which means that virtual tables are not necessarily
> involved there. In other words, you can piggy-back COM on existing
> vtable mechanics (as Microsoft did in the past), but you don't have
> to.
Yes you can use C parts of C++ to achieve binary interoperability
easily on any platform. COM (and its cousins like XPCOM) are the only
serious and successful attempt to change this state of affairs. Not to
mention that they form foundation of huge amount of modern software. A
change in C++ that is going to break existing code that relies on such
technologies has zero chance of being accepted.
--
Eugene
Eugene Gershnik
> Eugene Gershnik wrote:
> > On Aug 7, 8:58 am, Razvan Cojocaru <razva...@gmx.net> wrote:
>
> > [Restoring attribution]
> >> Eugene wrote:
>
> > [...]
> > Because COM relies on virtual table layout to achieve binary
>
> Commonly code written for the the VC compiler uses the proprietary
> attribute for a classs - novtable, specifying that the object mustn't
> have a vtable.
No this is *not* what this attribute does. What it actually does is to
make compiler/linker not generate the vtable for the interface (pure
abstract base class) *itself* since it can never be instantiated. The
derived implementations classes will definitely have *their* vtables
and they will be laid out according to the base class definition.
> I think you mean changing the abstract COM interfaces, would break the
> compatibility - that is true - but the destructor commonly isn't part of
> the abstract COM interfaces.
But it will be as soon as you make it virtual. This is exactly the
problem: every virtual function is automatically part of the COM
interface. If you start adding virtual functions that weren't there
before you break binary compatibility with code compiled with earlier/
different compilers.
--
Eugene
Andre Kaufmann
> On Aug 8, 10:47 pm, "gast...@hotmail.com" <gast...@hotmail.com> wrote:
>
>> I have just read a book about c#, and I must admit that a lot of
>> things are easier in c# /.Net, just because the language has an easier
>> model.
>
> The main problem with C# it is its proprietary nature. With C++, any
> interested party has roughly the same amount of influence on the
But effectively the influence tends to zero, if the interested party
isn't a member of the standardization committee. (I don't mean
discussions about features but to make decisions about a certain feature).
> development of the language. Not so with C# (or Java, for that
> matter). C# shall progress as MS sees fit, this will at some point no
> doubt involve breaking code and discontinuing support for it (think
> VB6.0/VB.Net).
VB hasn't been standardized, while C# has. And there is an open source
implementation of C# too. Even if MS would break compatibility, the open
source implementation would still work.
> Although C++'s keeping backward compatibility affects
> the language in negative ways, breaking large code bases is much worse
> than that.
The problem (for me) is that the evolution of C++ does take too much
time. There are too many decision makers involved. It's good on the one
side regarding stability, but on the other side evolution is slow.
Doesn't mean that fast evolution is always good.
Backwards compatibility is good, but shouldn't be a mantra in all cases.
E.g. that new keywords shouldn't be introduced, because this would break
too much code. Context sensitive keywords can't be used, because this
would be too complex for some compiler vendors to be implemented.
> [...]
Andre
Razvan Cojocaru
> way is because C++ standard decided that binary interoperability is
> formally not a C++ problem. Other than sticking to platform's C ABI
> there is AFAIK no other way to make C++ objects produced by different
> compilers to directly use each other.
> Yes you can use C parts of C++ to achieve binary interoperability
> easily on any platform. COM (and its cousins like XPCOM) are the only
> serious and successful attempt to change this state of affairs. Not to
> mention that they form foundation of huge amount of modern software. A
> change in C++ that is going to break existing code that relies on such
> technologies has zero chance of being accepted.
Well, CORBA offers that, and it works with more programming languages
than COM does, it's an open standard, works with a variety of compilers,
and doesn't only work on Windows. Goes without saying that it doesn't
care much about virtual table layouts.
--
Razvan Cojocaru
KeyID: 1024D/04CA34DE
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
carl.s...@gmail.com
*might* be a case where you don't want the destructor to be virtual,
although other methods of the class are. I've personally forgotten the
virtual destructor many more times than I've had to make it non-
virtual.
So to me, the proposal makes perfect sense:
1. If a class has a virtual method, make the destructor virtual as
well (issue a warning to tell the programmer).
2. Provide a way to explicitly mark a destructor as non-virtual if
you're in one of the exceptional cases where this is not desired.
Cheers,
Carl
Alex
wrote:
> Why all the complication, when you can simply do
> typeid(*pb); /* where pb is a pointer to the base class */
> The standard guarantees that this yields the type_info for the most
> derived class, if the base class is polymorphic.
True, however if the parent class has no virtual functions, it doesn't
happen. Inheritance is not synonym for polymorphism. A design may call
for just extending the base interface in derived classes. Or
inheriting only the behavior from the base class.
That said, try this and see what you get:
#include <iostream>
class Base {};
class Derived : public Base {};
int main()
{
Derived* pd = new Derived;
Base* pb = pd;
std::cout << typeid(*pb).name() << std::endl;
delete pd;
}
MSVC and gcc will print the base type name. I'd say that any compliant
compiler should do the same.
When the parent class has virtual functions, I suspect the performance
penalty of typeid(*pb) will be the same as for dynamic_cast and
virtual call returning typeid(*this) may be a cheaper way to go. The
bottom line is, the original example used to mock the code structure
could have been pulled out of context and the original author may have
had a valid case for it.
> There is a subtle, but important difference in the two examples.
> In the example given by Felipe, the derived class returns the type_info
> of *itself*. This is completely useless, as the client code can obtain
> the exact same information without a virtual function call.
>
> In the boost::any code, the holder class returns the type_info for *the
> class it contains* and is instantiated upon. This information is not
> obtainable in any other way.
I agree about the subtle difference. However, Felipe has referred to
Ogre authors in a very condescending way, which has prompted me to
actually look into the code and, as it turns out, it is a copy of
boost::any. I am, BTW, in no way associated to Ogre project/code.
Alex
--
Razvan Cojocaru
Not necessarily abstract base classes, any base class with at least one
virtual member function. Indeed, it would make less sense for a POD
(even one you might inherit from), to have any kind of vtable.
But having at least one virtual member function is an indication of the
designer's wish to use C++ polymorphism, and there we should have a
virtual destructor for the top base class in the hierarchy.
Your example is indeed very valid.
--
Razvan Cojocaru
KeyID: 1024D/04CA34DE
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Andre Kaufmann
> On Aug 9, 7:56 am, Andre Kaufmann <akfmn...@t-online.de> wrote:
>> Eugene Gershnik wrote:
Sorry, I expressed it wrong and you are right. I tend always to speak of
objects and classes, where I should speak of an interface, which doesn't
exist in C++ (IMHO by definition), since IIRC each C++ class has it's
(auto generated) destructor.
So it should read: ...specifying that the COM interface mustn't have...
> No this is *not* what this attribute does. What it actually does is to
> make compiler/linker not generate the vtable for the interface (pure
> abstract base class) *itself* since it can never be instantiated.
Precisely I think it prevents instantiation of a destructor and code
accessing/referencing the vtable. It's just an optimization, not a
requirement.
> [...]
> But it will be as soon as you make it virtual. This is exactly the
> problem: every virtual function is automatically part of the COM
> interface. If you start adding virtual functions that weren't there
> before you break binary compatibility with code compiled with earlier/
> different compilers.
Perhaps we are discussing different things and all statements are
correct in the context we are speaking of ?
I think you mean:
-----------------
If a virtual destructor (function) would be added to a COM interface,
this would break compatibility, since the interface would be changed.
The abstract COM interfaces can have only abstract functions by
definition. So such an interface shouldn't have an destructor at all and
therefore it can't (by definition) be made virtual.
We are thinking of:
-------------------
I thought of the implementation of the interfaces in the object derived
from the interface (or multiple interfaces) and I think Razvan Cojocaru
meant this too.
Changing the destructor in this object from "non virtual" to virtual
wouldn't affect COM compatibility.
> --
> Eugene
> [...]
Andre
Bo Persson
> Bo Persson wrote:
>> There are many cases where you might want to adhere to an
>> interface, without dynamically allocating the derived classes.
>
> Perhaps, but it's very dangerous to assume that that will always be
> the case, and the next source code maintainer or library users will
> feel the same way and not use the heap. It's wiser to impose
> behaviour constraints upfront by design, than to write 100 pages
> coding style documents telling your programmers not to use the heap.
Like adding a protected destructor, to disallow improper use. :-)
Heap allocation is still not a problem, unless you also have delete
through pointer to base. That is the only case that the virtual
destructor helps against.
>
>
>> Adding an entry at the end would affect derived classes. The
>> number of virtual functions in the interface is important.
>
> As Maciej Sobczak observed in a previous reply, the standard is
> silent about the virtual table layout. All talk about it is bound
> to be speculative, and IMHO largely irrelevant, so I'd rather not
> try to solve an imaginary problem.
The current language standard *allows* an implementation to define the
vtable layout so that it conforms to the Windows COM interface (or
rather, allowed the COM spec to use the existing vtable layout).
Changes to the language that might break this, is just about as
serious a backward compatibility break as you can get!
Doing this just to potentially save some clueless maintenance
programmer, definitely isn't worth it!
Bo Persson
--
Le Chaud Lapin
> It will also be true in C++ if you intend to use the most important
> aspect of object-oriented programmin, which is polymorphism (try to
> count how many design patterns in the Gang of Four's book make sense
May I take this opportunity to say that I think quite the opposite?
I must apologize in advance for offending Ye Ole Great Masters of C++,
but I think overemphasis on abstract programming is one of worst
mistakes made in introducing C++ to the young engineering community.
Abstract programming, IMO, is like a narcotic. Yes it works. Yes it's
powerful. But It should be used sparingly. Typically, something less
exotic like aspirin is not only sufficient, but superior, in that it
does its job without causing side-effects. The "aspirin" is getting
aggregates to behave like scalars, a primary early goal of OO-
programming.
Perhaps the masters of OO programming were so afraid that young
engineers would stall in the aggregates-behaving-as-scalars rut, they
deliberately pre-defined OO programming to be synonymous with abstract
programming. They implied:
"If you are not using abstract polymorphism, you are not doing OO
programming".
What they should have been implied, IMO, is..
"If you are not using abstract base classes, you are probably not
realizing the full benefits of OO programming."
Anyhow, I think the current state of affairs is a mess. I have
encountered countless programmers in my career, both junior and
senior, who use virtual functions as if they were adding decorative
whitespace. [It's sad - one engineer had gotten into the habit of
makinv every member function virtual, no matter what.] They bypass the
aspirin at every opportunity and go straight for the hydrocodone.
Then they suffer through concomitant side-effects. And we all know
that there are definitely "side-effects".
But we must put side-effects in quotes because technically, there are
no "side-effects", as it implies that there is something defective
about the language itself, which there is not. If one uses virtual
functions, certain subsequent events will inevitably result. That's in
the contract. It's when the programmer wants it both ways when serious
issues arise:
"I have made all my classes abstract, but I would like to be able to
copy one derived to another without thinking too hard."
Ok, well, perhaps you should not have done that.
I see countless posts in this group and elsewhere of programmers
trying in vain to force their abstract classes to behave as if they
were concrete, when they could have just made the classes concrete to
start with.
My preference:
Aim for nickel-and-dime facilities of C++.
Given a class, I would be predisposed to make it concrete, then ask
the following questions about two objects of that class:
1. Can I assign one to the other?
2. Can I provide comparison >, <, >=, <=, ==, != ?
3. How do I construct one from the other?
4. What conversion operators are there, if any?
5. Can I serialize it?
6. Does it operate on state _only_ within itself?
Belive it or not, for any non-GUI project, 95%+ of my code fits this
model.
Then...
For those classes that are necessarily abstract, I allow a bit of
hydrocodone. :)
-Le Chaud Lapin-
--
Eugene Gershnik
>
> But what is the advantage of
> the protected non virtual destructor compared to a protected virtual
> one ? I see only a slightly smaller vtable in the base class ?
There might also be speed advantage especially for classes with no-op
operator delete(). But the main issue is the fundamental principle
that one shouldn't be forced to pay for what one doesn't use.
Going back to the original suggestion a rule like "if a destructor for
a class with at least one virtual function is pubic then it should
automatically be virtual" might make sense for a *new* language.
Unfortunately it is too late for C++. Introducing such rule now (even
with possibility of user override) would break too much code.
A good compiler should warn if a class has virtual functions and
public non-virtual destructor. This ought to be more than enough for
this (relatively minor) issue. For comparison the warnings most modern
compilers give on if (i = 1) had in my experience completely
eliminated this problem without changing the language.
--
Eugene
Mathias Gaunard
what OO is and isn't? -mod }
On 10 aoūt, 07:53, Razvan Cojocaru <razva...@gmx.net> wrote:
> It will also be true in C++ if you intend to use the most important
> aspect of object-oriented programmin, which is polymorphism (try to
> count how many design patterns in the Gang of Four's book make sense
> without polymorphism). You might not call your most abstract class
> "Object", or you might have several such top base classes, but the
> principle remains the same.
A lot of people think righly that ad-hoc polymorphism is a very bad
programming paradigm.
Not using it means not really programming in an object-oriented way
though; I think the problem here is that people have different notions
of what OOP is.
I personally hate OOP and prefer object-based programming, with value
semantics.
--
Alex
> Alex wrote:
> > The main problem with C# it is its proprietary nature. With C++, any
> > interested party has roughly the same amount of influence on the
>
> But effectively the influence tends to zero, if the interested party
> isn't a member of the standardization committee. (I don't mean
> discussions about features but to make decisions about a certain feature).
Well, that's true for pretty much anything - if you choose not to be a
member of a governing body, you don't get to govern. If I understand
it right, a "one man band" company member of the C++ standard
committee gets the same amount of votes as Microsoft or Sun - exactly
one.
> Backwards compatibility is good, but shouldn't be a mantra in all cases.
> E.g. that new keywords shouldn't be introduced, because this would break
> too much code.
About a dozen are being introduced (some recycled) in C++0x as we
speak.
Alex
Eugene Gershnik
>
> Perhaps we are discussing different things and all statements are
> correct in the context we are speaking of ?
>
> I think you mean:
> -----------------
> If a virtual destructor (function) would be added to a COM interface,
> this would break compatibility, since the interface would be changed.
> The abstract COM interfaces can have only abstract functions by
> definition. So such an interface shouldn't have an destructor at all and
> therefore it can't (by definition) be made virtual.
Well, yes but this is not the main problem. See below
>
> We are thinking of:
> -------------------
> I thought of the implementation of the interfaces in the object derived
> from the interface (or multiple interfaces) and I think Razvan Cojocaru
> meant this too.
> Changing the destructor in this object from "non virtual" to virtual
> wouldn't affect COM compatibility.
The problem is that C++ doesn't have a special interface concept/
keyword. An interface is just an abstract base class. COM (or XPCOM or
many others) interfaces look like
class ISomething
{
public:
virtual unsigned long foo() = 0;
};
class ISomethingElse : public ISomething
{
public:
virtual unsigned long bar() = 0;
};
Imagine these declarations compiled with a "new" compiler that
silently injects virtual destructors and an "old" (i.e. current) one.
The code produced by one wouldn't be able to use the implementations
produced by the other.
Regardless of abstract reasoning whether interfaces should or
shouldn't have a destructor there is a backward compatibility problem
here.
--
Eugene
Andre Kaufmann
> [...]
> Going back to the original suggestion a rule like "if a destructor for
> a class with at least one virtual function is pubic then it should
> automatically be virtual" might make sense for a *new* language.
> Unfortunately it is too late for C++. Introducing such rule now (even
> with possibility of user override) would break too much code.
I don't think it would break >too much< code. Could you give an example
? COM isn't IMHO an example, since COM uses interfaces, which by
definition shouldn't have an destructor at all. If there isn't one, it
can't be made virtual by such a new rule too.
> A good compiler should warn if a class has virtual functions and
> public non-virtual destructor. This ought to be more than enough for
> this (relatively minor) issue.
Well without the warning you get perhaps memory leaks, which IMHO isn't
a minor issue. The same is true for a missing override. I'm also told
this to be a minor issue, but this too introduces runtime errors, which
I can't prevent currently in C++.
> For comparison the warnings most modern
> compilers give on if (i = 1) had in my experience completely
> eliminated this problem without changing the language.
A good compiler shouldn't IMHO even compile such code. If old (ugly)
style code should be compiled a compiler switch enabling the old
behavior would do the trick. This would allow a slow evolution of the
language - but perhaps it's better to introduce a new one, which at
least can compile and use C++.
> --
> Eugene
Andre
Andrei Alexandrescu
> Every base class that _has_at_least_one_virtual_member_function_ should
> have a virtual destructor. Because obviously there's some polymorphism
> going on there. Putting in a virtual member function and then making the
> destructor protected is a very suspect way of dodging the issue.
While I agree that this rule applies to most cases, I'll point out that
exception classes do have virtual functions but don't need a virtual
destructor. Also ScopeGuard's implementation uses a base class with no
virtual destructor.
Andrei
--
Nominal Pro
> I have spent eight plus years in the software industry
> working in applications programming on C++/ Windows. My current company is
> now moving big time towards Java/ J2EE based technologies. Most of the
other
> companies which are writing application software are also moving (or have
> alreadt moved) to J2EE or to .Net.
What you call "the software industry" is vaguely defined. There are
"software companies" (business that write and sell end-user software,
also known as ISVs), enterprise development (software written for
internal use), and embedded development. And these categories are
fairly broad too.
My guess is that you work in "enterprise development," where there has
been a shift away from C++.
> So is there no future for C++ in application software?
The death of C++ is greatly exaggerated. I suspect you are seeing the
decline in the use of C++ in enterprise development. In the early 90s,
C++ dominated enterprise development, simply because Java and C# had
not been invented. For object-oriented languages, C++ and SmallTalk
were the only real choices, and C++ had advantages over SmallTalk.
When C++ has nearly 100% of the enterprise development pie, its share
of the market can only go down, not up, as newer language choices
become available.
However, I doubt that even if C++ declines in enterprise development,
it will not go extinct. C++ will continue to dominate in software
companies (companies that sell software to the end user). For example,
Microsoft may sell C# to the world, but internally, it will continue
to use C++. Most end-user software is still C/C++ (except on Apple's
OS X).
> What do the people on this group feel about it?
In the grand scheme of things, you have to adapt and remain flexible.
My father started as a COBOL programmer, and it wasn't a language that
lasted his entire career. Cling too long to a narrow and rigid
skillset as the industry you work in shifts, and you could wake up
someday and realize that you are behind the curve.
> I understand that Systems side and Embedded are still the areas where C++
is
> being used well. But is that all?
No, you are forgetting about "software companies" (ISVs) -- the
companies that write the software that you buy at your local computer
store. Adobe, Intuit, Symantec, etc. There are also entire industries
within the category of ISVs, For example, the video game industry from
Nintendo to Electronic Arts. C++ continues to dominate in this space.
> What do the people who have invested time
> and energy in C++ should do?
It depends on your career goals. If you choose to stay in "enterprise
development" then be prepared to adapt to changing market share
between C++, Java, and C#. Or else, you can switch to working for an
ISV with stable products, go into business for yourself (become your
own ISV), learn video game development or work for Microsoft, where C+
+ will continue to dominate.
Razvan Cojocaru
>> the case, and the next source code maintainer or library users will
>> feel the same way and not use the heap. It's wiser to impose
>> behaviour constraints upfront by design, than to write 100 pages
>> coding style documents telling your programmers not to use the heap.
>
> Like adding a protected destructor, to disallow improper use. :-)
I agree, but if the implication here is that I've suggested adding
protected destructors to disallow improper use you might wish to scroll
the thread up :-).
--
Razvan Cojocaru
KeyID: 1024D/04CA34DE
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Razvan Cojocaru
>> have a virtual destructor. Because obviously there's some polymorphism
>> going on there. Putting in a virtual member function and then making the
>> destructor protected is a very suspect way of dodging the issue.
>
> While I agree that this rule applies to most cases, I'll point out that
> exception classes do have virtual functions but don't need a virtual
> destructor. Also ScopeGuard's implementation uses a base class with no
> virtual destructor.
I agree that the exception classes can get away with it, mainly because
you don't usually 'catch(const std::exception* pe)'. Hence, premature
optimization has somehow hesitated to be the root of all evil in this case.
This is however more of an exception (pun intended ;-) ) than the rule,
as you've kindly noticed, and having the destructor virtual by default
there would not hurt anything (unless you're hard pressed for space,
programming embedded applications, in which case you can have some new
or recycled keyword for explicitly not making the destructor virtual).
As for ScopeGuard, I'm assuming you're talking about this article:
http://www.ddj.com/cpp/184403758
in particular about class ScopeGuardImplBase. Which does not have any
virtual member function to begin with, so it is not a candidate for
automatically making the destructor virtual, and is a fine example of
optimization to the core.
Since we're agreed that in most cases it would make a lot of sense to
automatically make the destructor virtual by default in classes with
virtual member functions, wouldn't it be more intuitive to have _that_
behaviour as default, and explicit instructions for the compiler for the
extreme and rare cases where it is _not_ desired? Which I've not been
convinced as of yet that justifiably occur anywhere else except in
embedded systems...
--
Razvan Cojocaru
KeyID: 1024D/04CA34DE
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
gas...@hotmail.com
> interested party has roughly the same amount of influence on the
> development of the language. Not so with C# (or Java, for that
> matter). C# shall progress as MS sees fit
they use it heavily they will not incoporate features from 'practise'.
The c++ standarization now takes such a long time, especailly when in
the standard they can not revoke it. Therefore the Tr1 setup.
> What's hurting C++ are several things:
>
> - C people say its bloated
C still has its own place
> - Java/C# people say it leaks memory
I agree. Selectable GC (in a library or requiring that classes are
derived from some sort of base class) would be nice extension. The
power of c++ is always that it spans low level and high level
constructs, but the high level constructs could be served better if
programmers weren't required to think about this.
Bo Persson
> So far, the arguments against the proposal have always been that
> there *might* be a case where you don't want the destructor to be
> virtual, although other methods of the class are. I've personally
> forgotten the virtual destructor many more times than I've had to
> make it non- virtual.
Ok, YMMV.
>
> So to me, the proposal makes perfect sense:
> 1. If a class has a virtual method, make the destructor virtual as
> well (issue a warning to tell the programmer).
> 2. Provide a way to explicitly mark a destructor as non-virtual if
> you're in one of the exceptional cases where this is not desired.
>
It still breaks old code.
The rule so far has been that if I want a destructor virtual, I have
to write 'virtual' in front of it. If I don't want it to be virtual, I
don't write 'virtual'.
Now I have to find all place of these non-virtual destructors (how do
you do that?) and mark them as
'I-really-really-did-not-want-this-to-be-virtual'. Then I have to
distribute the source to everyone who intends to compile with C++0x
(or whatever). Possibly using a conditional compile for older
compilers.
All this just so you can occasionally forget to write 'virtual' when
you actually intended to? Cost-benefit analysis?
Bo Persson
Eugene Gershnik
> > The reason Microsoft (as well as Mozilla and many others) went this
> > way is because C++ standard decided that binary interoperability is
> > formally not a C++ problem. Other than sticking to platform's C ABI
> > there is AFAIK no other way to make C++ objects produced by different
> > compilers to directly use each other.
> > [...]
> > Yes you can use C parts of C++ to achieve binary interoperability
> > easily on any platform. COM (and its cousins like XPCOM) are the only
> > serious and successful attempt to change this state of affairs. Not to
> > mention that they form foundation of huge amount of modern software. A
> > change in C++ that is going to break existing code that relies on such
> > technologies has zero chance of being accepted.
>
No AFAIK it doesn't. Or if it does it uses the same vtable approach.
See the word 'directly' above. It is relatively simple to let anything
to talk to anything if you have an adapter in the middle. It is also
quite expensive. The trick is to have one C++ class call another built
by other people just like it calls another class in the same program.
C lets you call functions built by other people so seamlessly people
rarely think about it.
--
Eugene
--
Alex
> > The main problem with C# it is its proprietary nature. With C++, any
> > interested party has roughly the same amount of influence on the
> > development of the language. Not so with C# (or Java, for that
> > matter). C# shall progress as MS sees fit
>
> That doesn't need to be disadvantagous: they can react quickly and if
> they use it heavily they will not incoporate features from 'practise'.
It doesn't need to be, but sometimes it is. And reacting quickly can
be disadvantageous to the point of ruining the language.
Java generics tale is probably the best recent example. See "Seeking
the joy in Java" ( http://www.artima.com/weblogs/viewpost.jsp?thread=173229
).
> The c++ standarization now takes such a long time, especailly when in
> the standard they can not revoke it. Therefore the Tr1 setup.
Well, I guess once you end up with vector<bool> and likes, you start
applying the carpenter's rules - "measure twice, cut once".
> > - C people say its bloated
>
> C still has its own place
I did not say it doesn't. What I meant is that there is a certain
amount of unjustified and indiscriminate criticism of C++ from the C
crowd. Typically they neglect the fact that C++ is on an order of
magnitude higher design level with minimal (often zero) price.
> > - Java/C# people say it leaks memory
>
> I agree. Selectable GC (in a library or requiring that classes are
> derived from some sort of base class) would be nice extension. The
> power of c++ is always that it spans low level and high level
> constructs, but the high level constructs could be served better if
> programmers weren't required to think about this.
Garbage collectors (in addition to other techniques such as RAII and
smart pointers) for C++ have been available for a long time. I'm not
saying standard optional garbage collector wouldn't be beneficial. It
definitely would, but we can do without it.
Alex
Eugene Gershnik
> Eugene Gershnik wrote:
> > [...]
> > Going back to the original suggestion a rule like "if a destructor for
> > a class with at least one virtual function is pubic then it should
> > automatically be virtual" might make sense for a *new* language.
> > Unfortunately it is too late for C++. Introducing such rule now (even
> > with possibility of user override) would break too much code.
>
> I don't think it would break >too much< code. Could you give an example
> ? COM isn't IMHO an example, since COM uses interfaces, which by
> definition shouldn't have an destructor at all. If there isn't one, it
> can't be made virtual by such a new rule too.
See my other reply. COM interface is just a class/struct in C++. Or
are you perhaps saying that it the dtor happens to be compiler-
generated then your rule shouldn't apply? If so it will still leave
far too many normal classes vulnerable to the problem you are trying
to solve. Not to mention that saome people do put ctor/dtor in the
class/struct representing COM interface just for completeness.
If this is not what you are saying then you will break almost all COM
code out there. ;-)
--
Eugene
carl.s...@gmail.com
> > So to me, the proposal makes perfect sense:
> > 1. If a class has a virtual method, make the destructor virtual as
> > well (issue a warning to tell the programmer).
> > 2. Provide a way to explicitly mark a destructor as non-virtual if
> > you're in one of the exceptional cases where this is not desired.
>
> It still breaks old code.
Yes, true. But then: of all the cases where old code would break, how
many of those would be actual mistakes that would need fixing? I would
think it's a vast majority.
Breaking old code, of course, is kind of rude, but I really think that
making it harder to make mistakes is badly needed in some areas of C++
(virtual functions being one of them - I just wasted 2 hours the other
day because I used a slightly wrong parameter type for a function I
though I was overriding. C# has done a decent job in that area, I
think). Changing compilers on a big code base has never been a
painless operation in my experience anyway.
But hey, many compilers already warn about it. Maybe an alternative,
softer solution is to make sure all compilers do that, and provide a
standard way of declaring a destructor as non-virtual, instead of
relying on compiler-specific pragmas to get rid of the warning.
Carl
Eugene Gershnik
[snipping heavily]
> C. it's very probable that, at least at some point in time, someone will
> put one of these derived class objects on the heap, and use it through a
> base class pointer. Hence, we need to worry about the destructors, and
> the only and best way for a destructor to be in this case, is virtual.
It was repeatedly explained to you the base class interface doesn't
have to include destructor at all. If you don't ever use this approach
- fine, but don't claim that what you do is universal principle of OO.
> >>http://www.research.att.com/~bs/C++0x_panel.pdf
>
> > This argument is nothing but an "appeal to authority". The slides
> > provide no context or discussion about the issue.
>
> Alas, it was simply an appeal to reason. I had hoped that you would at
> least take a well respected expert's opinion on the issue less lightly [...]
You didn't link any opinion, just some "on the margin" notes from some
presentation, not even a stand-alone text. It might very well be that
the author has excellent arguments for your case but you haven't shown
any. Without them it is just that: an appeal to authority.
> > I can only suggest that you research how COM (without +) works, how OO
> > interfaces are idiomatically implemented in C++ and how compilers lay
> > out virtual function tables for class hierarchies.
>
> Like I've said in an earlier reply to Pete Becker, which, as I'm typing
> this, has not yet gone through the newsgroup moderation queue, I'd
> rather not speculate about issues unspecified in the C++ ISO standard,
> issues that are, after all, compiler-dependent.
If you propose changes to the language you need to examine existing
implementations and your impact on them very, very carefully. As far
as I know "breaking existing code" is number one reason to reject any
proposed change.
> The vtable layout is not specified in the standard. So COM (with or
> without the +), is at this very moment very much compiler-dependent. I'm
> sure that if the nice people working at Microsoft CL compiler had to
> implement this new requirement they would be able to find a way out of
> the predicament. After all, the vtable layout is what they decide the
> vtable layout is.
Sigh. I can only repeat my suggestion above. Had you followed it you
would discover that there is nothing nice people at MS can do other
than disable your proposed extension by default. Which would amount to
the same thing as being rejected by the standard committee.
--
Eugene
Walter Bright
> I agree. Selectable GC (in a library or requiring that classes are
> derived from some sort of base class) would be nice extension. The
> power of c++ is always that it spans low level and high level
> constructs, but the high level constructs could be served better if
> programmers weren't required to think about this.
I'm not so sure optional gc would work out very well. Suppose you're a
library designer - do you design it to work with gc, without gc, or
both? Doesn't this make it more difficult for the library designer, not
less?
gas...@hotmail.com
wrote:
> gast...@hotmail.com wrote:
> > I agree. Selectable GC (in a library or requiring that classes are
> > derived from some sort of base class) would be nice extension. The
> > power of c++ is always that it spans low level and high level
> > constructs, but the high level constructs could be served better if
> > programmers weren't required to think about this.
>
> I'm not so sure optional gc would work out very well. Suppose you're a
> library designer - do you design it to work with gc, without gc, or
> both? Doesn't this make it more difficult for the library designer, not
> less?
Ah I had the STL in mind. The STL containers do not have ownership
semantics in case of pointers. Only if all objects are GC controlled,
library writers can take advantage of that, but that wasn't my initial
thoughts. But maybe I simplify things now.
Francis Glassborow
> On Aug 9, 11:07 pm, Razvan Cojocaru <razva...@gmx.net> wrote:
>
> [snipping heavily]
>
>> C. it's very probable that, at least at some point in time, someone will
>> put one of these derived class objects on the heap, and use it through a
>> base class pointer. Hence, we need to worry about the destructors, and
>> the only and best way for a destructor to be in this case, is virtual.
>
> It was repeatedly explained to you the base class interface doesn't
> have to include destructor at all. If you don't ever use this approach
> - fine, but don't claim that what you do is universal principle of OO.
>
>>>> http://www.research.att.com/~bs/C++0x_panel.pdf
>>> This argument is nothing but an "appeal to authority". The slides
>>> provide no context or discussion about the issue.
>> Alas, it was simply an appeal to reason. I had hoped that you would at
>> least take a well respected expert's opinion on the issue less lightly [...]
>
> You didn't link any opinion, just some "on the margin" notes from some
> presentation, not even a stand-alone text. It might very well be that
> the author has excellent arguments for your case but you haven't shown
> any. Without them it is just that: an appeal to authority.
>
And Bjarne Stroustrup is a highly active member of WG21 and certainly
raised this issue. So the fact that it has not been added to the draft
for C++0x would imply (correctly as it happens) that the gains did not
justify a change.
What WG21 has done is make it easier to add a virtual dtor to a base class:
class base {
public:
virtual ~base() = default;
....
};
Andre Kaufmann
> Razvan Cojocaru wrote:
>> Every base class that _has_at_least_one_virtual_member_function_ should
> While I agree that this rule applies to most cases, I'll point out that
> exception classes do have virtual functions but don't need a virtual
> destructor.
What if the exception
class Exception : ExceptionBase {....};
is thrown by:
throw new Exception();
?
{ Even if it's a rare case or "don't write it this way code" - but
anyways it's just the same as needing non virtual destructors in base
classes with virtual functions -> rare case IMHO too).
> Also ScopeGuard's implementation uses a base class with no
> virtual destructor.
Aren't stack allocated objects which use virtual functions a minority ?
I don't know for sure.
A virtual destructor introduces somewhat overhead, but in the context of
polymorphisms it's IMHO needed, if the objects are allocated on the
heap. For all the other ones (rare cases) the overhead is IMHO
neglectable or can be omitted by declaring the destructor explicitly non
virtual e.g. a solution would be to use the explicit keyword:
explicit ~myclass() {} // Explicitly non virtual destructor
Currently the compiler warns me about a "non virtual destructor", when I
add virtual functions. But to prevent this warning I have to temporarily
disable it - which I can't if I want to support all C++ compilers. Or by
adding a virtual destructor ?!
So in any case it would make sense to enhance the C++ language, to allow
me to express my intention, to have explicitly a "non virtual destructor".
To sum it up we have the choice between:
a) To pay for the rare cases where the destructor is made automatically
virtual, where it shouldn't be and where the developer has forgotten
to add a keyword to make the destructor explicitly non virtual.
b) Current state: Destructor stays non virtual, but when polymorphism
is used with heap objects memory leaks and weird behavior at
runtime may occur.
I would decide a)
> Andrei
Andre
Andre Kaufmann
> On Aug 10, 12:15 pm, Andre Kaufmann <akfmn...@t-online.de> wrote:
>> Eugene Gershnik wrote:
>>> [...]
>
See my other reply too ;-).
> are you perhaps saying that it the dtor happens to be compiler-
No I only state that COM interfaces are commonly declared this way:
__declspec(novtable) struct ....
and commonly a guid is assigned by using:
struct __declspec(uuid("xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"))
and therefore the compiler has enough information about the struct to be
a COM interface, where it would be dumb of the compiler to add
automatically a virtual destructor or convert an existing one (which
shouldn't be the case for interfaces).
So in most cases the compiler could do just the right thing - IMHO.
> Not to mention that saome people do put ctor/dtor in the
> class/struct representing COM interface just for completeness.
Which is against the definition of interfaces - even if there isn't
anything like them in C++.
> [...]
Andre Kaufmann
> [...]
> Well, yes but this is not the main problem. See below
>
> Regardless of abstract reasoning whether interfaces should or
> shouldn't have a destructor there is a backward compatibility problem
> here.
I don't think that there is much COM code, which doesn't use the
proprietary COM extensions, therefore the compiler can differentiate
between COM classes and C++ classes and wouldn't IMHO be affected by the
discussed C++ destructor changes.
> --
> Eugene
> [...]
Andre
Andrei Alexandrescu
>> While I agree that this rule applies to most cases, I'll point out that
>> exception classes do have virtual functions but don't need a virtual
>> destructor. Also ScopeGuard's implementation uses a base class with no
>> virtual destructor.
>
> I agree that the exception classes can get away with it, mainly because
> you don't usually 'catch(const std::exception* pe)'. Hence, premature
> optimization has somehow hesitated to be the root of all evil in this case.
Agreed. Exceptions are odd beasts - the only type (well, "kind" to bring
a little Haskell snootiness to the discussion) in C++ that has at the
same time value and dynamic polymorphic semantics.
> This is however more of an exception (pun intended ;-) ) than the rule,
> as you've kindly noticed, and having the destructor virtual by default
> there would not hurt anything (unless you're hard pressed for space,
> programming embedded applications, in which case you can have some new
> or recycled keyword for explicitly not making the destructor virtual).
>
> As for ScopeGuard, I'm assuming you're talking about this article:
>
> http://www.ddj.com/cpp/184403758
>
> in particular about class ScopeGuardImplBase. Which does not have any
> virtual member function to begin with, so it is not a candidate for
> automatically making the destructor virtual, and is a fine example of
> optimization to the core.
Whew :o).
> Since we're agreed that in most cases it would make a lot of sense to
> automatically make the destructor virtual by default in classes with
> virtual member functions, wouldn't it be more intuitive to have _that_
> behaviour as default, and explicit instructions for the compiler for the
> extreme and rare cases where it is _not_ desired? Which I've not been
> convinced as of yet that justifiably occur anywhere else except in
> embedded systems...
I definitely remember Bjarne told me three years ago that he wants to
propose that very behavior. I don't know what happened with that idea.
Probably since much more important things were on the plate, this fell
through the cracks as it's not really a blocker. But there's definitely
a paper trace of that. Not sure this has been mentioned in this long
discussions, but e.g. search
http://www.research.att.com/~bs/C++0x_panel.pdf for "virtual".
Andrei
--
gas...@hotmail.com
> > they use it heavily they will not incoporate features from 'practise'.
>
> It doesn't need to be, but sometimes it is. And reacting quickly can
> be disadvantageous to the point of ruining the language.
> Java generics tale is probably the best recent example. See "Seeking
> the joy in Java" (http://www.artima.com/weblogs/viewpost.jsp?thread=173229
It wouldn't be a problem if they fix it and break backards
compatiblity
> > The c++ standarization now takes such a long time, especailly when in
> > the standard they can not revoke it. Therefore the Tr1 setup.
>
> Well, I guess once you end up with vector<bool> and likes, you start
> applying the carpenter's rules - "measure twice, cut once".
The story of vector<bool> is lawyas good for a chapter or two in
Sutter's or Meyers book. As far as I am concerned just fix it (and
make a normal container out of it). Btw the auto keyword gets new
semantics.
>
> > > - C people say its bloated
>
> > C still has its own place
>
> I did not say it doesn't. What I meant is that there is a certain
> amount of unjustified and indiscriminate criticism of C++ from the C
> crowd. Typically they neglect the fact that C++ is on an order of
> magnitude higher design level with minimal (often zero) price.
I agree. I work in the application development, and for my part the c+
+ may even on a higher design level, notably automatic memory
management.
Maybe if you work on kernels you want to control everything. I ve
written long ago a simple driver in Windows, and you have there
certain memory pools to allocate from (non paged, paged). In c you can
just call the correct function, but it wouldn't be hard to make such a
thing also for c++. Maybe in this (highly specialized) area some
certain c++ features would be forbidden, but even there I can imagine
that the c++ model (with matching constructor / destructor) and STL
can be quite handy.
>
> > > - Java/C# people say it leaks memory
>
> > I agree. Selectable GC (in a library or requiring that classes are
> > derived from some sort of base class) would be nice extension. The
> > power of c++ is always that it spans low level and high level
> > constructs, but the high level constructs could be served better if
> > programmers weren't required to think about this.
>
> Garbage collectors (in addition to other techniques such as RAII and
> smart pointers) for C++ have been available for a long time. I'm not
> saying standard optional garbage collector wouldn't be beneficial. It
> definitely would, but we can do without it.
Yes you can do without it. You can als do without smart pointers.
However smart pointers relieve some tasks, and GC does that job better
(e.g. circular references). The less you have to concentrate on
language (c++) technicalities the better it is imo.
Mathias Gaunard
> > While I agree that this rule applies to most cases, I'll point out that
> > exception classes do have virtual functions but don't need a virtual
> > destructor. Also ScopeGuard's implementation uses a base class with no
> > virtual destructor.
>
> I agree that the exception classes can get away with it, mainly because
> you don't usually 'catch(const std::exception* pe)'.
Honestly, I do not see how that is related.
The recommended way to catch exceptions is by const-reference, which
still means that your object can actually be of a derived type.
--
Nicola Musatti
[...]
> It will also be true in C++ if you intend to use the most important
> aspect of object-oriented programmin, which is polymorphism (try to
> count how many design patterns in the Gang of Four's book make sense
> without polymorphism). You might not call your most abstract class
> "Object", or you might have several such top base classes, but the
> principle remains the same.
This might have been true for C++ in the early 90's and probably still
is for languages such as Java and C#, although generics blur the issue
somewhat; however C++ has had templates for a long time now and in
many contexts either templates alone or a judicious combination of
templates and inheritance are a better solution than inheritance by
itself. What you say about "Design Patterns" is true, but that only
makes evident a limitation in the book, or rather in the languages it
tries to cater for. C++ allows for a far richer sets of idioms than
"pure" object oriented languages.
> > Not at all. It breaks some particular notion of how to implement an
> > object oriented design, but there are many other ways of doing things.
>
> Indeed there are, however merely being able to do something does not
> imply the wisdom of doing so. I would further argue that since the
> central notion of pure object-oriented programming is the class
> hierarchy (subtyping), and you cannot in good faith assume that your
> classes' users will refrain from using the heap, you have to follow the
> principle of least surprise.
That is way, when your base classes are not meant to be used for
polymorphic destruction, you better ensure that their destructor is
not accessible.
> > Hmm, I don't recall anyone saying that having virtual destructors for
> > all of your base classes is nonsense. Seems to me the discussion was
> > about whether every base class *must* have a virtual destructor. If you
> > wan't 'em, feel free. But don't insist that I have to follow your
> > design approach and apply the techniques that it necessitates. There
> > are more things in heaven and Earth, Horatio, than are dreamt of in
> > your philosophy.
>
> Every base class that _has_at_least_one_virtual_member_function_ should
> have a virtual destructor. Because obviously there's some polymorphism
> going on there. Putting in a virtual member function and then making the
> destructor protected is a very suspect way of dodging the issue.
You are assuming that doing so is not the result of a careful choice.
That strikes me as rather unfair towards your interlocutors.
> _All_ base classes _with_at_least_one_virtual_member_function_ should
> have a virtual destructor. You never know. Might be that a source code
> maintainer will use the heap like that. Might be that you're writing a
> library and some libary user will want to use a container of base class
> pointers to derived classes objects. That sort of thing happens all the
> time in GUI libraries (the Composite pattern).
I agree that one should try and make it impossible to misuse one's
code, but only the original coder has a say on what constitutes
misuse; going against her/his judgment (when it is documented!!) is
foolish even if the attempt isn't blocked at the code level.
> I've done my best to show with examples why I believe that's a very
> strong candidate for a "default" rule of thumb in any software shop's
> coding style / coding policy manual.
>
> I leave it to you to show me some examples where having a virtual
> destructor for your base class with at least one virtual member function
> would make your code worse in some way. Please exclude the "legacy code
> that's been written like that" argument - that code can be recompiled,
> or we can compile our applications in "deprecated mode". You keep saying
> there are sometimes better ways but have yet to enlighten us with such
> an example.
Any polymorphic class for which deletion shouldn't be performed by
general users. Classes that are subject to caching or pooling are
natural candidates.
Cheers,
Nicola Musatti
Andre Kaufmann
> carl.s...@gmail.com wrote:
> [...]
>
> It still breaks old code.
Some lines to add to my recent post:
One comes to my mind:
Derived interfaces. Appending a function, in this case a virtual
destructor, would break old COM code.
But only where the commonly used attribute:
"declspec(novtable)" is not used.
> Bo Persson
Andre
Eugene Gershnik
wrote:
>
> I'm not so sure optional gc would work out very well. Suppose you're a
> library designer - do you design it to work with gc, without gc, or
> both? Doesn't this make it more difficult for the library designer, not
> less?
Look like this is no different from tons of other choices a library
designer has to make in a multi-paradigm language. Do you use
exceptions or error codes? Standard string or homegrown (and better)
one? iostreams or something else? etc. etc.
It actually touches on the issue some people mentioned in this thread.
It is much easier to use and build libraries in single-paradigm
languages than in C++. If I need some FooBar facility while writing a
Java/C# app I am 100% certain that all available libraries will easily
"fall into" my code with at most a few hours of integration time. I
will spend my time mostly reading on the "problem domain" part of the
library and not on the implementation technicalities.
With C++ any new library is a nightmare. First you need to figure out
how to build it (and whether you want to build it or binaries are ok -
if they exist). Then you need to adapt its error handling/threading/
resource management/data structures/IO/character encodings etc. to the
ones used in your code. This process is often tricky and error-prone
so far too many bugs are introduced just because some third party
library wasn't integrated properly.
The time spent on these integration tasks is mostly fixed and over the
lifetime of a long project may not be that significant but for the
smaller ones Java/C# application will be ready and delivered while the
C++ one is still being built.
--
Eugene
peter koch larsen
wrote:
> gast...@hotmail.com wrote:
> > I agree. Selectable GC (in a library or requiring that classes are
> > derived from some sort of base class) would be nice extension. The
> > power of c++ is always that it spans low level and high level
> > constructs, but the high level constructs could be served better if
> > programmers weren't required to think about this.
>
> I'm not so sure optional gc would work out very well. Suppose you're a
> library designer - do you design it to work with gc, without gc, or
> both? Doesn't this make it more difficult for the library designer, not
> less?
More difficult in what way? I believe that all current code with
manually managed memory will continue to work in gc C++. Thus, the
effort will not be greater than if the library designer generated code
for the current version of C++. Of course, the designer now has to
face a dilemma: will he write only for gc C++ and risk losing
customers (namely the segment that continues without gc) or will he go
the whole way and perform manual memory-management? Luckily, I see no
reason not to supply a library for gc only in order to later - if
demand requires so - add the manual memory management without any
implications for existing users.
/Peter
Andrei Alexandrescu
I guess "{}" is shorter than "= default" :o). But maybe you are
referring to a shortcut for this:
class base {
public:
virtual ~base() = 0;
....
};
inline base::~base() {}
Is that correct?
Andrei
Andrei Alexandrescu
> Andrei Alexandrescu wrote:
>> Razvan Cojocaru wrote:
>>> Every base class that _has_at_least_one_virtual_member_function_ should
>> [...]
>> While I agree that this rule applies to most cases, I'll point out that
>> exception classes do have virtual functions but don't need a virtual
>> destructor.
>
> What if the exception
>
> class Exception : ExceptionBase {....};
>
> is thrown by:
>
> throw new Exception();
>
> ?
>
> { Even if it's a rare case or "don't write it this way code" - but
> anyways it's just the same as needing non virtual destructors in base
> classes with virtual functions -> rare case IMHO too).
That's more than just a rare case, it's a faux pas of the dimension of a
presidential candidate's extramarital affair. catch (...) will be unable
to do proper teardown of the exception object and that's a net leak of
state. Before anyone points out that MFC does exactly that, I should
note that I have a marksman badge and a short temper :o).
>> Also ScopeGuard's implementation uses a base class with no
>> virtual destructor.
>
> Aren't stack allocated objects which use virtual functions a minority ?
> I don't know for sure.
They are, and probably few if any would shed a tear if they were
disallowed entirely. In fact it would rid us of a number of problems
starting with slicing.
> A virtual destructor introduces somewhat overhead, but in the context of
> polymorphisms it's IMHO needed, if the objects are allocated on the
> heap. For all the other ones (rare cases) the overhead is IMHO
> neglectable or can be omitted by declaring the destructor explicitly non
> virtual e.g. a solution would be to use the explicit keyword:
>
> explicit ~myclass() {} // Explicitly non virtual destructor
>
>
> Currently the compiler warns me about a "non virtual destructor", when I
> add virtual functions. But to prevent this warning I have to temporarily
> disable it - which I can't if I want to support all C++ compilers. Or by
> adding a virtual destructor ?!
>
> So in any case it would make sense to enhance the C++ language, to allow
> me to express my intention, to have explicitly a "non virtual destructor".
>
>
> To sum it up we have the choice between:
>
> a) To pay for the rare cases where the destructor is made automatically
> virtual, where it shouldn't be and where the developer has forgotten
> to add a keyword to make the destructor explicitly non virtual.
>
> b) Current state: Destructor stays non virtual, but when polymorphism
> is used with heap objects memory leaks and weird behavior at
> runtime may occur.
>
> I would decide a)
Makes sense to me too. But it's just not going to happen.
Andrei
Nicola Musatti
[...]
> I have just read a book about c#, and I must admit that a lot of
> things are easier in c# /.Net, just because the language has an easier
> model. The basic rule of value and reference classes is small and
> should be easy to understand (at least for a c++ programmer).
There are no such things as value classes in C#. C#'s structs are much
closer in semantics to C structs than to C++'s directly allocated
class instances.
> Imo the
> best improvements of c# compared to c++ are the gc and the properties,
> but also other features are quite handy. One would almost think that
> they are experienced c++ programmers, fixing a lot 'unhandy' c++
> features.
Some of C# features are indeed handy and I find it interesting to note
that C# appears to have influenced some of the features that are being
added to C++. However I have yet to find a C# feature that doesn't
have its downside when compared to its C++ counterpart.
GC makes memory handling much simpler, to the extent that I wonder if
hand coded memory management isn't a form of premature optimization;
on the other hand it makes it much more complicated to deal with
objects that require timely destruction.
Properties are nice, but they don't have that big an impact on code
effectiveness.
On the other hand in my limited experience the lack of destructors and
the limitations of generics compared to C++ templates make C# a
worthwhile alternative to C++ only when you access to the .NET
libraries is an important advantage.
Cheers,
Nicola
Eugene Gershnik
> Eugene Gershnik wrote:
> > On Aug 10, 12:15 pm, Andre Kaufmann <akfmn...@t-online.de> wrote:
> >> Eugene Gershnik wrote:
>
> No I only state that COM interfaces are commonly declared this way:
>
> __declspec(novtable) struct ....
>
> and commonly a guid is assigned by using:
>
> struct __declspec(uuid("xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"))
>
> and therefore the compiler has enough information about the struct to be
> a COM interface,
This is getting rather platform specific but I hope moderators will
let this through since at least some of it applies to standard C++.
1. Both these attributes do *not* say that the class they apply to is
a COM interface. The first one is a nice optimization for any abstract
class as we already discussed and is sometimes (often?) used for non
COM classes. The second associates a unique identifier with a class
(another facility sorely missing from standard C++) and is also
sometimes used in non COM contexts for things like serialization.
2. A lot of classes that do represent COM interface do not use either
attribute
I repeat: there is NO way for the compiler to detect that a certain C+
+ class is used as a COM interface. If you don't believe me, fine, but
then please explain how exactly it should be done. A solution that
work only in some cases isn't good enough given the amounts of
existing code we are talking about. A solution with false positives
(like the one above) is even worse.
> > Not to mention that saome people do put ctor/dtor in the
> > class/struct representing COM interface just for completeness.
>
> Which is against the definition of interfaces - even if there isn't
> anything like them in C++.
I have no idea what "definition of interface" means to you but to me
in C++ an interface is a pure abstract class. A class in C++ always
has a constructor and destructor even if the user doesn't write them
down. The fact that those are inaccessible to outside code can be
expressed by making them protected. The 100% correct interface today
looks like
class ISomething : public IUnknown
{
public:
virtual unsigned long foo() = 0;
protected:
ISomething()
{}
~ISomething()
{}
};
If you suggest that this code is somehow incorrect C++ then I fail to
understand your reasoning.
Eugene Gershnik
> Eugene Gershnik wrote:
> > [...]
> > Well, yes but this is not the main problem. See below
>
> > [...]
> > Regardless of abstract reasoning whether interfaces should or
> > shouldn't have a destructor there is a backward compatibility problem
> > here.
>
> I don't think that there is much COM code, which doesn't use the
> proprietary COM extensions,
You are wrong. Even ignoring the fact that these extensions do not
uniquely mark a COM interface (explained in more details in reply to
your other post) their widespread use is a fairly recent thing. From
my experience quite a lot of code doesn't use them. And there
definitely exist code that uses them for different purposes.
> therefore the compiler can differentiate
> between COM classes and C++ classes and wouldn't IMHO be affected by the
> discussed C++ destructor changes.
Sorry but it cannot.
--
Eugene
Joshua...@gmail.com
destructors. I understand the problem that making destructors virtual
by default for classes with a virtual function may break existing
code. The argument I do not understand is when several people
mentioned that it should not be done because of the design goal "Don't
pay for what you don't use." I don't understand what penalty there
would be (especially assuming a simple, explicit way to turn it off
for the oddball cases). At most, it's an extra function pointer in the
virtual function table and a do-nothing function, something I'd hardly
call a penalty. The extra couple of bytes is the penalty?
Bo Persson
> Sorry, just a general question to the recent debate in here on
> virtual destructors. I understand the problem that making
> destructors virtual by default for classes with a virtual function
> may break existing code. The argument I do not understand is when
> several people mentioned that it should not be done because of the
> design goal "Don't pay for what you don't use." I don't understand
> what penalty there would be (especially assuming a simple, explicit
> way to turn it off for the oddball cases). At most, it's an extra
> function pointer in the virtual function table and a do-nothing
> function, something I'd hardly call a penalty. The extra couple of
> bytes is the penalty?
No, *silently* breaking existing code is the penalty.
The proposed changes would save some guys in this case:
- a base class has some virtual functions
- the base class has a user defined destructor
- oops, forgot to make the destructor virtual!
- another class derives from the base
- the derived class is dynamically allocated
- it is deleted through a pointer to base
What if I never delete the derived class through a pointer to base (I
hardly ever do)? Then the virtual destructor is totally unneeded -
that's why I didn't add one in the first place, doh! Should the
compiler add one anyway, just in case?
Bo Persson
Razvan Cojocaru
>> you don't usually 'catch(const std::exception* pe)'.
>
> Honestly, I do not see how that is related.
> The recommended way to catch exceptions is by const-reference, which
> still means that your object can actually be of a derived type.
It's related because only by catching something like a pointer to an
exception would it make sense to delete that pointer, hence we don't
usually get into the problem of deleting a derived class object via a
base class pointer, in the case of exceptions.
See also Andrei Alexandrescu's second reply.
--
Razvan Cojocaru
KeyID: 1024D/04CA34DE
Razvan Cojocaru
> have to include destructor at all. If you don't ever use this approach
> - fine, but don't claim that what you do is universal principle of OO.
Repeating oneself a lot usually has no bearing over whether one is able
to succesfully make a point ;-).
> You didn't link any opinion, just some "on the margin" notes from some
> presentation, not even a stand-alone text. It might very well be that
> the author has excellent arguments for your case but you haven't shown
> any. Without them it is just that: an appeal to authority.
Here it is yet another time (hopefully somewhat more detailed
information here):
http://www.research.att.com/~bs/bs_faq2.html#virtual-dtor
The majority of our interlocutors seem to be convinced that it's a neat
rule of thumb, I am sorry I've not managed to convince you as well.
> If you propose changes to the language you need to examine existing
> implementations and your impact on them very, very carefully. As far
> as I know "breaking existing code" is number one reason to reject any
> proposed change.
I would argue that breaking existing _bad_ code would be worth it,
though I remain convinced that the "breakage" would be minimal and
avoidable in this case.
Furthermore, I was merely discussing a problem often occuring in the
real world that makes C++ a pain to use sometimes, trying to answer the
thread-starter. I was not actually "proposing changes to the language"
as I not on the C++ standardization committee.
> Sigh. I can only repeat my suggestion above. Had you followed it you
> would discover that there is nothing nice people at MS can do other
> than disable your proposed extension by default. Which would amount to
> the same thing as being rejected by the standard committee.
See Andre Kaufmann's replies on the subject. Please provide exact links
and possibly relevant quotes from any documentation that you feel
demonstrates that COM would necessarily be broken by the change (perhaps
a small ASCII-art drawing of a messed up vtable in your case?) if you
feel the point has still not been made.
--
Razvan Cojocaru
KeyID: 1024D/04CA34DE
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Andre Kaufmann
> On Aug 11, 3:27 pm, Andre Kaufmann <akfmn...@t-online.de> wrote:
> [...]
>
> This is getting rather platform specific but I hope moderators will
> let this through since at least some of it applies to standard C++.
I think it gets too proprietary too - so I try to be more C++ specific.
> 1. Both these attributes do *not* say that the class they apply to is
> a COM interface. The first one is a nice optimization for any abstract
> [...]
No, but would it make sense for a C++ compiler to make a destructor
automatically virtual if a class has the novtable attribute ?
By the way, C++ already does make functions automatically virtual, if a
hidden function in the base class is changed to a virtual function.
> I repeat: there is NO way for the compiler to detect that a certain C++
> class is used as a COM interface
If the C++ compiler can't detect it, how is the binary compatibility of
the COM - ABI with the other languages and other C++ compilers ensured ?
Or are you just assuming that the VTABLE of a C++ compiler matches with
the proprietary COM specifications ?
> [...]
Interface = Pure abstract means only abstract functions for me - and is
the definition of interfaces in other languages - even no destructor.
Which is not possible in C++.
> has a constructor and destructor even if the user doesn't write them
> down.
Yes, this is why C++ has no "true" interfaces. Would be perhaps a good
idea to add interfaces to C++, because the additional code for the
destructor could be omitted.
> [...]
Alex
> On the other hand in my limited experience the lack of destructors and
> the limitations of generics compared to C++ templates make C# a
> worthwhile alternative to C++ only when you access to the .NET
> libraries is an important advantage.
The main short-term advantage (and long-term disadvantage) of C# (or
Java) is that languages are simpler, available libraries all look and
feel alike and the learning curve is not so steep, so a newcomer gets
to an acceptable level of productivity faster and easier than with C+
+.
As for access to .NET, C++ is the most powerful language for that. See
"C++: The Most Powerful Language for .NET Framework
Programming" ( http://msdn.microsoft.com/en-us/library/ms379617.aspx )
Also, from http://www.research.att.com/~bs/hopl-almost-final.pdf :
"Interestingly, C++ with the C++/CLI extensions is the only language
that provides access to every feature of .Net."
Alex
Sergey P. Derevyago
> What if the exception
>
> class Exception : ExceptionBase {....};
>
> is thrown by:
>
> throw new Exception();
>
> ?
>
See the "Exceptions as smart pointers" thread for the details
http://groups.google.com/group/comp.lang.c++.moderated/msg/66a0c6484460d4ef
--
With all respect, Sergey. http://ders.stml.net/
mailto : ders at skeptik.net
Andre Kaufmann
> On Aug 11, 3:58 pm, Andre Kaufmann <akfmn...@t-online.de> wrote:
>> Eugene Gershnik wrote:
> [...]
Stating it doesn't proof it.
In C++ there is no guarantee of the VTABLE layout, or am I wrong ?
So why should there be a guarantee of a C++ class to have the same
layout as COM specifies ?
> [...]