Oozing poison

Discussion in 'C++' started by AD, Jan 10, 2012.

  1. AD

    AD Guest

    I kid you not, I found this trash in a real project:

    //Remove texture from the the stack and try to unload from memory
    void resourceManager::popTexture(const char* nickName)
    {
    BOOL removed = false;
    for (std::vector<texture*>::iterator itr = textures.begin(); itr !=
    textures.end();)
    {
    if ( (*itr)->nickName == nickName )
    {
     
    AD, Jan 10, 2012
    #1
    1. Advertising

  2. AD

    Jorgen Grahn Guest

    On Tue, 2012-01-10, AD wrote:
    > I kid you not, I found this trash in a real project:
    >
    > //Remove texture from the the stack and try to unload from memory
    > void resourceManager::popTexture(const char* nickName)
    > {
    > BOOL removed = false;
    > for (std::vector<texture*>::iterator itr = textures.begin(); itr !=
    > textures.end();)
    > {
    > if ( (*itr)->nickName == nickName )
    > {


    I don't see anything unusually bad about it. I assume there's a itr++
    elsewhere, and that texture::nickName is a std::string.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Jan 10, 2012
    #2
    1. Advertising

  3. AD

    AD Guest

    On Jan 10, 5:19 pm, Leigh Johnston <> wrote:
    > On 10/01/2012 12:35, AD wrote:
    >
    > > I kid you not, I found this trash in a real project:

    >
    > > //Remove texture from the the stack and try to unload from memory
    > > void resourceManager::popTexture(const char* nickName)
    > > {
    > >    BOOL removed = false;
    > >    for  (std::vector<texture*>::iterator itr = textures.begin(); itr !=
    > > textures.end();)
    > >    {
    > >            if ( (*itr)->nickName == nickName )
    > >            {

    >
    > If texture::nickName is a std::string I can see nothing wrong with this
    > code snippet.
    >
    > Posting such partial code snippets which lack sufficient context are
    > time wasting at best.
    >


    that's exactly what the person who wrote that piece of code did.
    made assumptions without verifying it wasting my time in the process.
    now for the actual texture class definition:

    typedef struct texture
    {
    texture(TextureInfo *glTexture_, const char *nick) :
    glTexture(glTexture_), nickName(nick)
    {

    }
    const char *nickName;
    TextureInfo *glTexture;
    }texture;

    c++ is trash not only because of the gawd ugly syntax but because of
    the coding style in results in
    the resulting black hole of ungawdly maintenance inflicted on
    unsuspected continued engineers
     
    AD, Jan 11, 2012
    #3
  4. On 11.01.2012 09:43, AD wrote:
    > On Jan 10, 5:19 pm, Leigh Johnston<> wrote:
    >> On 10/01/2012 12:35, AD wrote:
    >>
    >>> I kid you not, I found this trash in a real project:

    >>
    >>> //Remove texture from the the stack and try to unload from memory
    >>> void resourceManager::popTexture(const char* nickName)
    >>> {
    >>> BOOL removed = false;
    >>> for (std::vector<texture*>::iterator itr = textures.begin(); itr !=
    >>> textures.end();)
    >>> {
    >>> if ( (*itr)->nickName == nickName )
    >>> {

    >>
    >> If texture::nickName is a std::string I can see nothing wrong with this
    >> code snippet.
    >>
    >> Posting such partial code snippets which lack sufficient context are
    >> time wasting at best.
    >>

    >
    > that's exactly what the person who wrote that piece of code did.
    > made assumptions without verifying it wasting my time in the process.
    > now for the actual texture class definition:
    >
    > typedef struct texture
    > {
    > texture(TextureInfo *glTexture_, const char *nick) :
    > glTexture(glTexture_), nickName(nick)
    > {
    >
    > }
    > const char *nickName;
    > TextureInfo *glTexture;
    > }texture;


    The author of that code mixed up C and C++. The typedef only makes sense
    in C (but the code will not compile as C). The constructor only makes
    sense in C++ (but the typedef is meaningless in C++).



    > c++ is trash not only because of the gawd ugly syntax but because of
    > the coding style in results in
    > the resulting black hole of ungawdly maintenance inflicted on
    > unsuspected continued engineers


    Let's not condemn a language just because it's used by at least one
    incompetent person.

    And let's not condemn that person for wasting others' time, when we're
    doing the same right here. :)


    Cheers & hth.,

    - Alf
     
    Alf P. Steinbach, Jan 11, 2012
    #4
  5. AD

    Ian Collins Guest

    On 01/11/12 10:01 PM, Alf P. Steinbach wrote:
    > On 11.01.2012 09:43, AD wrote:
    >> On Jan 10, 5:19 pm, Leigh Johnston<> wrote:
    >>> On 10/01/2012 12:35, AD wrote:
    >>>
    >>>> I kid you not, I found this trash in a real project:
    >>>
    >>>> //Remove texture from the the stack and try to unload from memory
    >>>> void resourceManager::popTexture(const char* nickName)
    >>>> {
    >>>> BOOL removed = false;
    >>>> for (std::vector<texture*>::iterator itr = textures.begin(); itr !=
    >>>> textures.end();)
    >>>> {
    >>>> if ( (*itr)->nickName == nickName )
    >>>> {
    >>>
    >>> If texture::nickName is a std::string I can see nothing wrong with this
    >>> code snippet.
    >>>
    >>> Posting such partial code snippets which lack sufficient context are
    >>> time wasting at best.
    >>>

    >>
    >> that's exactly what the person who wrote that piece of code did.
    >> made assumptions without verifying it wasting my time in the process.
    >> now for the actual texture class definition:
    >>
    >> typedef struct texture
    >> {
    >> texture(TextureInfo *glTexture_, const char *nick) :
    >> glTexture(glTexture_), nickName(nick)
    >> {
    >>
    >> }
    >> const char *nickName;
    >> TextureInfo *glTexture;
    >> }texture;

    >
    > The author of that code mixed up C and C++. The typedef only makes sense
    > in C (but the code will not compile as C). The constructor only makes
    > sense in C++ (but the typedef is meaningless in C++).


    Using a type "BOOL" also hints at a confused author.

    --
    Ian Collins
     
    Ian Collins, Jan 11, 2012
    #5
  6. AD

    AD Guest

    On Jan 11, 11:09 am, Ian Collins <> wrote:
    > On 01/11/12 10:01 PM, Alf P. Steinbach wrote:
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > On 11.01.2012 09:43, AD wrote:
    > >> On Jan 10, 5:19 pm, Leigh Johnston<>   wrote:
    > >>> On 10/01/2012 12:35, AD wrote:

    >
    > >>>> I kid you not, I found this trash in a real project:

    >
    > >>>> //Remove texture from the the stack and try to unload from memory
    > >>>> void resourceManager::popTexture(const char* nickName)
    > >>>> {
    > >>>>      BOOL removed = false;
    > >>>>      for  (std::vector<texture*>::iterator itr = textures.begin(); itr !=
    > >>>> textures.end();)
    > >>>>      {
    > >>>>              if ( (*itr)->nickName == nickName )
    > >>>>              {

    >
    > >>> If texture::nickName is a std::string I can see nothing wrong with this
    > >>> code snippet.

    >
    > >>> Posting such partial code snippets which lack sufficient context are
    > >>> time wasting at best.

    >
    > >> that's exactly what the person who wrote that piece of code did.
    > >> made assumptions without verifying it wasting my time in the process.
    > >> now for the actual texture class definition:

    >
    > >> typedef struct texture
    > >> {
    > >>        texture(TextureInfo *glTexture_, const char *nick) :
    > >> glTexture(glTexture_), nickName(nick)
    > >>        {

    >
    > >>        }
    > >>        const char *nickName;
    > >>        TextureInfo *glTexture;
    > >> }texture;

    >
    > > The author of that code mixed up C and C++. The typedef only makes sense


    the only difference is that structs are by default public and clas is
    by default private.
    but i guess this garbage initially started its life as code to be
    "improved" later with c__

    > > in C (but the code will not compile as C). The constructor only makes
    > > sense in C++ (but the typedef is meaningless in C++).

    >
    > Using a type "BOOL" also hints at a confused author.
    >


    yeah, somehow vanilla objective c was not enough for them.
    they just HAD to use objective c++

    with predictable results


    4. Alf P. Steinbach
    View profile
    More options Jan 11, 11:01 am
    On 11.01.2012 09:43, AD wrote:

    - Show quoted text -

    The author of that code mixed up C and C++. The typedef only makes
    sense
    in C (but the code will not compile as C). The constructor only makes
    sense in C++ (but the typedef is meaningless in C++).

    > c++ is trash not only because of the gawd ugly syntax but because of
    > the coding style in results in
    > the resulting black hole of ungawdly maintenance inflicted on
    > unsuspected continued engineers


    Let's not condemn a language just because it's used by at least one
    incompetent person.

    > And let's not condemn that person for wasting others' time,


    yeah, except I see the same pattern over and over and over
    in all c++ garbage that comes my way: the left hand did not know what
    the right one
    was doing with disastrous results (the cretin who wrote this
    had seen fit to use handmade refcounting
    instead of relying on the built in mechanism in NSObject)

    Predictably now another person (me) is faced with underrefs & co
    in that fragile inconsistent p.o.s.

    I'll illustrate the problems with this hack of a language further once
    I get another
    suitable snippet
     
    AD, Jan 11, 2012
    #6
  7. AD

    John Bokma Guest

    John Bokma, Jan 11, 2012
    #7
  8. AD

    Jorgen Grahn Guest

    On Wed, 2012-01-11, AD wrote:
    > On Jan 10, 5:19 pm, Leigh Johnston <> wrote:
    >> On 10/01/2012 12:35, AD wrote:
    >>
    >> > I kid you not, I found this trash in a real project:

    ....
    > c++ is trash not only because of the gawd ugly syntax but because of
    > the coding style in results in
    > the resulting black hole of ungawdly maintenance inflicted on
    > unsuspected continued engineers


    If /that/ example is enough to make you rant & rave on Usenet, you
    probably haven't been doing maintenance programming for very long!

    I've been doing lots of it. Some points:

    - You will see much scarier things than that.

    - Maintenance programming can be both fun and a quick way to
    become a better programmer. I pity the people who write code
    from scratch, test it some, and then hand it over to some
    maintenance organization. They miss out one some very important
    lessons.

    - I seriously doubt that C++ maintenance nightmares are worse
    than Perl, Python or whatever maintenance nightmares.

    My experience is only with C and C++. Of those two, C++ code is
    easier to debug and clean up, because you can lock things up, in
    steps, turning bugs from run-time errors to compile-time ones.

    /Jorgen


    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Jan 11, 2012
    #8
  9. AD

    AD Guest

    On Jan 11, 6:50 pm, Jorgen Grahn <> wrote:
    > On Wed, 2012-01-11, AD wrote:
    > > On Jan 10, 5:19 pm, Leigh Johnston <> wrote:
    > >> On 10/01/2012 12:35, AD wrote:

    >
    > >> > I kid you not, I found this trash in a real project:

    > ...
    > > c++ is trash not only because of the gawd ugly syntax but because of
    > > the coding style in results in
    > > the resulting black hole of ungawdly maintenance inflicted on
    > > unsuspected continued engineers

    >
    > If /that/ example is enough to make you rant & rave on Usenet, you
    > probably haven't been doing maintenance programming for very long!
    >
    > I've been doing lots of it. Some points:
    >
    > - You will see much scarier things than that.
    >
    > - Maintenance programming can be both fun and a quick way to
    >   become a better programmer. I pity the people who write code
    >   from scratch, test it some, and then hand it over to some
    >   maintenance organization.  They miss out one some very important
    >   lessons.
    >
    > - I seriously doubt that C++ maintenance nightmares are worse
    >   than Perl, Python or whatever maintenance nightmares.
    >

    with c like languages you don't have code rot,
    with python my experience is of a write-and-forget variety

    Just Works (tm)

    >   My experience is only with C and C++.  Of those two, C++ code is
    >   easier to debug and clean up, because you can lock things up, in
    >   steps, turning bugs from run-time errors to compile-time ones.
    >


    I'm much happier after stopping c++ coding in favor of c++less
    objective c.
    have to use mm extension only when using c++ frameworks such as
    cocos2d
    but that's pretty much it
     
    AD, Jan 12, 2012
    #9
  10. AD

    AD Guest

    On Jan 11, 3:36 pm, Leigh Johnston <> wrote:
    > On 11/01/2012 09:42, AD wrote:
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > On Jan 11, 11:09 am, Ian Collins<>  wrote:
    > >> On 01/11/12 10:01 PM, Alf P. Steinbach wrote:

    >
    > >>> On 11.01.2012 09:43, AD wrote:
    > >>>> On Jan 10, 5:19 pm, Leigh Johnston<>     wrote:
    > >>>>> On 10/01/2012 12:35, AD wrote:

    >
    > >>>>>> I kid you not, I found this trash in a real project:

    >
    > >>>>>> //Remove texture from the the stack and try to unload from memory
    > >>>>>> void resourceManager::popTexture(const char* nickName)
    > >>>>>> {
    > >>>>>>       BOOL removed = false;
    > >>>>>>       for  (std::vector<texture*>::iterator itr = textures.begin(); itr !=
    > >>>>>> textures.end();)
    > >>>>>>       {
    > >>>>>>               if ( (*itr)->nickName == nickName )
    > >>>>>>               {

    >
    > >>>>> If texture::nickName is a std::string I can see nothing wrong with this
    > >>>>> code snippet.

    >
    > >>>>> Posting such partial code snippets which lack sufficient context are
    > >>>>> time wasting at best.

    >
    > >>>> that's exactly what the person who wrote that piece of code did.
    > >>>> made assumptions without verifying it wasting my time in the process..
    > >>>> now for the actual texture class definition:

    >
    > >>>> typedef struct texture
    > >>>> {
    > >>>>         texture(TextureInfo *glTexture_, const char *nick) :
    > >>>> glTexture(glTexture_), nickName(nick)
    > >>>>         {

    >
    > >>>>         }
    > >>>>         const char *nickName;
    > >>>>         TextureInfo *glTexture;
    > >>>> }texture;

    >
    > >>> The author of that code mixed up C and C++. The typedef only makes sense

    >
    > > the only difference is that structs are by default public and clas is
    > > by default private.
    > > but i guess this garbage initially started its life as code to  be
    > > "improved" later with c__

    >
    > >>> in C (but the code will not compile as C). The constructor only makes
    > >>> sense in C++ (but the typedef is meaningless in C++).

    >
    > >> Using a type "BOOL" also hints at a confused author.

    >
    > > yeah, somehow vanilla objective c was not enough for them.
    > > they just HAD to use objective c++

    >
    > > with predictable results

    >
    > > 4.  Alf P. Steinbach
    > > View profile
    > >     More options Jan 11, 11:01 am
    > > On 11.01.2012 09:43, AD wrote:

    >
    > > - Show quoted text -

    >
    > > The author of that code mixed up C and C++. The typedef only makes
    > > sense
    > > in C (but the code will not compile as C). The constructor only makes
    > > sense in C++ (but the typedef is meaningless in C++).

    >
    > >> c++ is trash not only because of the gawd ugly syntax but because of
    > >> the coding style in results in
    > >> the resulting black hole of ungawdly maintenance inflicted on
    > >> unsuspected continued engineers

    >
    > > Let's not condemn a language just because it's used by at least one
    > > incompetent person.

    >
    > >> And let's not condemn that person for wasting others' time,

    >
    > > yeah, except I see the same pattern over and over and over
    > > in all c++ garbage that comes my way: the left hand did not know what
    > > the right one
    > > was doing with disastrous results (the cretin who wrote this
    > > had seen fit to use handmade refcounting
    > > instead of relying on the built in mechanism in NSObject)

    >
    > > Predictably now another person (me) is faced with underrefs&  co
    > > in that fragile inconsistent p.o.s.

    >
    > > I'll illustrate the problems with this hack of a language further once
    > > I get another
    > > suitable snippet

    >
    > Posting code snippets of colleague's code and then calling said
    > colleague a "cretin" in a public forum such as this is not very
    > professional.


    probably, though as i get older i care much less about being
    "professional"
    and much more about being true. though the evidence of problems swept
    under
    the carpet in the original code does not leave a whole lot of basis to
    reciprocate
    on top of

    integrity is a great trait: try to cultivate that for a while to see
    what I mean

    honesty is another good one. try telling the customer "this feature is
    more
    than you've paid for, moroever it's likely to turn the codebase
    into an unmaintainable piece of shit" next time you are contracted.
    a whole lot of goodwill towards you might be expected on their part.
    if not they are unreasonable iDiots. Next!
     
    AD, Jan 12, 2012
    #10
  11. On 1/12/2012 9:04 AM, AD wrote:
    >[..]
    > I'm much happier after stopping c++ coding in favor of c++less
    > objective c.
    > have to use mm extension only when using c++ frameworks such as
    > cocos2d
    > but that's pretty much it


    So, you're not coding in C++, and you come to a C++ community hangout to
    complain about C++ being difficult to comprehend, and you expect what,
    sympathy? <shrug>

    V
    --
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Jan 12, 2012
    #11
  12. On Jan 12, 2:08 pm, AD <> wrote:
    > On Jan 11, 3:36 pm, Leigh Johnston <> wrote:


    <snip>

    > > Posting code snippets of colleague's code and then calling said
    > > colleague a "cretin" in a public forum such as this is not very
    > > professional.


    it's also somewhat subjective

    > probably, though as i get older i care much less about being
    > "professional" and much more about being true.


    predicates are true, people are correct or honest or tactless. Odd
    most people grow out of atitudes like yours at about 14.

    <snip>

    > integrity is a great trait: try to cultivate that for a while to see
    > what I mean
    >
    > honesty is another good one. try telling the customer "this feature is
    > more
    > than you've paid for, moroever it's likely to turn the codebase
    > into an unmaintainable piece of shit" next time you are contracted.


    ....and you'll never work again

    > a while lot of goodwill towards you might be expected on their part.


    LOL

    > if not they are unreasonable iDiots. Next!


    its possible to critique code without being gratuitously rude. It
    might be more effective as well
     
    Nick Keighley, Jan 13, 2012
    #12
  13. AD

    AD Guest

    On Jan 12, 4:13 pm, Leigh Johnston <> wrote:
    > On 12/01/2012 14:08, AD wrote:
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > On Jan 11, 3:36 pm, Leigh Johnston<>  wrote:
    > >> Posting code snippets of colleague's code and then calling said
    > >> colleague a "cretin" in a public forum such as this is not very
    > >> professional.

    >
    > > probably, though as i get older i care much less about being
    > > "professional"
    > > and much more about being true. though the evidence of problems swept
    > > under
    > > the carpet in the original code does not leave a whole lot of basis to
    > > reciprocate
    > > on top of

    >
    > > integrity is a great trait: try to cultivate that for a while to see
    > > what I mean

    >
    > > honesty is another good one. try telling the customer "this feature is
    > > more
    > > than you've paid for, moroever it's likely to turn the codebase
    > > into an unmaintainable piece of shit" next time you are contracted.
    > > a whole lot of goodwill towards you might be expected on their part.
    > > if not they are unreasonable iDiots. Next!

    >
    > Still no reason to wash the dirty linen in public; you have to consider
    > your company's reputation as well as the customer's.  Be professional


    honesty is far more beneficial for the company reputation than
    "professionalism"

    > and solve such problems in private.
    >

    You still don;t understand, don't you?
    I would not have had this kind of problems in the first place if there
    was no c++ code in that project.
    The whole point of my post is to illustrate how shitty of a language c+
    + is.
    You can not fix that by subtracting from it (though revving it back to
    1.2 or at least 2.0 might
    make it marginally usable again. good luck squeezing toothpaste back
    into the tube)
    and you most certainly can't fixing it by adding more shit into c+
    +--11

    just jettison this hack of the language and move on to an incompatible
    lean and mean offspring.
    the industry will be in a much better shape with that load off the
    chest
     
    AD, Jan 17, 2012
    #13
  14. AD

    AD Guest

    On Jan 12, 5:13 pm, Victor Bazarov <> wrote:
    > On 1/12/2012 9:04 AM, AD wrote:
    >
    > >[..]
    > > I'm much happier after stopping c++ coding in favor of c++less
    > > objective c.
    > > have to use mm extension only when using c++ frameworks such as
    > > cocos2d
    > > but that's pretty much it

    >
    > So, you're not coding in C++, and you come to a C++ community hangout to
    > complain about C++ being difficult to comprehend, and you expect what,
    > sympathy?  <shrug>
    >

    I'm not coding in C++ ANYMORE
    I could not possibly see how it can be used to write robust code

    linux kernel developers at one point tried (and failed),
    primirily because of the buggy g++ frontend to gcc
    and you can really count on your palm c++ compilers that work okay.
    (none on *nix systems)
    most are full of bugs. when you can't predict how many passes you need
    to
    parse code you could just as well scram at that point because
    it's an indication of something horrendouzly wrong with the language

    but more and more leammings nevertheless insist on their journey to
    nowhere
     
    AD, Jan 17, 2012
    #14
  15. AD

    AD Guest

    On Jan 13, 12:18 pm, Nick Keighley <>
    wrote:
    > On Jan 12, 2:08 pm, AD <> wrote:
    >
    > > On Jan 11, 3:36 pm, Leigh Johnston <> wrote:

    >
    > <snip>
    >
    > > > Posting code snippets of colleague's code and then calling said
    > > > colleague a "cretin" in a public forum such as this is not very
    > > > professional.

    >
    > it's also somewhat subjective
    >
    > > probably, though as i get older i care much less about being
    > > "professional" and much more about being true.

    >
    > predicates are true, people are correct or honest or tactless. Odd
    > most people grow out of atitudes like yours at about 14.
    >
    > <snip>
    >
    > > integrity is a great trait: try to cultivate that for a while to see
    > > what I mean

    >
    > > honesty is another good one. try telling the customer "this feature is
    > > more
    > > than you've paid for, moroever it's likely to turn the codebase
    > > into an unmaintainable piece of shit" next time you are contracted.

    >
    > ...and you'll never work again
    >
    > > a while lot of goodwill towards you might be expected on their part.

    >
    > LOL
    >
    > > if not they are unreasonable iDiots. Next!

    >
    > its possible to critique code without being gratuitously rude. It
    > might be more effective as well


    You are right. Efficiency (as well as my well being) being the primary
    concern
    I should remember to multiply my estimates by a coefficient that is
    tied to the amount of
    c++ in the codebase I'm about to inherit

    Thank you!
    bye bye!
     
    AD, Jan 17, 2012
    #15
  16. AD

    AD Guest

    On Jan 10, 11:42 pm, Jorgen Grahn <> wrote:
    > On Tue, 2012-01-10, AD wrote:
    > > I kid you not, I found this trash in a real project:

    >
    > > //Remove texture from the the stack and try to unload from memory
    > > void resourceManager::popTexture(const char* nickName)
    > > {
    > >    BOOL removed = false;
    > >    for  (std::vector<texture*>::iterator itr = textures.begin(); itr !=
    > > textures.end();)
    > >    {
    > >            if ( (*itr)->nickName == nickName )
    > >            {

    >
    > I don't see anything unusually bad about it. I assume there's a itr++
    > elsewhere, and that texture::nickName is a std::string.
    >

    yes, the person who wrote this code had (erroneously) assumed the same
    thing
     
    AD, Jan 17, 2012
    #16
  17. AD

    Henrik Faber Guest

    On 17.01.2012 11:08, AD wrote:

    > You still don;t understand, don't you?
    > I would not have had this kind of problems in the first place if there
    > was no c++ code in that project.


    Right: Because in C, one could not use "==" to compare two char*. Or in
    Python one could not use "is" to compare two strings.

    You, Sir, are an enourmous moron.

    Best regards,
    Henrik
     
    Henrik Faber, Jan 17, 2012
    #17
  18. On 1/17/2012 5:19 AM, AD wrote:
    > On Jan 12, 5:13 pm, Victor Bazarov<> wrote:
    >> On 1/12/2012 9:04 AM, AD wrote:
    >>
    >>> [..]
    >>> I'm much happier after stopping c++ coding in favor of c++less
    >>> objective c.
    >>> have to use mm extension only when using c++ frameworks such as
    >>> cocos2d
    >>> but that's pretty much it

    >>
    >> So, you're not coding in C++, and you come to a C++ community hangout to
    >> complain about C++ being difficult to comprehend, and you expect what,
    >> sympathy?<shrug>
    >>

    > I'm not coding in C++ ANYMORE
    > I could not possibly see how it can be used to write robust code
    >
    > linux kernel developers at one point tried (and failed),
    > primirily because of the buggy g++ frontend to gcc
    > and you can really count on your palm c++ compilers that work okay.
    > (none on *nix systems)
    > most are full of bugs. when you can't predict how many passes you need
    > to
    > parse code you could just as well scram at that point because
    > it's an indication of something horrendouzly wrong with the language
    >
    > but more and more leammings nevertheless insist on their journey to
    > nowhere


    ....and you're standing nearby shouting at them and hoping they're going
    to listen? What are you trying to accomplish? Save the world? Get a
    life. Sounds like you really would like to come back to C++ but since
    you spent too much time already away from it, your grip on it (however
    weak it was before) is slipping even further, and it makes you very
    annoyed, irritated and angry. If it's not for you, give it up, don't
    waste your time. And ours.

    V
    --
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Jan 17, 2012
    #18
  19. AD

    Miles Bader Guest

    AD <> writes:
    >> So, you're not coding in C++, and you come to a C++ community hangout to
    >> complain about C++ being difficult to comprehend, and you expect what,
    >> sympathy?  <shrug>
    >>

    > I'm not coding in C++ ANYMORE
    > I could not possibly see how it can be used to write robust code


    You expect us to trust your judgement?

    [I've found C++ _much_ easier to write robust code in compared to C.
    It is clearly no proof against incompetent coders (nothing is), but it
    does offer some really good tools to help competent ones...]

    -miles

    --
    Bacchus, n. A convenient deity invented by the ancients as an excuse for
    getting drunk.
     
    Miles Bader, Jan 18, 2012
    #19
  20. AD

    AD Guest

    On Jan 18, 6:51 am, Miles Bader <> wrote:
    > AD <> writes:
    > >> So, you're not coding in C++, and you come to a C++ community hangout to
    > >> complain about C++ being difficult to comprehend, and you expect what,
    > >> sympathy?  <shrug>

    >
    > > I'm not coding in C++ ANYMORE
    > > I could not possibly see how it can be used to write robust code

    >
    > You expect us to trust your judgement?
    >
    > [I've found C++ _much_ easier to write robust code in compared to C.
    > It is clearly no proof against incompetent coders (nothing is), but it
    > does offer some really good tools to help competent ones...]
    >

    Well, objective-c (and it's inherent to all c based languages, unless
    you start ripping out pointers, etc) is prone to allowing a single fly-
    idiot
    poisoning the whole barrel, and java like languages
    were designed precisely to keep idiots at bay, but c++ seems to be
    especially
    susceptible to providing morons with tools to automate
    writing some crap code.
     
    AD, Jan 21, 2012
    #20
    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.

Share This Page