Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C++ (http://www.velocityreviews.com/forums/f39-c.html)
-   -   Oozing poison (http://www.velocityreviews.com/forums/t807861-oozing-poison.html)

AD 01-10-2012 12:35 PM

Oozing poison
 
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 )
{

Jorgen Grahn 01-10-2012 09:42 PM

Re: Oozing poison
 
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 .

AD 01-11-2012 08:43 AM

Re: Oozing poison
 
On Jan 10, 5:19*pm, Leigh Johnston <le...@i42.co.uk> 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

Alf P. Steinbach 01-11-2012 09:01 AM

Re: Oozing poison
 
On 11.01.2012 09:43, AD wrote:
> On Jan 10, 5:19 pm, Leigh Johnston<le...@i42.co.uk> 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

Ian Collins 01-11-2012 09:09 AM

Re: Oozing poison
 
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<le...@i42.co.uk> 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

AD 01-11-2012 09:42 AM

Re: Oozing poison
 
On Jan 11, 11:09*am, Ian Collins <ian-n...@hotmail.com> 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<le...@i42.co.uk> * 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

John Bokma 01-11-2012 04:08 PM

Re: Oozing poison
 
Leigh Johnston <leigh@i42.co.uk> writes:

[..]

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

--
John Bokma j3b

Blog: http://johnbokma.com/ Perl Consultancy: http://castleamber.com/
Perl for books: http://johnbokma.com/perl/help-in-ex...for-books.html

Jorgen Grahn 01-11-2012 04:50 PM

Re: Oozing poison
 
On Wed, 2012-01-11, AD wrote:
> On Jan 10, 5:19*pm, Leigh Johnston <le...@i42.co.uk> 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 .

AD 01-12-2012 02:04 PM

Re: Oozing poison
 
On Jan 11, 6:50*pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
> On Wed, 2012-01-11, AD wrote:
> > On Jan 10, 5:19*pm, Leigh Johnston <le...@i42.co.uk> 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 01-12-2012 02:08 PM

Re: Oozing poison
 
On Jan 11, 3:36*pm, Leigh Johnston <le...@i42.co.uk> wrote:
> On 11/01/2012 09:42, AD wrote:
>
>
>
>
>
>
>
>
>
> > On Jan 11, 11:09 am, Ian Collins<ian-n...@hotmail.com> *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<le...@i42.co.uk> * * 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 ****" 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!


All times are GMT. The time now is 01:43 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.