Language features
546...@163.com
usefule, and which two features that you think are the most over-rated
or the most misused and why you think so? Thanks very much!
Zara
And if I feel they are seven, like sins?
Most useful: books published, google searchs
Most over-rated: asking moronic questions about the language, asking
stupid questions about language features
Most misused: usenets queries for homeqowrk, usenet queries for tests
Regards
Karl Heinz Buchegger
If your homework asks you to do a newsgroup poll, you
should say so ....
most useful:
beeing able to do addition. (without addition I could not write
a single program)
beeing able to write functions. (without functions I could not write
a single real world program).
most over-rated or most misused:
automatic return 0 in main()
thinking that the NULL macro denotes a pointer
Seriously: This question have the same meaningful answer as the
question: What is the most useful part in a car?
--
Karl Heinz Buchegger
kbuc...@gascad.at
Rolf Magnus
Bob Hairgrove
[I normally don't respond to trolls, but I think there are sensible
answers to these questions, so I hope this isn't an attempt at
trolling...]
Most useful -- without a doubt, polymorphism and encapsulation. These
are features which can be found to some degree in other languages, but
the C++ implementation of these concepts is quite powerful and cannot
be found elsewhere IMHO. Templates and generic programming are almost
equally important, though. But since they came later to C++, I will
say that polymorphism and encapsulation are more important since they
were there from the very beginnings of C++ ("C with classes").
The other question is more difficult to answer. People tend to misuse
just about everything, but this is no fault of the language itself.
And I would say that just about all the features in C++ which are used
at all are certainly important. For example, should we condemn the use
of pointers just because there are people who do not use them
properly? You cannot outlaw the knife just because it is sometimes
used to hurt other people.
However, there are two things which probably not many people use and
might possibly be overrated:
(1) export (for templates). This is a potentially very useful feature,
but hardly any widely-used compiler vendors have implemented it. Many
seem to think that we could therefore get along quite well without it.
I can get along without it, but it would be nice to have for hiding
parts of the template source code. Once there are more compilers which
offer this feature, it will be easier to determine whether it is
actually as useful as those who introduced it seem to think it is.
(2) the <c...> STL headers which put the C runtime functions into the
std namespace. Since the names are almost always in the global
namespace anyway, I think most people just use the <.h> headers for
these (not for any other standard libraries, though...it is important
to remember to use <iostream> instead of <iostream.h>, for example).
--
Bob Hairgrove
NoSpam...@Home.com
Tomasz Sopek Sobkowiak
didn't release you from distributing the source code of templates.
One usefull feature of export template is that you can split source of
you template into .h and .cpp, but this is only organisation of you
code.
Bob Hairgrove
wrote:
>using export template didn't release you from distributing the source code of templates.
Thanks, I didn't know this.
--
Bob Hairgrove
NoSpam...@Home.com
Mike Wahler
"Karl Heinz Buchegger" <kbuc...@gascad.at> wrote in message
news:4368BBEB...@gascad.at...
> 546...@163.com wrote:
> Seriously: This question have the same meaningful answer as the
> question: What is the most useful part in a car?
The back seat, of course. :-)
-Mike
Mike Wahler
<546...@163.com> wrote in message
news:1130936429.4...@f14g2000cwb.googlegroups.com...
> who can tell me which two features in the C++ language are most
> usefule,
That depends entirely upon one's notion
of 'useful', which changes with the purpose
of a program. It could easily be that for
a given program, some other language would
be more useful than C++.
> and which two features that you think are the most over-rated
C++ often gets overrated by those who think its
the best tool for every job. One thing I see rather
often is that folks assume that a C++ program must
use OO features, whether they're applicable or not.
> or the most misused
I've seen almost every feature of C++ misused
at one time or another, especially by those
who don't fully understand the language (I think
at some point everyone has been guilty of this).
> and why you think so?
Because those are my opinions. :-)
>Thanks very much!
You're welcome.
-Mike
Bob Hairgrove
<mkwa...@mkwahler.net> wrote:
>What is the most useful part in a car?
>
>The back seat, of course. :-)
LOL ... good one, Mike!
--
Bob Hairgrove
NoSpam...@Home.com
Rolf Magnus
> export usefull?? Very interesting in fact that using export template
> didn't release you from distributing the source code of templates.
Right. Actually, those two things don't have anything to do with each other.
> One usefull feature of export template is that you can split source of
> you template into .h and .cpp, but this is only organisation of you
> code.
And basically, you can still do that. You just have to #include the .cpp at
the end of the header, which seems strange at first but works well.
tony_i...@yahoo.co.uk
Good to see someone's sensible enough to make the most of a bad
situation. Of course the question only makes any sense in contrast to
other languages, as the most useful things like the ability to accept
input, process it, and generate output are universal.
Myself, I'd agree with polymorphism and abstraction (a slightly wider
term than encapsulation) for useful features.
BTW, Polymorphism is provided in C++ through various compile-time and
run-time mechanisms including templates, the preprocessor, overloading,
function pointers, and virtual functions. It's incorrect to talk of
polymorphism as something distinct from templates and generic
programming: polymorphism is the mechanism of generic programming, and
templates are a mechanism of polymorphism. A test I find useful is
this: polymorphic code must implicitly handle different types. More
concretely, consider whether you could use a mechanism to write a
function that can be called with at least two types of argument, e.g.
"fn(my_int); fn(my_double);".
As for over-hyped and misused, it sounds like someone wanting to vent a
pet peeve. People hype up template metaprogramming, and I'd say that's
the hype is disproportional to the actual amount of usage in real
systems, but not to the importance or potential of introspective
programming techniques. It's a terribly clumsy and inefficient
business though, and C++ has to evolve significantly to capitalise on
the potential.
Difficult to think of something else particularly significant. It's
rare to see people systems benefitting from widespread use of custom
streams (bringing disparate systems into the C++ I/O abstraction), and
ditto for custom allocators, but while this potential may be
underrealised it's again real, and not a candidate for misused.
Another vague candidate is exceptions, which can prove harder to
consistently use safely in multi-threaded code than some would hope. I
gather Stroustrup didn't want to add the protected keyword, and a
perception formed - over the year or so afterwards - in the company
that had insisted on protected, that it was a misguided request. But I
think personally think it's sound. Perhaps backwards compatibility
with C leads to the greatest potentials for misuse, as new C++
programmers may not be sure which facilities are best-practice C++, and
which untype-safe, overly pointer based etc. generally-dangerous C, but
again the net benefits from compatibility with C are overwhelming.
I've also heard some people argue that templates are overhyped: mainly
Java advocates that believe the performance benefits (relative to
virtual functions) are like (the now fashionably derided) premature
optimisations. Java advocate, may also complain that
multiple-inheritance (and associated things like virtual inheritance)
is over-complicated, error prone and less useful than some of the Java
facilities becoming available, like cross-cutting Aspect Oriented
Programming (AOP) code-injection. Personally, I think that argument's
crap too: because there are other ways to achieve similar results, some
more powerful, doesn't mean that multiple inheritance isn't perfectly
adequate and elegant for many applications. An argument may be
advanced that C++ needs to evolve, in this case perhaps as possible
through use of systems such as OpenC++, but it's not a valid rebuttal
of existing functionality.
Cheers,
Tony
peter koch
546...@163.com skrev:
> who can tell me which two features in the C++ language are most
> usefule, and which two features that you think are the most over-rated
> or the most misused and why you think so? Thanks very much!
I'll step in.
Most useful? The one feature in C++ i believe to be most valuable bar
none is the deterministic destruction of objects. This allows you to
use RAII which is an incredible help for writing solid programs.
The whole object oriented stuff with abtractions and polymorphism is of
course invaluable as well.
Most overrated? I do not believe there's such a thing. Perhaps this
goes into my "most misused" category. One useless feature could be that
main without a return corresponds to returning zero (this was pointed
out by one of the other posters here).
Most misused? Perhaps this is in the use of new. I believe Java is one
cause for this problem. Other misuses are excessive try-catch (for
resource-deallocation) and abuse of rtti and dynamic_cast.
/Peter
BigBrian
> run-time mechanisms including templates, the preprocessor, overloading,
> function pointers, and virtual functions. It's incorrect to talk of
> polymorphism as something distinct from templates and generic
> programming:
I most often hear polymorphism in reference to runtime dynamic binding.
In this context, polymorphism doesn't have anything to do with
templates because templates are expanded at compile time. I think
defining what templates provide as some sort of compile time
ploymorphism just makes the term polymorphism confusing to people,
especially those trying to learn the language.
> polymorphism is the mechanism of generic programming, and
> templates are a mechanism of polymorphism.
Maybe I'm just misunderstanding what you're saying. But isn't generic
programming in C++ based on templates and not polymorphism. ( Although
I have heard some Java programmers use the term "generic programming"
to describe code which is based only on polymorphism, but this is
mostly since at the time Java didn't support templates, and all classes
on Java have a common parent class ). I've seen some people refer to
templates as providing compile time polymorphism, but templates don't
have anything to do with run-time behavior.
> A test I find useful is
> this: polymorphic code must implicitly handle different types. More
> concretely, consider whether you could use a mechanism to write a
> function that can be called with at least two types of argument, e.g.
> "fn(my_int); fn(my_double);".
I don't understand what you're getting at. Isn't this just plain
operator overloading ( not polymorphism )?
Thomas J. Gritzan
> I most often hear polymorphism in reference to runtime dynamic binding.
> In this context, polymorphism doesn't have anything to do with
> templates because templates are expanded at compile time. I think
> defining what templates provide as some sort of compile time
> ploymorphism just makes the term polymorphism confusing to people,
> especially those trying to learn the language.
Tony is right.
From Wikipedia:
|In computer science, polymorphism is the idea of allowing the same
|definitions to be used with different types of data (specifically,
|different classes of objects), resulting in more general and abstract
|implementations.
[...]
|A function that can evaluate to and be applied to values of different
|types is known as a polymorphic function.
But also:
|Polymorphism has another view, a dual, called inheritance, which
|describes computer modules as sharing implementation (specifically,
|subclasses inheriting the methods of a superclass).
Thomas
tony_i...@yahoo.co.uk
> In this context, polymorphism doesn't have anything to do with
> templates because templates are expanded at compile time. I think
> defining what templates provide as some sort of compile time
> ploymorphism just makes the term polymorphism confusing to people,
> especially those trying to learn the language.
A silly argument! The term polymorphism means what it means. If you
mean virtual dispatch, then refer to it instead. If it's confusing
newbies, then refer them to a decent book that presents the terms
properly, and don't yourself use the wrong terms.
> > polymorphism is the mechanism of generic programming, and
> > templates are a mechanism of polymorphism.
> Maybe I'm just misunderstanding what you're saying. But isn't generic
> programming in C++ based on templates and not polymorphism.
I'd just finished explaining that polymorphism includes templates!
> ( Although I have heard some Java programmers use the term "generic
> programming" to describe code which is based only on polymorphism,
> but this is mostly since at the time Java didn't support templates, and all classes
> on Java have a common parent class ). I've seen some people refer to
> templates as providing compile time polymorphism, but templates don't
> have anything to do with run-time behavior.
You've really got to get this straight in your head Brian.
Polymorphism is a language feature that allows the same code (such as a
function call) to invoke behaviour appropriate to the type(s) provided.
If Java lacked templates, and therefore Java programmers used the term
"polymorphism" when refering to virtual dispatch, then they'll have to
learn to differentiate template-based polymorphism from run-time
virtual-dispatch based polymorphism in future. It mirrors the way
Java's facilities have led to confusion over the terms serialisation
and externalisation, and consequently many use Java's terminology
instead of the correct computing-science terminology.
> > A test I find useful is
> > this: polymorphic code must implicitly handle different types. More
> > concretely, consider whether you could use a mechanism to write a
> > function that can be called with at least two types of argument, e.g.
> > "fn(my_int); fn(my_double);".
> I don't understand what you're getting at. Isn't this just plain
> operator overloading ( not polymorphism )?
As I said at the top of my post, operator overloading is a form of
polymorphism, but it's certainly not implied by the test I've written.
A preprocessor macro "#define fn(X) (cout << x)" could also satisfy the
above test, as could a "template <typename T> fn(T)", virtual dispatch
through "class my_int : public my_abstract_type; class my_double :
public my_abstract_type; void fn(my_abstract_type&)" etc..
POLYMORPHISM INCLUDES ALL THESE TECHNIQUES, AND IS NOT LIMITED TO
VIRTUAL DISPATCH.
Tony
Tony
BigBrian
> polymorphism,
> VIRTUAL DISPATCH.
( You don't need to yell, I wasn't attacking you or your post. I'm
trying to make sure I have my terms right. )
That's not how most people use the term "polymorhism". Maybe they're
wrong, maybe I'm wrong, that's what I'm trying to find out. You just
making this claim doesn't make it so. I know some people that say
templates provide compile-time polymorphism, but they always include
the "compile-time" part, without it most people would think that you're
talking about what you call "virtual dispatch".
Maybe they're just arrogant and ignorant, but I know some programmers
who would ridicule somebody for refering to operator overloading as
polymorphism.
-Brian
BigBrian
> VIRTUAL DISPATCH.
"The C++ Programming Language", special edition, by Bjarne Stroustrup.
On page 312, he defines polymorphism *only* in terms of dynmic binding
and virtual functions.
On page 347 he continues....
".. what virtual functions provide is called run-time polymorphism, and
what templates offer is called compile-time polymorphism or parametric
polymorphism" ...
But he makes no mention of operator overloading as a type of
polymorphism.
But however, he does say (in regards to virtual functions and
templates), "both allow an algorithm to be expressed once and applied
to a variety of types, (so) people sometimes refer to both as
polymorphic". So, I don't think operator overloading applies here
since the overloaded function is not expressed once, it has to be
explicitly expressed for every overloaded type. ( Templates can be
specialized for certain types, but they don't *have* to be expressed
for every type, so I can see how templates are different ).
Maybe we come up with a single term which can be used to describe every
aspect about programming in general. Kind of like how "The smurf's" (
the cartoon ) used "smurf" for everything. That would make things much
easier.
-Brian
tony_i...@yahoo.co.uk
> On page 312, he defines polymorphism *only* in terms of dynmic binding
> and virtual functions.
I'm not sure if the special edition has the same page numbering, but
I'd guess so, because my 3rd Ed also talks about polymorphism on page
312. What's said is:
Getting "the right" behaviour from Employee's functions
independently of exactly what kind of Employee is actually used is
called polymorphism. A type with virtual functions is called a
polymorphic type. To get polymorphic behaviour in C++, the member
functions called must be virtual and objects must be manipulated
through pointers or references. When manipulating an object directly
(rather than through a pointer or refreence), its exact type is known
by the compiler so that run-time polymorphism is not needed.
Now, you'll notice that the first sentence defines polymorphism as the
getting of "the right" behaviour independently of exact types. It
explicitly doesn't yet descend into run-time polymorphic specific
techniques. "A type with virtual functions is called a polymorphic
type". This is true, but notice that he explicitly doesn't say "A
polymorphic type...", nor "Only a type with virtual functions is called
a polymorphic type". His next sentence is less carefully worded
(paraphrased slightly) "to get polymorphic behaviour member functions
must be virtual...", which is ambiguous, but he is after all in the
context of introducing virtual dispatch. He will have actually meant
that "to get [this type] of polymorphic behaviour member functions must
be virtual...".
If you look at the reasoning you've documented him using:
"both allow an algorithm to be expressed once and applied to a
variety of types, (so) people sometimes refer to both as polymorphic"
You should be able to see why operator overloading and indeed
preprocessor macros are polymorphic mechanisms. Consider that while
you do have to write explicit overloaded functions (no polymorphism
benefit yet), having done so you can have the same code dispatch a call
to whichever function is actually appropriate to the types passed. In
other words, it's the calling code that becomes polymorphic through the
support of the overloaded functions, and not the overloaded functions
themselves. For example, a preprocessor macro may say:
#define FN(X) do { if (!(X)) cerr << "!" #X " " << (X) << endl; }
while (false)
(Yes I know it's not side-effect safe). FN() is however polymorphic as
it can be used on different types of expressions (e.g. FN(my_int);
FN(3.14 * 2); FN("hello");). But in order for FN to provide it's
behaviour, it's actually had to rely on a second source of
source-code-level polymorphism: the operator<< operator being available
for it's argument. Because of the overloaded streaming operators, this
code can be used unchanged for a set of supported types.
As for the distinction you're reaching for between overloading and
templates: templates can be automatically instantiated (preprocessor
macros have a similar benefit), but think back to virtual methods. We
know virtual functions implement a form of polymorphism, and yet you
can only substitute the finite set of classes you've actually bothered
to define. Like overloading, you can extend that set as necessary, but
it's still a manual process.
Anyway, it's not for us to "come up with a single term". The terms
already exist and have well-defined meanings.
For what it's worth, I also know plenty of people who don't understand
these distinctions (and plenty more who do). As you say, some would
and do ridicule people for suggesting that macros or overloading have
so much in common with their beloved OO virtual dispatch. Once or
twice they've been colleagues coming back from interviews sniggering
about the candidate who said otherwise... :-(. Luckily, I've never
been interviewed by someone similarly misinformed.
Cheers,
Tony