Victor Bazarov wrote:
> Kevin Hall wrote:
> > - semi-strong typed (since there are some implicit conversions
> > allowed)Is that a good thing?
> If it is, why is "semi-" a good thing? Would
> plain strong typing with all conversions explicit be a better thing?
There are some implicit conversions which are OK (integer to double
conversion for example). But I appreciate the strong typing elsewhere.
> > - preprocessor -- it's powerful not evil. Powerful things just often
> > can be used for evil purposes -- and unfortunately, the preprocessor
> > sometimes is used in evil ways.
> I don't believe the preprocessor is powerful enough.
Yes, it can be more powerful. C99 brings a tiny bit more power. But
something more powerful that is standardized would be nice.
> > - Real multiple inheritance. Again, it's powerful, not evil.
> Is there any other kind besides "real"? What other multiple inheritance
> can there be?
Yes, there are many people that say inheriting multiple interfaces is a
type of MI and is good enough (some even say it's better). I disagree.
> > - templates -- more powerful than generics provided by other
> > languages.
> Oops... Did you mean to compare languages here? Read the FAQ.
Not in the sense of 'what is better -- language X or C++'. But if
something can be learned from features implemented in other languages,
then so be it. (Besides, there is no 'official' FAQ for this
unmoderated group -- despite what some FAQs claim. This was discussed
not too long ago in this forum.)
> > - Is portable to more platforms than most other languages. (This is
> > due in part to having fewer standard libraries.)Not only libraries.
> Absence of explicitly sized types plays big part in that too.
True. C99's <stdint.h> will help a little bit when C++0x standardizes
C++'s use of it.
> > - Some 'baggage': throw specifications, std::vector<bool>, 'export',
> > some C-baggage
> Hos is C baggage a bad thing? Have you any idea how much code was
> possible to simply bring over, compile and never worry?
Please note that I said 'some' -- not all. I think that backwards
compatibility with C is a wonderful thing. But as we all know, C++ is
not 100% compatible with C. '\0' is a char in C++, whereas it is a int
in C.
Anyway, I'm having trouble thinking of the examples of the top of my
head, but there are some things inherited from C that are more vexing
(to me anyway) than if that compatibility had been dropped.
> > - No true-typedefs; typedefs are really type aliases.
> Not sure what you mean here. What "true" typedefs do you need?
"true typedefs" means that a typedef and its base type are different
types in the language type-system. In otherwords: 'bar Foo(bar);' and
'int Foo(int);' describe two different functions if bar is typedef'ed
as an int.
There are many articles online and parts of books written about "true"
typedefs. Here's one online reference (look halfway down the page):
http://www.artima.com/cppsource/typesafety3.html
> > - A lot of things to learn
> You don't need a lot of things to learn. See advantage #1, you only
> need to learn what you're going to apply.
True.
> > - Due to the way C++ has evolved, some things are more complicated
> > than they need to be.
>
> Like what? Keep in mind the need to provide backward compatibility.
I understand backward compatibility is a good thing. Nevertheless,
there are downsides to it too. std::vector<bool>. is one such example.
As far as I can tell, it was known before the standard was finally
released that std::vector<bool> could not fully act like a container,
but it was kept anyway. And if you really need a genuine vector of
booleans then you have to jump through hoops to get one.
> > - Too much undefined behavior.
> What would you do instead? Define it and limit the chances for
> optimizers to work, or define it and limit the number of platforms
> C++ would be possible to implement on?
I said 'too much', not 'C++ has UB'. Even people on the standards
comittee and other people commonly held up as C++ experts like
Alexandrescu say there is *too much* UB.
I don't argue that some UB is needed.
> > - No support for properties.
> What do you mean?
See MS's __declspec(property):
http://msdn2.microsoft.com/en-us/lib...hd(VS.80).aspx
Again, there are many articles and chapters of books written on how to
simulate properties to C++.
> > - No standard for name mangling.
> Why would you need it? C++ is source-code portable. Why would you
> need standard in name mangling?
To support inter-compiler libraries, a standard way for other languages
to tap into C++'s APIs. Other languages usually can only tap into
functions declared as 'extern "C"'. If there were a standard for name
mangling, then it would be easier to tap into C++ interfaces.
> > - No reflection capabilities.
> You mean, built-in, right? Well, how much do you need provided for
> you? After all, what are the programmers for?
Yes, I meant built-in. Reflection would make some things a lot easier
-- for example finding the names of enumeration values.
> > - No garbage collection. Though, GC is often used incorrectly like
> > the preprocessor and multiple-inheritance. Also note that there are
> > GC libraries for C++ -- but there are potentially some advantages to
> > be gained if GC were added to the language.
> Like what, for example?
COW strings (and other COW objects) would be easier to implement.
> > - Missing libraries: (though, there are many widely available
> > cross-platform libraries that do fill in the gaps)
> > * No standardized threading model/libraryThere isn't any across as many platforms as C++ covers.
>
> > * No standard GUI library. However, we should note that standard
> > GUI's are typically not used for state-of-the-art, fancy looking apps.
> > The Java standard doesn't support the newest GUI features of OSX,
> > Windows Vista, OpenGL, or DirectX.
> Again, it would only be applicable to a very few platforms. Why
> would you want to define something that cannot be used everywhere
> where the language can be used?
There are advantages to defining something that can't be used
everywhere. If you need to do something, and that something is
available, then there is a standard way to use it. The POSIX standard
is very popular, but it can't be used everywhere.
Some other languages have thrived on having standard GUIs -- even
though the look and feel of those GUIs seem quite dated.
> > * The standard libraries don't cover some very common things, like
> > decimal and large-integer types, the ability to handle directory
> > structures, etc....
> What's a decimal type?
http://www.google.com/search?hl=en&p...a+type&spell=1.
> Large-integer types are platform-specific,
> and C++ doesn't prohibit their existence. Most implementations have
> some additional types provided, and they work just fine. Making
> those part of the language is simply impossible without sacrificing
> the ability of the compilers to do what they need to optimize the
> programs.
Why would it sacrifice the ability of compiler to do what they need to
optimize the programs?
std::complex<> was standardized. The STL was standardized. Why can't
we have a large integer template?
> > * No standard way to obtain stack-traces.
> And why do you need that? Isn't that what the debuggers are for?
*sigh*... stack-traces are very useful for logging in applications that
are released to customers. When attached to exceptions, they are also
very useful in tracking down intermittent errors customers experience.
Similar Threads
