C++: The Good and Bad

Discussion in 'C++' started by Kevin Hall, Jan 26, 2007.

  1. Kevin Hall

    Kevin Hall Guest

    C++ is one of my favorite languages to work in. This is because it has
    so many differrent strengths. But there is also a number of blemishes
    in the language -- some could potentially be fixed, others are not
    likely. I wanted to open a discussion on what people think are the
    good and bad things about C++. Here are my lists:

    Good things about C++
    ---------------------
    - multi-paradigm language.
    - const-specifications
    - deterministic destruction
    - semi-strong typed (since there are some implicit conversions allowed)
    - 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.
    - Real multiple inheritance. Again, it's powerful, not evil.
    - templates -- more powerful than generics provided by other languages.
    - partial template specialization.
    - template meta-programming.
    - SFINAE, RAII, CRTP
    - Is portable to more platforms than most other languages. (This is
    due in part to having fewer standard libraries.)


    Bad things about C++
    --------------------
    - Some 'baggage': throw specifications, std::vector<bool>, 'export',
    some C-baggage
    - No true-typedefs; typedefs are really type aliases.
    - A lot of things to learn
    - Due to the way C++ has evolved, some things are more complicated than
    they need to be.
    - Too much undefined behavior.
    - No support for properties.
    - No standard for name mangling.
    - No reflection capabilities.
    - 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.
    - Missing libraries: (though, there are many widely available
    cross-platform libraries that do fill in the gaps)
    * No standardized threading model/library
    * 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.
    * The standard libraries don't cover some very common things, like
    decimal and large-integer types, the ability to handle directory
    structures, etc....
    * No standard way to obtain stack-traces.
     
    Kevin Hall, Jan 26, 2007
    #1
    1. Advertising

  2. Re: The Good and Bad

    Kevin Hall wrote:
    > C++ is one of my favorite languages to work in. This is because it
    > has so many differrent strengths. But there is also a number of
    > blemishes in the language -- some could potentially be fixed, others
    > are not likely. I wanted to open a discussion on what people think
    > are the good and bad things about C++. Here are my lists:
    >
    > Good things about C++
    > ---------------------
    > - multi-paradigm language.
    > - const-specifications
    > - deterministic destruction
    > - 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?

    > - 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.

    > - Real multiple inheritance. Again, it's powerful, not evil.


    Is there any other kind besides "real"? What other multiple inheritance
    can there be?

    > - templates -- more powerful than generics provided by other
    > languages.


    Oops... Did you mean to compare languages here? Read the FAQ.

    > - partial template specialization.
    > - template meta-programming.
    > - SFINAE, RAII, CRTP
    > - 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.

    > Bad things about C++
    > --------------------
    > - 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?

    > - No true-typedefs; typedefs are really type aliases.


    Not sure what you mean here. What "true" typedefs do you need?

    > - 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.

    > - 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.

    > - 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?

    > - No support for properties.


    What do you mean?

    > - No standard for name mangling.


    Why would you need it? C++ is source-code portable. Why would you
    need standard in name mangling?

    > - No reflection capabilities.


    You mean, built-in, right? Well, how much do you need provided for
    you? After all, what are the programmers for?

    > - 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?

    > - Missing libraries: (though, there are many widely available
    > cross-platform libraries that do fill in the gaps)
    > * No standardized threading model/library


    There 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?

    > * 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? 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.

    > * No standard way to obtain stack-traces.


    And why do you need that? Isn't that what the debuggers are for?

    It all sounds like you've lived too much in <insert your interpreted
    language here> land. Snap out of it!

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Jan 27, 2007
    #2
    1. Advertising

  3. Kevin Hall

    Ian Collins Guest

    Re: The Good and Bad

    Victor Bazarov wrote:
    > Kevin Hall wrote:
    >
    >>- No standard for name mangling.

    >
    > Why would you need it? C++ is source-code portable. Why would you
    > need standard in name mangling?
    >

    I can go along with this one, try linking library X built with compiler
    A into an application built with compiler B.

    <OT> As a real example, look at KDE, a great desktop, but if you want to
    build something to link into its libraries, or Qt, you have to use the
    same compiler that was used to build them. </OT>

    --
    Ian Collins.
     
    Ian Collins, Jan 27, 2007
    #3
  4. Kevin Hall

    Kevin Hall Guest

    Re: The Good and Bad

    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/library/yhfk0thd(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&...=0&ct=result&cd=1&q=decimal data 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.
     
    Kevin Hall, Jan 27, 2007
    #4
  5. Kevin Hall

    Pete Becker Guest

    Re: The Good and Bad

    Ian Collins wrote:
    > Victor Bazarov wrote:
    >> Kevin Hall wrote:
    >>
    >>> - No standard for name mangling.

    >> Why would you need it? C++ is source-code portable. Why would you
    >> need standard in name mangling?
    >>

    > I can go along with this one, try linking library X built with compiler
    > A into an application built with compiler B.
    >


    Which is why having different name mangling is good. Unless, of course,
    you also want to standardize object layout. That's a much bigger job.

    --

    -- Pete
    Roundhouse Consulting, Ltd. (www.versatilecoding.com)
    Author of "The Standard C++ Library Extensions: a Tutorial and
    Reference." (www.petebecker.com/tr1book)
     
    Pete Becker, Jan 27, 2007
    #5
  6. Kevin Hall

    Cesar Rabak Guest

    Re: The Good and Bad

    Pete Becker escreveu:
    > Ian Collins wrote:
    >> Victor Bazarov wrote:
    >>> Kevin Hall wrote:
    >>>
    >>>> - No standard for name mangling.
    >>> Why would you need it? C++ is source-code portable. Why would you
    >>> need standard in name mangling?
    >>>

    >> I can go along with this one, try linking library X built with compiler
    >> A into an application built with compiler B.
    >>

    >
    > Which is why having different name mangling is good. Unless, of course,
    > you also want to standardize object layout.
    >

    Yes! Why not?
    > That's a much bigger job.


    But worth of it!
     
    Cesar Rabak, Jan 27, 2007
    #6
  7. Kevin Hall

    Noah Roberts Guest

    Re: The Good and Bad

    Cesar Rabak wrote:
    > Pete Becker escreveu:
    >> Ian Collins wrote:
    >>> Victor Bazarov wrote:
    >>>> Kevin Hall wrote:
    >>>>
    >>>>> - No standard for name mangling.
    >>>> Why would you need it? C++ is source-code portable. Why would you
    >>>> need standard in name mangling?
    >>>>
    >>> I can go along with this one, try linking library X built with compiler
    >>> A into an application built with compiler B.
    >>>

    >>
    >> Which is why having different name mangling is good. Unless, of
    >> course, you also want to standardize object layout.

    > Yes! Why not?


    Because, the C++ standard makes a great point of not standardizing too
    much. If object layout was standardized, beyond the minimum that it is,
    then first of all the standard would become much larger and it would
    take longer to release. Second, and more importantly, if the object
    layout was specified by the standard then that is the object layout
    everyone would have to use...whether it is good for the platform or not.
    With the additional time it would take to specify a standard we would
    have a situation in which we're stuck with an object layout based on
    obsolete understandings and hardware for 20+ years.

    By specifying such details the C++ standard would quickly become rigid
    and unresponsive to change. The language would become obsolete very
    quickly.
     
    Noah Roberts, Jan 27, 2007
    #7
  8. On 27 Jan., 00:55, "Kevin Hall" <> wrote:
    > Bad things about C++

    i would add the fact i can ask whether a definition is defined but
    cant ask if a type is defined ... really nasty and senseless.
     
    .rhavin grobert, Jan 27, 2007
    #8
  9. Kevin Hall

    Grizlyk Guest

    Re: The Good and Bad

    Kevin Hall wrote:
    > C++ is one of my favorite languages to work in. This is because it has
    > so many differrent strengths.


    This is because no other languages in the world, that can be used as C++ and
    because it is easyer to everybody to continue apply old language instead of
    new one.

    > But there is also a number of blemishes
    > in the language -- some could potentially be fixed, others are not
    > likely. I wanted to open a discussion on what people think are the
    > good and bad things about C++.


    C++ has many "holes" and "bad places", and at least ten big of them known
    for me. All of them can be easy eliminated.

    --
    Maksim A Polyanin
     
    Grizlyk, Jan 27, 2007
    #9
  10. Kevin Hall

    Grizlyk Guest

    Re: The Good and Bad

    > C++ has many "holes" and "bad places", and at least ten big of them known
    > for me. All of them can be easy eliminated.


    Ă‘an be easy eliminated by C++ standard and compiler improvements, not by
    programmers.

    --
    Maksim A Polyanin
     
    Grizlyk, Jan 27, 2007
    #10
  11. Kevin Hall

    Cesar Rabak Guest

    Re: The Good and Bad

    Noah Roberts escreveu:
    > Cesar Rabak wrote:
    >> Pete Becker escreveu:

    [snipped]

    >>> Which is why having different name mangling is good. Unless, of
    >>> course, you also want to standardize object layout.

    >> Yes! Why not?

    >
    > Because, the C++ standard makes a great point of not standardizing too
    > much. If object layout was standardized, beyond the minimum that it is,
    > then first of all the standard would become much larger and it would
    > take longer to release.


    Yes this is part of the price to pay.

    > Second, and more importantly, if the object
    > layout was specified by the standard then that is the object layout
    > everyone would have to use...whether it is good for the platform or not.


    Couldn't the standard propose a way of going for a standard per
    platform, then?

    The present status is somewhat more awkward IMNSHO: if you want to have
    any chance to supply a library written in C++ the API has to be in C
    (not C++) due the non existance of an ABI for C++.

    So we get to a funny situation where we have a proposal from the
    Standard intended to foster portability, but that hinders code reuse!

    > With the additional time it would take to specify a standard we would
    > have a situation in which we're stuck with an object layout based on
    > obsolete understandings and hardware for 20+ years.


    Yes. We need to have faster turn around times for the Standard, or this
    argument would be forever a showstopper.

    >
    > By specifying such details the C++ standard would quickly become rigid
    > and unresponsive to change. The language would become obsolete very
    > quickly.


    I don't think I agree totally with this either. Newer architectures are
    hard to come by. From the last issuing of the Standard, how many
    _really_ new architectures have appeared to give statistical substance
    to this argument?

    We still have compiler vendors struggling with some aspects of the
    standard¹, meanwhile a lot of vendors seem to loose interest in C++ and
    produce variants which may already be a signal of the obsolescence you
    mention as a thing to avoid.

    Regards,

    --
    Cesar Rabak


    [1] like the export theme
     
    Cesar Rabak, Jan 27, 2007
    #11
  12. Kevin Hall

    Ian Collins Guest

    Re: The Good and Bad

    Pete Becker wrote:
    > Ian Collins wrote:
    >
    >> Victor Bazarov wrote:
    >>
    >>> Kevin Hall wrote:
    >>>
    >>>> - No standard for name mangling.
    >>>
    >>> Why would you need it? C++ is source-code portable. Why would you
    >>> need standard in name mangling?
    >>>

    >> I can go along with this one, try linking library X built with compiler
    >> A into an application built with compiler B.
    >>

    >
    > Which is why having different name mangling is good. Unless, of course,
    > you also want to standardize object layout. That's a much bigger job.
    >

    C also lacks a standard ABI, but each platform has its own. With C++,
    we don't even have that.

    I guess the only contentious aspect of object layout is the virtual
    dispatch mechanism.

    --
    Ian Collins.
     
    Ian Collins, Jan 27, 2007
    #12
  13. Kevin Hall

    Noah Roberts Guest

    Re: The Good and Bad

    Cesar Rabak wrote:
    > Noah Roberts escreveu:


    >> Second, and more importantly, if the object
    >> layout was specified by the standard then that is the object layout
    >> everyone would have to use...whether it is good for the platform or not.

    >
    > Couldn't the standard propose a way of going for a standard per
    > platform, then?
    >


    You mean per implementation? That's what we have. What you really want
    isn't going to be much, if any, better. You would still have no real
    way to change later if you wanted to.

    > The present status is somewhat more awkward IMNSHO: if you want to have
    > any chance to supply a library written in C++ the API has to be in C
    > (not C++) due the non existance of an ABI for C++.


    There are several standards that do explain methods to interoperate,
    including COM, CORBA, etc... The dll interface is know as well, as is
    ELF on Linux. So any implementation can choose to interoperate with
    other compiler writers in this regard. MinGW can use VC++ dlls and can
    create them.
    >
    > So we get to a funny situation where we have a proposal from the
    > Standard intended to foster portability, but that hinders code reuse!


    If you want something that is going to be super portable, where it's all
    spelled out as you are suggesting, there is C# or Java, among others,
    that answer this requirement. C++ doesn't really need to as it serves a
    different purpose. C++ isn't a really super portable language and is
    meant to foster a more implementation specific coding style. You can
    certainly write portable code, but that isn't the goal of the design of
    the language, nor should it be.
     
    Noah Roberts, Jan 28, 2007
    #13
  14. Kevin Hall

    Greg Herlihy Guest

    Re: The Good and Bad

    On Jan 26, 7:23 pm, Pete Becker <> wrote:
    > Ian Collins wrote:
    > > Victor Bazarov wrote:
    > >> Kevin Hall wrote:

    >
    > >>> - No standard for name mangling.
    > >> Why would you need it? C++ is source-code portable. Why would you
    > >> need standard in name mangling?

    >
    > > I can go along with this one, try linking library X built with compiler
    > > A into an application built with compiler B.Which is why having different name mangling is good. Unless, of course,

    > you also want to standardize object layout. That's a much bigger job.


    Sharing a class interface does not require sharing the class object
    layout as well. Just as long as the class implementation is
    encapsulated within a single binary, the class interface can be
    distributed at will. Clients of this class simply need a pointer to a
    class object (obtained from the class library) and the name and
    parameters of its methods. In particular, clients do not need to know
    anything about how the class is laid out in memory. To its clients, a
    class object pointer is "opaque." In fact, COM employs this very
    strategy in order for software components to interoperate.

    Greg
     
    Greg Herlihy, Jan 28, 2007
    #14
  15. Kevin Hall

    Pete Becker Guest

    Re: The Good and Bad

    Greg Herlihy wrote:
    >
    > On Jan 26, 7:23 pm, Pete Becker <> wrote:
    >> Ian Collins wrote:
    >>> Victor Bazarov wrote:
    >>>> Kevin Hall wrote:
    >>>>> - No standard for name mangling.
    >>>> Why would you need it? C++ is source-code portable. Why would you
    >>>> need standard in name mangling?
    >>> I can go along with this one, try linking library X built with compiler
    >>> A into an application built with compiler B.Which is why having different name mangling is good. Unless, of course,

    >> you also want to standardize object layout. That's a much bigger job.

    >
    > Sharing a class interface does not require sharing the class object
    > layout as well. Just as long as the class implementation is
    > encapsulated within a single binary, the class interface can be
    > distributed at will. Clients of this class simply need a pointer to a
    > class object (obtained from the class library) and the name and
    > parameters of its methods. In particular, clients do not need to know
    > anything about how the class is laid out in memory. To its clients, a
    > class object pointer is "opaque." In fact, COM employs this very
    > strategy in order for software components to interoperate.
    >


    Yup. And COM is a C interface.

    More generally, confining yourself to opaque types puts some fairly
    severe constraints on what those types have to look like to users. No
    inline functions, no compiler-generated member functions, no
    inheritance, no templates. In fact, just about the only benefit from
    providing a C++ interface instead of a C interface is that you can
    overload functions. But since an interface like that is so close to C,
    it's probably better to just write it in C, rather than make it unusable
    to C programmers.

    --

    -- Pete
    Roundhouse Consulting, Ltd. (www.versatilecoding.com)
    Author of "The Standard C++ Library Extensions: a Tutorial and
    Reference." (www.petebecker.com/tr1book)
     
    Pete Becker, Jan 28, 2007
    #15
  16. Kevin Hall

    u.int.32.t Guest

    Re: The Good and Bad

    On Jan 26, 6:03 pm, Ian Collins <> wrote:
    > Victor Bazarov wrote:
    > > Kevin Hall wrote:

    >
    > >>- No standard for name mangling.

    >
    > > Why would you need it? C++ is source-code portable. Why would you
    > > need standard in name mangling?I can go along with this one, try linking library X built with compiler

    > A into an application built with compiler B.


    Lets all this what it is: lack of a standardized ABI for C++. Though I
    *think* someone has developed one for the Linux world, which is better
    than nothing. I think it would be difficult to develop one in general
    for all platforms.

    Windows has COM for this purpose (among others).
     
    u.int.32.t, Jan 28, 2007
    #16
  17. Re: The Good and Bad

    Kevin Hall wrote:
    > Victor Bazarov wrote:
    >> Kevin Hall wrote:
    >>> [...C++: many things are amiss...]

    >> [...Why do they need to be part of the language?...]

    > [...because:...]
    >
    > 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.


    Think of it for a second. Why would you need those things to be
    standardised as part of C++ _language_, when they can happily live
    and be used standardised _outside_ of C++. Use POSIX to explain.

    > [..]


    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Jan 29, 2007
    #17
  18. Kevin Hall

    Guest

    Re: The Good and Bad

    Victor Bazarov wrote:
    > Kevin Hall wrote:
    > > 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.Think of it for a second. Why would you need those things to be

    > standardised as part of C++ _language_, when they can happily live
    > and be used standardised _outside_ of C++. Use POSIX to explain.


    Let's take a look at the current C++ standard. Many parts of the
    standard library:
    * cannot be supported on all platforms
    * but can be happily standardized elsewhere by some other standard
    * yet are common enough operations that they ended up being
    standardized

    One example that pops in my mind is file I/O, standard out, standard
    in, and standard error. There many, many embedded systems that don't
    support any of those. There are also many windowing platforms that do
    not support standard out nor standard error. The C++ compilers on
    many of those systems are very compliant on parts of the standard that
    they can implement though.

    I think that there is a large set of functionality that isn't covered
    by the C++ standard that also happens to fall into the same category.
    Handling and navigating directories is one example. Threading
    primitives (like those found in boost) are another.

    If the C++ standard only covered language syntax and did not provide
    useful libraries, then C++ would not be as good nor as popular
    language as it is today. I just think that the number of useful
    libraries can be expanded. (Incidentally, so does the C++ comittee --
    they have been calling for proposals on XML, Unicode, and several
    other libraries.)

    - Kevin
     
    , Jan 30, 2007
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    0
    Views:
    899
  2. Eric Anderson

    Bad Transform or Bad Engine?

    Eric Anderson, Oct 4, 2005, in forum: XML
    Replies:
    1
    Views:
    380
    Peter Flynn
    Oct 5, 2005
  3. =?Utf-8?B?V2lsbGlhbSBTdWxsaXZhbg==?=

    vs2005 publish website doing bad things, bad things

    =?Utf-8?B?V2lsbGlhbSBTdWxsaXZhbg==?=, Oct 25, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    616
    =?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=
    Oct 25, 2006
  4. Gene

    Re: Bad code or bad compiler?

    Gene, Jun 1, 2008, in forum: C Programming
    Replies:
    3
    Views:
    286
    Barry Schwarz
    Jun 1, 2008
  5. rantingrick
    Replies:
    44
    Views:
    1,248
    Peter Pearson
    Jul 13, 2010
Loading...

Share This Page