Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #13209 > unrolled thread

Oozing poison

Back to article view | Back to comp.lang.c++

Contents

  Oozing poison AD <isquat@gmail.com> - 2012-01-10 04:35 -0800
    Re: Oozing poison Leigh Johnston <leigh@i42.co.uk> - 2012-01-10 15:19 +0000
      Re: Oozing poison AD <isquat@gmail.com> - 2012-01-11 00:43 -0800
        Re: Oozing poison "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2012-01-11 10:01 +0100
          Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-11 22:09 +1300
            Re: Oozing poison AD <isquat@gmail.com> - 2012-01-11 01:42 -0800
              Re: Oozing poison Leigh Johnston <leigh@i42.co.uk> - 2012-01-11 13:36 +0000
                Re: Oozing poison John Bokma <john@castleamber.com> - 2012-01-11 10:08 -0600
                Re: Oozing poison AD <isquat@gmail.com> - 2012-01-12 06:08 -0800
                  Re: Oozing poison Leigh Johnston <leigh@i42.co.uk> - 2012-01-12 14:13 +0000
                    Re: Oozing poison AD <isquat@gmail.com> - 2012-01-17 02:08 -0800
                      Re: Oozing poison Henrik Faber <hfaber@invalid.net> - 2012-01-17 12:50 +0100
                  Re: Oozing poison Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-13 02:18 -0800
                    Re: Oozing poison AD <isquat@gmail.com> - 2012-01-17 02:24 -0800
        Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-11 16:50 +0000
          Re: Oozing poison AD <isquat@gmail.com> - 2012-01-12 06:04 -0800
            Re: Oozing poison Victor Bazarov <v.bazarov@comcast.invalid> - 2012-01-12 10:13 -0500
              Re: Oozing poison AD <isquat@gmail.com> - 2012-01-17 02:19 -0800
                Re: Oozing poison Victor Bazarov <v.bazarov@comcast.invalid> - 2012-01-17 08:04 -0500
                Re: Oozing poison Miles Bader <miles@gnu.org> - 2012-01-18 13:51 +0900
                  Re: Oozing poison AD <isquat@gmail.com> - 2012-01-21 04:40 -0800
                    Re: Oozing poison Quint Rankid <qbr567@gmail.com> - 2012-01-21 09:05 -0800
                      Re: Oozing poison Wil Evers <bouncer@dev.null> - 2012-01-21 18:52 +0000
                        Re: Oozing poison Quint Rankid <qbr567@gmail.com> - 2012-01-21 11:33 -0800
                          Re: Oozing poison AD <isquat@gmail.com> - 2012-01-25 02:23 -0800
                        Re: Oozing poison AD <isquat@gmail.com> - 2012-01-25 02:07 -0800
                          Re: Oozing poison Victor Bazarov <v.bazarov@comcast.invalid> - 2012-01-25 07:59 -0500
                          Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-26 07:54 +1300
                    Re: Oozing poison Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-01-21 22:43 -0500
                      Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-22 21:05 +1300
                        Re: Oozing poison Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-01-22 18:21 -0500
                      Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-23 15:55 +0000
                        Re: Oozing poison gwowen <gwowen@gmail.com> - 2012-01-23 08:37 -0800
                        Re: Oozing poison Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-01-24 22:48 -0500
                          Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-25 19:44 +0000
                          Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-26 08:56 +1300
                            Re: Oozing poison 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-25 23:04 -0800
                              Re: Oozing poison Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-26 03:24 -0800
                                Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-26 19:13 +0000
                                Re: Oozing poison Brian Drummond <brian@shapes.demon.co.uk> - 2012-01-27 00:12 +0000
                                  Re: Oozing poison "MikeWhy" <boat042-nospam@yahoo.com> - 2012-01-26 22:44 -0600
                                Re: Oozing poison 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-28 14:25 -0800
                    Re: Oozing poison Robert Miles <milesrf@Usenet-News.net> - 2012-02-26 22:16 -0600
                Re: Oozing poison "Gernot Frisch" <me@privacy.net> - 2012-01-24 18:21 +0100
                  Re: Oozing poison Victor Bazarov <v.bazarov@comcast.invalid> - 2012-01-24 12:41 -0500
                  Re: Oozing poison Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-26 03:25 -0800
                Re: Oozing poison Rui Maciel <rui.maciel@gmail.com> - 2012-01-25 19:44 +0000
                  Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-26 09:44 +0000
                    Re: Oozing poison Rui Maciel <rui.maciel@gmail.com> - 2012-01-26 10:36 +0000
                      Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-26 19:18 +0000
                      Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-26 20:42 +0000
                  Re: Oozing poison Juha Nieminen <nospam@thanks.invalid> - 2012-01-26 16:30 +0000
                    Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-26 19:24 +0000
                      Re: Oozing poison Cholo Lennon <chololennon@hotmail.com> - 2012-01-26 17:13 -0300
                        Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-26 20:55 +0000
                          Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-26 22:08 +0000
                            Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-27 00:32 +0000
                              Re: Oozing poison Dombo <dombo@disposable.invalid> - 2012-01-28 12:59 +0100
                            Re: Oozing poison Cholo Lennon <chololennon@hotmail.com> - 2012-01-27 18:28 -0300
                              Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-29 18:02 +0000
                          Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-27 20:18 +1300
                            Re: Oozing poison Miles Bader <miles@gnu.org> - 2012-01-27 18:09 +0900
                              Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-27 20:29 +0000
                                Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-28 10:06 +1300
                                  Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-27 21:26 +0000
                                    Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-28 12:22 +1300
                                      Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-28 04:18 +0000
                                        Re: Oozing poison Miles Bader <miles@gnu.org> - 2012-01-28 13:44 +0900
                                          Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-28 21:31 +0000
                                            Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-29 11:32 +1300
                                              Re: Oozing poison 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-28 14:55 -0800
                                                Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-29 11:59 +1300
                                              Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-30 17:08 +0000
                                        Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-28 18:06 +1300
                                          Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-28 22:49 +0000
                                            Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-29 12:22 +1300
                            Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-27 20:16 +0000
                              Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-28 10:01 +1300
                      Re: Oozing poison Juha Nieminen <nospam@thanks.invalid> - 2012-01-28 16:00 +0000
    Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-10 21:42 +0000
      Re: Oozing poison AD <isquat@gmail.com> - 2012-01-17 02:31 -0800

Page 1 of 5  [1] 2 3 4 5  Next page →

#13209 — 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 )
		{

[toc] | [next] | [standalone]

#13210

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.

/Leigh

[toc] | [prev] | [next] | [standalone]

#13234

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

[toc] | [prev] | [next] | [standalone]

#13235

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

[toc] | [prev] | [next] | [standalone]

#13236

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

[toc] | [prev] | [next] | [standalone]

#13237

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

[toc] | [prev] | [next] | [standalone]

#13240

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.

/Leigh

[toc] | [prev] | [next] | [standalone]

#13243

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-exchange-for-books.html

[toc] | [prev] | [next] | [standalone]

#13279

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

[toc] | [prev] | [next] | [standalone]

#13280

On 12/01/2012 14:08, AD wrote:
> On Jan 11, 3:36 pm, Leigh Johnston<le...@i42.co.uk>  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 
and solve such problems in private.

/Leigh

[toc] | [prev] | [next] | [standalone]

#13431

On Jan 12, 4:13 pm, Leigh Johnston <le...@i42.co.uk> wrote:
> On 12/01/2012 14:08, AD wrote:
>
>
>
>
>
>
>
>
>
> > On Jan 11, 3:36 pm, Leigh Johnston<le...@i42.co.uk>  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

[toc] | [prev] | [next] | [standalone]

#13435

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

[toc] | [prev] | [next] | [standalone]

#13320

On Jan 12, 2:08 pm, AD <isq...@gmail.com> wrote:
> On Jan 11, 3:36 pm, Leigh Johnston <le...@i42.co.uk> 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

[toc] | [prev] | [next] | [standalone]

#13433

On Jan 13, 12:18 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On Jan 12, 2:08 pm, AD <isq...@gmail.com> wrote:
>
> > On Jan 11, 3:36 pm, Leigh Johnston <le...@i42.co.uk> 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!

[toc] | [prev] | [next] | [standalone]

#13245

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   .

[toc] | [prev] | [next] | [standalone]

#13278

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

[toc] | [prev] | [next] | [standalone]

#13286

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

[toc] | [prev] | [next] | [standalone]

#13432

On Jan 12, 5:13 pm, Victor Bazarov <v.baza...@comcast.invalid> 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

[toc] | [prev] | [next] | [standalone]

#13438

On 1/17/2012 5:19 AM, AD wrote:
> On Jan 12, 5:13 pm, Victor Bazarov<v.baza...@comcast.invalid>  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

[toc] | [prev] | [next] | [standalone]

#13461

AD <isquat@gmail.com> 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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.c++

csiph-web