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 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#13532

On Jan 18, 6:51 am, Miles Bader <mi...@gnu.org> wrote:
> AD <isq...@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...]
>
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.

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

#13534

On Jan 21, 7:40 am, AD <isq...@gmail.com> wrote:
> On Jan 18, 6:51 am, Miles Bader <mi...@gnu.org> wrote:> AD <isq...@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...]
>
> 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.

I think it would be helpful to know why you are posting to this
group.  Can you please tell me what you hope to accomplish?  I think
this would help those who would like to respond to whatever points
you're trying to make.

If you are simply trying to tell us that you don't like C++, then I
think it is clear that you have done that.  So I tentatively conclude
that you must have some other purpose in mind.  Please share it with
us.

TIA

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

#13535

Quint Rankid wrote:

> On Jan 21, 7:40 am, AD <isq...@gmail.com> wrote:
>> On Jan 18, 6:51 am, Miles Bader <mi...@gnu.org> wrote:> AD <isq...@gmail.com> writes:

>>> [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.
>
> I think it would be helpful to know why you are posting to this
> group.  Can you please tell me what you hope to accomplish?  I think
> this would help those who would like to respond to whatever points
> you're trying to make.

Well, AD, whoever he is, is not alone.  Wasn't it Bjarne himself who
said something like "C makes it easy to shoot yourself in the foot;
C++ makes it harder, but when you do, you blow away your whole leg"?

Personally, I believe that the built-in idiot filter in C++ is a
feature: I've seen it expose quite a few problems before they could
cause any real harm.  The philosophy C++ inherited from C is to
trust the programmer, who is supposed to make an informed, intelligent
choice when it comes to selecting the right tool for the right job.

Of course, that doesn't mix well with a poor management style that is
only capable of focussing on short-term labor costs.

There.  Now that felt good!

- Wil

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

#13536

On Jan 21, 1:52 pm, Wil Evers <boun...@dev.null> wrote:
> Quint Rankid wrote:

> Wasn't it Bjarne himself who
> said something like "C makes it easy to shoot yourself in the foot;
> C++ makes it harder, but when you do, you blow away your whole leg"?

http://www2.research.att.com/~bs/bs_faq.html#really-say-that
"What people tend to miss, is that what I said there about C++ is to a
varying extent true for all powerful languages. As you protect people
from simple dangers, they get themselves into new and less obvious
problems. Someone who avoids the simple problems may simply be heading
for a not-so-simple one. One problem with very supporting and
protective environments is that the hard problems may be discovered
too late or be too hard to remedy once discovered. Also, a rare
problem is harder to find than a frequent one because you don't
suspect it."

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

#13579

On Jan 21, 9:33 pm, Quint Rankid <qbr...@gmail.com> wrote:
> On Jan 21, 1:52 pm, Wil Evers <boun...@dev.null> wrote:
>
> > Quint Rankid wrote:
> > Wasn't it Bjarne himself who
> > said something like "C makes it easy to shoot yourself in the foot;
> > C++ makes it harder, but when you do, you blow away your whole leg"?
>
> http://www2.research.att.com/~bs/bs_faq.html#really-say-that
> "What people tend to miss, is that what I said there about C++ is to a
> varying extent true for all powerful languages. As you protect people
> from simple dangers, they get themselves into new and less obvious
> problems. Someone who avoids the simple problems may simply be heading
> for a not-so-simple one. One problem with very supporting and
> protective environments is that the hard problems may be discovered
> too late or be too hard to remedy once discovered. Also, a rare
> problem is harder to find than a frequent one because you don't
> suspect it."

that's a very blanket and vague statement

he should try to get into senate -> being there is all about
saving face and never utter anything remotely resembling
"yes, i fucked up big time: but look at all the suckers
who followed me in my footsteps!"

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

#13577

On Jan 21, 8:52 pm, Wil Evers <boun...@dev.null> wrote:
> Quint Rankid wrote:
> > On Jan 21, 7:40 am, AD <isq...@gmail.com> wrote:
> >> On Jan 18, 6:51 am, Miles Bader <mi...@gnu.org> wrote:> AD <isq...@gmail.com> writes:
> >>> [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.
>
> > I think it would be helpful to know why you are posting to this
> > group.  Can you please tell me what you hope to accomplish?  I think
> > this would help those who would like to respond to whatever points
> > you're trying to make.
>
> Well, AD, whoever he is, is not alone.  Wasn't it Bjarne himself who
> said something like "C makes it easy to shoot yourself in the foot;
> C++ makes it harder, but when you do, you blow away your whole leg"?
>
> Personally, I believe that the built-in idiot filter in C++ is a
> feature: I've seen it expose quite a few problems before they could
> cause any real harm.  The philosophy C++ inherited from C is to
> trust the programmer, who is supposed to make an informed, intelligent
> choice when it comes to selecting the right tool for the right job.
>
> Of course, that doesn't mix well with a poor management style that is
> only capable of focussing on short-term labor costs.
>

I don't see how you could maintain any reasonable quality of c++
project
even if you keep the team in the git jail and have the subproject
stakeholders
responsible for their parts.
As I said linux kernel dev tried and failed miserably: c++(compilers)
were not as bloated
with features back then.

But I guess I'm preaching here in vain.

---
Some blame the management, some the employees
Everybody knows it's the industrial disease (TM)

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

#13581

On 1/25/2012 5:07 AM, AD wrote:
> [..]
> But I guess I'm preaching here in vain.

Stop preaching then and start doing something useful.  It's *you* who's 
"oozing poison"; the sooner you realize that, the better.

V
-- 
I do not respond to top-posted replies, please don't ask

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

#13583

On 01/25/12 11:07 PM, AD wrote:
>
> I don't see how you could maintain any reasonable quality of c++
> project

Just because you lack the skills to manage a quality C++ project, 
doesn't assume others can't.

> But I guess I'm preaching here in vain.

Preaching in ignorance more like.

-- 
Ian Collins

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

#13537

AD wrote:
> On Jan 18, 6:51 am, Miles Bader<mi...@gnu.org>  wrote:
>> AD<isq...@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...]
>>
> 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.

I guess, everyone's mileage varies. For a change, I am on AD side in this 
C-vs-C++ maintenance/reviewing issue although for different reasons. Reading C++ 
code takes, in my experience, much longer time than C code of equivalent 
complexity because there are on average more (commonly used) meanings for 
identically-looking C++ code than C code. I have already given on this group an 
example that, in C, you pretty much know that f(a) does not change a -- but not 
in C++. Also, something like a+b can mean anything but addition (forget about a 
<< b being always a shift) and getting certainty is prohibitively time-expensive 
(last time I counted, operator<< had some 3 to 4 thousands overloads in my 
organization; add to this potential automatic conversions and you get the picture).

To be on schedule, a reviewer/maintainer needs to assume; but because there are 
always more than one way to skin a cat in C++, any (and I mean *any*) assumption 
one developer will find reasonable will be broken not too often in another 
person's code that the unfortunate first developer has to review.

Writing C++ code is a different story.. I often call C++ code I am getting for 
reviews or maintenance "write-only" because it takes longer to understand what 
some code does (forget about "supposed to do") than to write the equivalent 
code. (yeah, I know there shall be specs that say what code shall do; the only 
thing is, often there are none).

I think that's why I noticed trend about C++ developers (and related managers) 
to switch roles: you code if you can, no matter how high is your level in an 
organization, and leave reviewing to underlings. I think this trend is 
C++-specific, because the situation with Java is opposite, in my experience: 
more senior people commonly review the code. I was too late to catch this trend 
timely; now trying to reposition myself back to writing.. hopefully not 
write-only code.


-Pavel

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

#13540

On 01/22/12 04:43 PM, Pavel wrote:
>
> Writing C++ code is a different story.. I often call C++ code I am getting for
> reviews or maintenance "write-only" because it takes longer to understand what
> some code does (forget about "supposed to do") than to write the equivalent
> code. (yeah, I know there shall be specs that say what code shall do; the only
> thing is, often there are none).

That should be "there shall be tests that so exactly what the code 
does".  I certainly rely on mine when modifying my own code that's more 
than a couple of projects old.

-- 
Ian Collins

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

#13548

Ian Collins wrote:
> On 01/22/12 04:43 PM, Pavel wrote:
>>
>> Writing C++ code is a different story.. I often call C++ code I am getting for
>> reviews or maintenance "write-only" because it takes longer to understand what
>> some code does (forget about "supposed to do") than to write the equivalent
>> code. (yeah, I know there shall be specs that say what code shall do; the only
>> thing is, often there are none).
>
> That should be "there shall be tests that so exactly what the code does". I
> certainly rely on mine when modifying my own code that's more than a couple of
> projects old.
>

Test results can be helpful in understanding some aspects of the code but, 
paroding Murphy laws: "A reliable test of a feature of your current interest is 
always missing". Also, the OP's (and oftentimes mine) issue is that we did not 
write the code (or tests) we need to understand.

-Pavel

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

#13553

On Sun, 2012-01-22, Pavel wrote:
...
> I guess, everyone's mileage varies. For a change, I am on AD side in this 
> C-vs-C++ maintenance/reviewing issue although for different reasons. Reading C++ 
> code takes, in my experience, much longer time than C code of equivalent 
> complexity because there are on average more (commonly used) meanings for 
> identically-looking C++ code than C code. I have already given on this group an 
> example that, in C, you pretty much know that f(a) does not change a -- but not 
> in C++.

I don't see the problem. You review f(A&), and immediately see that it
can modify its apparent argument. So you ask yourself "will this be
obvious in the calling code, based on the name of f and so on?" If the
answer is "no", you fail the code.

> Also, something like a+b can mean anything but addition (forget about a 
> << b being always a shift) and getting certainty is prohibitively time-expensive 

I don't get this part of your complaint. You must review the code with
the types of objects in mind.  In the expression 'a+b' a and b have
certain types, and if you know these and still cannot think of one
reasonable meaning for the expression ... well, that's a reason to
fail the code right there!

(I assume there is no deep interitance hierarchy with run-time
polymorphism involved. I can't read such code, either.)

> (last time I counted, operator<< had some 3 to 4 thousands overloads in my 
> organization; add to this potential automatic conversions and you get the picture).

And how many of these were not on the form ostream << const T& ?
I find it hard to believe that standard stream output can be a problem
in this context.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#13554

On Jan 23, 3:55 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
> On Sun, 2012-01-22, Pavel wrote:
>
> ...
>
> > I guess, everyone's mileage varies. For a change, I am on AD side in this
> > C-vs-C++ maintenance/reviewing issue although for different reasons. Reading C++
> > code takes, in my experience, much longer time than C code of equivalent
> > complexity because there are on average more (commonly used) meanings for
> > identically-looking C++ code than C code. I have already given on this group an
> > example that, in C, you pretty much know that f(a) does not change a -- but not
> > in C++.
>
> I don't see the problem. You review f(A&), and immediately see that it
> can modify its apparent argument. So you ask yourself "will this be
> obvious in the calling code, based on the name of f and so on?" If the
> answer is "no", you fail the code.

quite.


#define f(x) modify_x(&x)

// You can write terrible code in any except Haskell ;)
f(a);

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

#13571

Jorgen Grahn wrote:
> On Sun, 2012-01-22, Pavel wrote:
> ...
>> I guess, everyone's mileage varies. For a change, I am on AD side in this
>> C-vs-C++ maintenance/reviewing issue although for different reasons. Reading C++
>> code takes, in my experience, much longer time than C code of equivalent
>> complexity because there are on average more (commonly used) meanings for
>> identically-looking C++ code than C code. I have already given on this group an
>> example that, in C, you pretty much know that f(a) does not change a -- but not
>> in C++.
>
> I don't see the problem. You review f(A&), and immediately see that it
> can modify its apparent argument. So you ask yourself "will this be
> obvious in the calling code, based on the name of f and so on?" If the
> answer is "no", you fail the code.
Even letting alone that failing all such code you encounter prevents you from 
staying on schedule:

If you do not review but maintain it as in OP case -- what do you do then?

>
>> Also, something like a+b can mean anything but addition (forget about a
>> <<  b being always a shift) and getting certainty is prohibitively time-expensive
>
> I don't get this part of your complaint. You must review the code with
> the types of objects in mind.  In the expression 'a+b' a and b have
> certain types, and if you know these and still cannot think of one
> reasonable meaning for the expression ... well, that's a reason to
> fail the code right there!
Same question as above.

>
> (I assume there is no deep interitance hierarchy with run-time
> polymorphism involved. I can't read such code, either.)
>
>> (last time I counted, operator<<  had some 3 to 4 thousands overloads in my
>> organization; add to this potential automatic conversions and you get the picture).
>
> And how many of these were not on the form ostream<<  const T&  ?
More than a half. People create other classes than standard streams, most of 
them having stream-like (but not quite) semantics, for example for IPC purpose, 
some with different semantics. An example of the issue is that something like 
somestream << "abc" can lead to very different serializations for different 
types of the stream depending on whether there is an operator<< with const char 
* or some conversion is to be called. And of course it is not clear from the 
call site whether such operator is defined (sometimes it matters, too, whether 
it is defined as a member of the stream-like class or free-standing function).

> I find it hard to believe that standard stream output can be a problem
> in this context.
Well, believe it or not, it takes more time, sometimes many times so, to read 
this code with complete understanding of whether there is bug there (let alone 
what exactly will be in the output) even for ostream-like first arguments (which 
is, as I mentioned earlier, is not always the case) than something printf-like 
and this is a problem.

>
> /Jorgen
>

-Pavel

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

#13585

On Wed, 2012-01-25, Pavel wrote:
> Jorgen Grahn wrote:
>> On Sun, 2012-01-22, Pavel wrote:
>> ...
>>> I guess, everyone's mileage varies. For a change, I am on AD side in this
>>> C-vs-C++ maintenance/reviewing issue although for different reasons. Reading C++
>>> code takes, in my experience, much longer time than C code of equivalent
>>> complexity because there are on average more (commonly used) meanings for
>>> identically-looking C++ code than C code. I have already given on this group an
>>> example that, in C, you pretty much know that f(a) does not change a -- but not
>>> in C++.
>>
>> I don't see the problem. You review f(A&), and immediately see that it
>> can modify its apparent argument. So you ask yourself "will this be
>> obvious in the calling code, based on the name of f and so on?" If the
>> answer is "no", you fail the code.

> Even letting alone that failing all such code you encounter prevents you from 
> staying on schedule:
>
> If you do not review but maintain it as in OP case -- what do you do then?

I commented only on your claims about the difficulty of reviewing C++
code (and I seem to have missed that you talked about "reviewing and
maintenance").

I still don't see your argument about reviewing though. If it really
was "it's hard to usefully review changes in code which is already
unreadable" then that's trivially true in any language.

(I decline to discuss the "maintenance" part, not because I agree with
you but because I cannot come up with brief, good arguments at the
moment.)

...
>>> (last time I counted, operator<<  had some 3 to 4 thousands overloads in my
>>> organization; add to this potential automatic conversions and you get the picture).
>>
>> And how many of these were not on the form ostream<<  const T&  ?
> More than a half. People create other classes than standard streams, most of 
> them having stream-like (but not quite) semantics, for example for IPC purpose, 
> some with different semantics.

That's a bit unusual, and I don't think I would like it.

> An example of the issue is that something like 
> somestream << "abc" can lead to very different serializations for different 
> types of the stream depending on whether there is an operator<< with const char 
> * or some conversion is to be called.

You mentioned these conversions in your earlier posting, too. If you
have a lot those, you have my sympathies. My basic assumption is that
a Foo::Foo(T) which isn't marked 'explicit' is broken.  Same with
function overloads with very similar types.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#13586

On 01/25/12 04:48 PM, Pavel wrote:
> Jorgen Grahn wrote:
>> On Sun, 2012-01-22, Pavel wrote:
>> ...
>>> I guess, everyone's mileage varies. For a change, I am on AD side in this
>>> C-vs-C++ maintenance/reviewing issue although for different reasons. Reading C++
>>> code takes, in my experience, much longer time than C code of equivalent
>>> complexity because there are on average more (commonly used) meanings for
>>> identically-looking C++ code than C code. I have already given on this group an
>>> example that, in C, you pretty much know that f(a) does not change a -- but not
>>> in C++.
>>
>> I don't see the problem. You review f(A&), and immediately see that it
>> can modify its apparent argument. So you ask yourself "will this be
>> obvious in the calling code, based on the name of f and so on?" If the
>> answer is "no", you fail the code.

> Even letting alone that failing all such code you encounter prevents you from
> staying on schedule:

It sounds to me like you have a process problem rather than a language 
one.  I don't thank anyone can do a thorough job of reviewing anything 
other than small sections of unfamiliar code without the involvement of 
the authour or someone else familiar with the code.

-- 
Ian Collins

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

#13587

Programming in C++ code costs more to maintain. Maybe this is good for offering 
more programming positions for the employees. Also problems in C are inherited 
in C++ such as the non-closure integer arithmetics and the lousy sort trap
and the famous non-checking for array boundaries in any read/write. 
The vetctor part just covers up some traps but it slows down as expected. 
The operator reloading and the copy constructor  part of derived classes introduce
more problems  in any operation that needs a new object in the RHS to be 
assigned to the LHS. Of course there are people using C++ without deriving 
new classses and just use those libraries in trivial programs. 
Then in this cas C++ is easy to mantain.   
  

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

#13590

On Jan 26, 7:04 am, 88888 Dihedral <dihedral88...@googlemail.com>
wrote:

> Programming in C++ code costs more to maintain.

I've seen some pretty nasty C

> Maybe this is good for offering
> more programming positions for the employees. Also problems in C are inherited
> in C++ such as the non-closure integer arithmetics and the lousy sort trap

the what?

> and the famous non-checking for array boundaries in any read/write.
> The vetctor part just covers up some traps but it slows down as expected.

what language avoids this? If you do array bound checking it costs. If
you don't then you run a risk. Are there languages that can prove
array bounds won't be breeched?

> The operator reloading and the copy constructor  part of derived classes introduce
> more problems  in any operation that needs a new object in the RHS to be
> assigned to the LHS.

could you expand on that; I didn't quite follow you. I don't recall
encountering a problem in this area.

> Of course there are people using C++ without deriving
> new classses and just use those libraries in trivial programs.
> Then in this cas C++ is easy to mantain.

...and isn't really C++

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

#13593

Nick Keighley <nick_keighley_nospam@hotmail.com> writes:
>On Jan 26, 7:04=A0am, 88888 Dihedral <dihedral88...@googlemail.com>
>wrote:
>
>> Programming in C++ code costs more to maintain.
>
>I've seen some pretty nasty C
>
>> Maybe this is good for offering
>> more programming positions for the employees. Also problems in C are inhe=
>rited
>> in C++ such as the non-closure integer arithmetics and the lousy sort tra=
>p
>
>the what?
>
>> and the famous non-checking for array boundaries in any read/write.
>> The vetctor part just covers up some traps but it slows down as expected.
>
>what language avoids this? If you do array bound checking it costs. If
>you don't then you run a risk. Are there languages that can prove
>array bounds won't be breeched?

Sure.   ALGOL on various Unisys boxen, for instance.

There are still in existence processor architectures that bounds-check
each and every array reference (e.g. capability-based stack architectures such
as the Burroughs Large Systems/Unisys A-series/Clearpath).

On the other hand, the x86 'BOUND instruction was removed from the instruction
set by AMD when they developed the 64-bit extensions.

scott

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

#13602

On Thu, 26 Jan 2012 03:24:11 -0800, Nick Keighley wrote:

> On Jan 26, 7:04 am, 88888 Dihedral <dihedral88...@googlemail.com> wrote:
> 
>> Programming in C++ code costs more to maintain.
> 
> I've seen some pretty nasty C

They are both pretty bad.

>> and the famous non-checking for array boundaries in any read/write. The
>> vetctor part just covers up some traps but it slows down as expected.
> 
> what language avoids this? If you do array bound checking it costs. If
> you don't then you run a risk. Are there languages that can prove array
> bounds won't be breeched?

There certainly are. 
But array bound checks rarely cost anything. If your compiler can't prove 
and eliminate the bulk of them at compile time, get a better compiler.
Help it by defining a new integer type restricted to the size of the 
array (even where the array size is only known at runtime) and using that 
type for the index.
The remaining few checks cost, but you would have to write the same 
checks by hand in C, so they don't cost extra, they just save programmer 
time. 

Anyone with even a little sympathy for "AD"'s position, or interest in 
writing readable, maintainable, safe code would find it worthwhile to try 
Ada 2005. It's available in any decent gcc installation.

Where you really need to eliminate all run time checks and prove all 
bounds at or before compile time, use SPARK instead.

This is off topic on c.l.c++ but you did ask.

- Brian

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

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

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

csiph-web