Oozing poison

[AD]

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:opTexture(const char* nickName)
{
BOOL removed = false;
for (std::vector<texture*>::iterator itr = textures.begin(); itr !=
textures.end()
{
if ( (*itr)->nickName == nickName )
{

 

[Jorgen Grahn]

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:opTexture(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

 

[AD]

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

 

[Alf P. Steinbach]

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

 

[Ian Collins]

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.

 

[AD]

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__

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

 

[John Bokma]

[..]

On 11/01/2012 09:42, AD 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.

That, and the quoting disaster via Google Groups...

 

[Jorgen Grahn]

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

 

[AD]

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]

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!

 

[Victor Bazarov]

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

 

[Nick Keighley]

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.

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

 

[AD]

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]

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

it's also somewhat subjective


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




...and you'll never work again


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]

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

 

[Henrik Faber]

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

 

[Victor Bazarov]

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

 

[Miles Bader]

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

 

[AD]

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.