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

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

Methods for understanding complex, real world, C++ code?

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

Contents

  Methods for understanding complex, real world,  C++ code? mathog <dmathog@gmail.com> - 2012-04-10 08:54 -0700
    Re: Methods for understanding complex, real world, C++ code? "K. Frank" <kfrank29.c@gmail.com> - 2012-04-10 12:55 -0700
      Re: Methods for understanding complex, real world, C++ code? Noah Roberts <roberts.noah@gmail.com> - 2012-04-11 09:23 -0700
        Writing extensions, like VBA "macros", Perl or JavaScript.  @Jeff-Relf.Me - 2012-04-11 11:22 -0700
        Re: Methods for understanding complex, real world, C++ code? Lynn McGuire <lmc@winsim.com> - 2012-04-11 14:35 -0500
        Re: Methods for understanding complex, real world, C++ code? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-04-11 21:53 +0000
          Re: Methods for understanding complex, real world, C++ code? mathog <dmathog@gmail.com> - 2012-04-12 12:01 -0700
        Re: Methods for understanding complex, real world, C++ code? "K. Frank" <kfrank29.c@gmail.com> - 2012-04-11 16:06 -0700
        Re: Methods for understanding complex, real world, C++ code? Christopher Pisz <someone@somewhere.net> - 2012-04-12 11:46 -0500
        Re: Methods for understanding complex, real world, C++ code? Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-04-12 22:32 -0400
          Re: Methods for understanding complex, real world, C++ code? nick_keighley_nospam@hotmail.com - 2012-04-13 02:16 -0700
            Re: Methods for understanding complex, real world, C++ code? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-04-15 10:21 +0000
              Re: Methods for understanding complex, real world, C++ code? Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-04-15 19:33 -0400
                Re: Methods for understanding complex, real world, C++ code? Miles Bader <miles@gnu.org> - 2012-04-16 09:59 +0900
                  Re: Methods for understanding complex, real world, C++ code? Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-04-15 21:32 -0400
                    Re: Methods for understanding complex, real world, C++ code? Miles Bader <miles@gnu.org> - 2012-04-17 09:32 +0900
                      Re: Methods for understanding complex, real world, C++ code? scott@slp53.sl.home (Scott Lurndal) - 2012-04-17 02:06 +0000
                        Re: Methods for understanding complex, real world, C++ code? Miles Bader <miles@gnu.org> - 2012-04-17 11:35 +0900
                        Re: Methods for understanding complex, real world, C++ code? Ian Collins <ian-news@hotmail.com> - 2012-04-17 16:06 +1200
                          Re: Methods for understanding complex, real world, C++ code? scott@slp53.sl.home (Scott Lurndal) - 2012-04-17 15:24 +0000
                            Re: Methods for understanding complex, real world, C++ code? Miles Bader <miles@gnu.org> - 2012-04-18 04:50 +0900
                              Re: Methods for understanding complex, real world, C++ code? scott@slp53.sl.home (Scott Lurndal) - 2012-04-17 20:18 +0000
                                Re: Methods for understanding complex, real world, C++ code? Miles Bader <miles@gnu.org> - 2012-04-18 10:31 +0900
                                  Re: Methods for understanding complex, real world, C++ code? scott@slp53.sl.home (Scott Lurndal) - 2012-04-18 01:36 +0000
                                    Re: Methods for understanding complex, real world, C++ code? Miles Bader <miles@gnu.org> - 2012-04-18 11:00 +0900
                      Re: Methods for understanding complex, real world, C++ code? Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-04-18 22:09 -0400
                        Re: Methods for understanding complex, real world, C++ code? Miles Bader <miles@gnu.org> - 2012-04-19 11:41 +0900
                          Re: Methods for understanding complex, real world, C++ code? Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-04-18 23:04 -0400
                            Re: Methods for understanding complex, real world, C++ code? Miles Bader <miles@gnu.org> - 2012-04-19 13:33 +0900
                        Re: Methods for understanding complex, real world, C++ code? Ian Collins <ian-news@hotmail.com> - 2012-04-19 15:56 +1200
                          Re: Methods for understanding complex, real world, C++ code? Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-04-19 22:54 -0400
                            Re: Methods for understanding complex, real world, C++ code? Miles Bader <miles@gnu.org> - 2012-04-20 14:31 +0900
                Re: Methods for understanding complex, real world, C++ code? Tobias Müller <troplin@bluewin.ch> - 2012-04-16 06:39 +0000
                  Re: Methods for understanding complex, real world, C++ code? Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-04-18 22:25 -0400
                    Re: Methods for understanding complex, real world, C++ code? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-04-19 13:58 +0000
                      Re: Methods for understanding complex, real world, C++ code? Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-04-19 23:39 -0400
                        Re: Methods for understanding complex, real world, C++ code? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-04-22 16:37 +0000
                    Re: Methods for understanding complex, real world, C++ code? Dombo <dombo@disposable.invalid> - 2012-04-19 23:20 +0200
                      Re: Methods for understanding complex, real world, C++ code? Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-04-19 23:54 -0400
                Re: Methods for understanding complex, real world, C++ code? nick_keighley_nospam@hotmail.com - 2012-04-17 03:50 -0700
                  Re: Methods for understanding complex, real world, C++ code? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-04-17 12:01 +0000
    Re: Methods for understanding complex, real world,  C++ code? Ian Collins <ian-news@hotmail.com> - 2012-04-11 08:04 +1200
    Re: Methods for understanding complex, real world,  C++ code? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-04-10 22:26 +0000
      Rewrite it.  @Jeff-Relf.Me - 2012-04-10 16:31 -0700
        Re: Rewrite it.  nick_keighley_nospam@hotmail.com - 2012-04-11 01:20 -0700
          Re: Rewrite it.  Rui Maciel <rui.maciel@gmail.com> - 2012-04-11 10:06 +0100
            Re: Rewrite it.  nick_keighley_nospam@hotmail.com - 2012-04-11 03:45 -0700
              Building a "house" that you can live in for decades to come.  @Jeff-Relf.Me - 2012-04-11 08:52 -0700
                Re: Building a "house" that you can live in for decades to come.  Miles Bader <miles@gnu.org> - 2012-04-12 13:19 +0900
      Re: Methods for understanding complex, real world, C++ code? "K. Frank" <kfrank29.c@gmail.com> - 2012-04-10 17:37 -0700
        Re: Methods for understanding complex, real world, C++ code? Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-04-12 21:40 -0400
    Re: Methods for understanding complex, real world,  C++ code? michael.boehnisch@gmail.com - 2012-04-10 17:29 -0700
      Re: Methods for understanding complex, real world,  C++ code? Rui Maciel <rui.maciel@gmail.com> - 2012-04-11 10:02 +0100
    Re: Methods for understanding complex, real world,  C++ code? jgk@panix.com (Joe keane) - 2012-04-11 22:36 +0000
      Re: Methods for understanding complex, real world, C++ code? Noah Roberts <roberts.noah@gmail.com> - 2012-04-11 16:05 -0700
        Re: Methods for understanding complex, real world, C++ code? Robert Wessel <robertwessel2@yahoo.com> - 2012-04-11 19:37 -0500
    Re: Methods for understanding complex, real world,  C++ code? Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-04-12 21:48 -0400
      Re: Methods for understanding complex, real world,  C++ code? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-04-15 09:56 +0000
        Re: Methods for understanding complex, real world,  C++ code? Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-04-15 19:43 -0400

Page 3 of 3 — ← Prev page 1 2 [3]

#15426 — Re: Methods for understanding complex, real world, C++ code?

On Tue, 2012-04-17, nick_keighley_nospam@hotmail.com wrote:
> On Monday, April 16, 2012 12:33:44 AM UTC+1, Pavel wrote:
>> Jorgen Grahn wrote:
>> > On Fri, 2012-04-13, nick_keighley_nospam@hotmail.com wrote:
>> >> On Friday, April 13, 2012 3:32:59 AM UTC+1, Pavel wrote:
>
> <snip>
>
>> >>> the following is not even technical at all:
>> >>>
>> >>> - Try to gain friends, not enemies, among your co-workers. Explain your
>> >>> ideas.
>> >>> Take other people's ideas 
>
> I'll do that. And for the sake of quiet life I may use something that I think could be better. but...
>
>> >>> (sometimes do it even if you believe their
>> >>> ideas have no technical merit)
>
> ...I simply couldn't do this. How could you put something in your code
> that had /no/ technical merit!
>
>> >> sorry I'm too Geek to even *think* this! I'd rather saw my own head
>> >> off. Friends? Friends!? we're computer programmers we don't have no
>> >> stinking friends!
>> >
>> > Either there are no morons in your workplace, you're deluding
>> > yourself, or you're in for a difficult time ...
>
> probably a combination of 2 and 3! maybe it's my inner pedant but i though
> you said "of no technical merit"?

To be precise, *Pavel* said that. But I think I read it less
strictly than you.

/Jorgen

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

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

#15276

On 04/11/12 03:54 AM, mathog wrote:
> Mostly when I program it is maintenance work - making little tweaks and
> corrections to other people's code.  The C++ books and tutorials are all
> clear and wonderful about objects and methods but they only ever give
> toy examples.  In real world programs it seems that the code is always a
> morass of object types and methods, often with similar names.
> (Resulting in: "yes, 'print', but which 'print'?"). I find it extremely
> difficult to find in such code where actions actually occur, or in many
> cases what earlier events led to an issue later in the program.
>
> Presumably there are tools to help with this that I should be using but
> am not. What are these tools?  If somebody knows of a tutorial or
> reference on how to deal with complex code like this, please share it.

I use Oracle's version of NetBeans (Solaris studio) which has pretty 
good code browsing capabilities.  Standard NetBeans or Eclipse should do 
much the same.

-- 
Ian Collins

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

#15280

On Tue, 2012-04-10, mathog wrote:
> Mostly when I program it is maintenance work - making little tweaks and 
> corrections to other people's code.  The C++ books and tutorials are all 
> clear and wonderful about objects and methods but they only ever give 
> toy examples.  In real world programs it seems that the code is always a 
> morass of object types and methods, often with similar names.
> (Resulting in: "yes, 'print', but which 'print'?"). I find it extremely 
> difficult to find in such code where actions actually occur, or in many 
> cases what earlier events led to an issue later in the program.
>
> Presumably there are tools to help with this that I should be using but 
> am not. What are these tools?  If somebody knows of a tutorial or 
> reference on how to deal with complex code like this, please share it.

I don't have specialized tools, but here are some I actually use. They
may be Unix-specific.

- Emacs with 'exuberant ctags' in C++ mode. Still won't work well
  for looking up overloaded names though :-(

- Doxygen with full graph generation enabled.

- A gprof profiling run of the code, compiled with inlining disabled.
  Not for the profiling but for showing the main code flows.

- The nm(1) symbol lister to get a rough idea what one source file
  contains and what it depends on.

- Pen and paper for reconstructing class diagrams, state machines etc.

- Valgrind for detecting obvious memory handling bugs.

- Changing the code (making things private or const; changing their
  type and so on) just to see what stops compiling. Works best if your
  Makefile isn't broken, so the right things are rebuilt automatically.

BTW, I think most of these problems are not related to C++. Most are
there in C too. (Exception: inheritance. I really hate debugging messy
code where everything is badly designed run-time polymorphism and
nothing is documented.)

And, like K. Frank I share your pain. Remember that in maintenance
programming, at least you're creating stuff which people *really need*
and are asking for.  New code on the other hand is often not used in
the end.

/Jorgen

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

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

#15283 — Rewrite it. 

<PRE>
Re: "Methods for understanding complex, real world, C++"

Rewrite it.  That's what I do.

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

#15286 — Re: Rewrite it. 

On Wednesday, April 11, 2012 12:31:03 AM UTC+1, (unknown) wrote:
> 
> Re: "Methods for understanding complex, real world, C++"
> 
> Rewrite it.  That's what I do.
> </pre>

my boss tends not to give me the time to re-write 750 KLOC when a one line change is required. Get real.

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

#15288 — Re: Rewrite it. 

nick_keighley_nospam@hotmail.com wrote:

> my boss tends not to give me the time to re-write 750 KLOC when a one line
> change is required. Get real.

Indeed.  

I wonder if these proponents of this type of scorched earth approach to 
documentation also believe it is a good idea to demolish their house and 
rebuild it if they can't find its blueprints.


Rui Maciel

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

#15289 — Re: Rewrite it. 

On Wednesday, April 11, 2012 10:06:19 AM UTC+1, Rui Maciel wrote:
> nick_keighley_nospam@hotmail.com wrote:

> > my boss tends not to give me the time to re-write 750 KLOC when a one line
> > change is required. Get real.
> 
> Indeed.  
> 
> I wonder if these proponents of this type of scorched earth approach to 
> documentation also believe it is a good idea to demolish their house and 
> rebuild it if they can't find its blueprints.

I'm guessing they're thinking of someting "really large" they've encountered which they could re-write from scratch in 48 hours if they drank enough Jolt.

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

#15290 — Building a "house" that you can live in for decades to come. 

<PRE>
Compared to thousands of lines of code
( 127 columns wide, densely packed ) houses are ⋅very⋅ simple.

It took me months to rewrite some IBM Fortran code to Windows 3.1 C;
but, once done, I had a "house" that I could live in for decades to come.

  I replaced a leaking pipe yesterday.
  Many years ago, when the semi⋅fexible copper pipe was installed,
  it was bent too much ( doubled over ) and condensation corroded it.

  Earlier, I added ( and replaced ) electrical outlets/switches, fans,
  light fixtures, vinyl flooring, sinks, sound⋅proofing, insulation,
  shower doors, shower heads, four E4200 routers ( cat5 ), toilets etc.

Uncommented, <A hRef="http://Jeff-Relf.Me/X.CPP">my code</A> looks like this:

Cat( LnP B², int Sz² ) { if ( Sz² <= 0 ) return;
  LnP &amp;B¹ = *Ln.PP, B¹⁺² ;  int Sz¹ = szStr( B¹ ), Sz¹⁺² = Sz¹ + Sz² ;
  if ( !Sz¹ || Sz¹⁺² > mxCols ) { Ln.PP -= !Sz¹ && Ln.PP > Ln.BB + iPP && ( Top⋅Most || *Ln.PP[-1] <= 32 );
    if ( Sz² < 4 || B²[2] != L'⌗' ) Sh( L"    %.*s", Sz², B² );
    else Sh( L"%.*s", Sz²-=2, B²+=2 );  return;  }

  B¹⁺² = MallocTmp( ++Sz¹⁺² * szChr ), Str( B¹⁺², L"%s%.*s", B¹, Sz², B² ), B¹ = B¹⁺² ;  }

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

#15317 — Re: Building a "house" that you can live in for decades to come. 

@Jeff-Relf.Me writes:
> Uncommented, <A hRef="http://Jeff-Relf.Me/X.CPP">my code</A> looks
> like...

Hey wait, isn't that a bit over the IOCCC size limit?!   :O

-miles

p.s. To anybody who didn't bother following the link, do!
[Tho I'm suspicious that the code was run through some sort of
obfuscator...]

-- 
Omochiroi!

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

#15284 — Re: Methods for understanding complex, real world, C++ code?

Hello Jorgen!

On Apr 10, 6:26 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
> On Tue, 2012-04-10, mathog wrote:
> > ...
> > I find it extremely
> > difficult to find in such code where actions actually occur, or in many
> > cases what earlier events led to an issue later in the program.
>
> > Presumably there are tools to help with this that I should be using but
> > am not. What are these tools?  If somebody knows of a tutorial or
> > reference on how to deal with complex code like this, please share it.
>
> I don't have specialized tools, but here are some I actually use. They
> may be Unix-specific.
>
> - Emacs with 'exuberant ctags' in C++ mode. Still won't work well
>   for looking up overloaded names though :-(

I'm a big fan of using ctags with emacs, although some people find
emacs to be an acquired taste.

> ...
> - Changing the code (making things private or const; changing their
>   type and so on) just to see what stops compiling. Works best if your
>   Makefile isn't broken, so the right things are rebuilt automatically.

I've only ever done this by accident, but I like this idea as a
systematic
technique.  Maybe I'll add it to my bag of tricks.

> ...
> Remember that in maintenance
> programming, at least you're creating stuff which people *really need*
> and are asking for.  New code on the other hand is often not used in
> the end.

Hear, hear!  Sometimes confusing code started out bad, but lots
of times it starts out good, and the bloat and convolution and
bit-rot you're struggling with came about because the code was
useful and being used and growing and gaining new features
because people wanted it.  When you find yourself working on a
multi-man-decade code base like this, it's actually kind of
cool (if frustrating).

> /Jorgen


Thanks for your thoughts and suggestions.


K. Frank

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

#15336 — Re: Methods for understanding complex, real world, C++ code?

K. Frank wrote:
> Hello Jorgen!
>
> On Apr 10, 6:26 pm, Jorgen Grahn<grahn+n...@snipabacken.se>  wrote:
>> On Tue, 2012-04-10, mathog wrote:
>>> ...
>>> I find it extremely
>>> difficult to find in such code where actions actually occur, or in many
>>> cases what earlier events led to an issue later in the program.
>>
>>> Presumably there are tools to help with this that I should be using but
>>> am not. What are these tools?  If somebody knows of a tutorial or
>>> reference on how to deal with complex code like this, please share it.
>>
>> I don't have specialized tools, but here are some I actually use. They
>> may be Unix-specific.
>>
>> - Emacs with 'exuberant ctags' in C++ mode. Still won't work well
>>    for looking up overloaded names though :-(
>
> I'm a big fan of using ctags with emacs, although some people find
> emacs to be an acquired taste.
Those use ctags with vim :-). It does not have that taste and works reasonably 
well for overloaded names while there is less than 30-40 overloads..

But ultimately, grep (or fgrep) is your only friend..

-Pavel
>
>> ...
>> - Changing the code (making things private or const; changing their
>>    type and so on) just to see what stops compiling. Works best if your
>>    Makefile isn't broken, so the right things are rebuilt automatically.
>
> I've only ever done this by accident, but I like this idea as a
> systematic
> technique.  Maybe I'll add it to my bag of tricks.
>
>> ...
>> Remember that in maintenance
>> programming, at least you're creating stuff which people *really need*
>> and are asking for.  New code on the other hand is often not used in
>> the end.
>
> Hear, hear!  Sometimes confusing code started out bad, but lots
> of times it starts out good, and the bloat and convolution and
> bit-rot you're struggling with came about because the code was
> useful and being used and growing and gaining new features
> because people wanted it.  When you find yourself working on a
> multi-man-decade code base like this, it's actually kind of
> cool (if frustrating).
>
>> /Jorgen
>
>
> Thanks for your thoughts and suggestions.
>
>
> K. Frank

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

#15285

On Tuesday, April 10, 2012 5:54:39 PM UTC+2, mathog wrote:
> In real world programs it seems that the code is always a 
> morass of object types and methods, often with similar names.

I consider real world code that does not come with sufficient documentation to have a value close to zero. Often its less work to rewrite the stuff from scratch.

In cases where this is not an option and pressure to bother is gross, I'd recommend to reverse engineer an UML model for the code, i.e. start with a static class model depicting interfaces, inheritance and aggregation, and continue by filling in usage information who calls what else. It may also possible to group classes to components.

Once this is done, you can analyze method by method and add diagrams for the code's dynamics (sequence-, activity-, state diagrams). Whatever you find out you should also add as extra comments to the code.

If you're lucky, you end up with a usable code documentation. Many times you won't be lucky, in spite of the systematic approach.

Doxygen in combination with GraphViz is a good start if you are looking for tools. It will spare you of lots of manual work for the analysis. For modelling UML I prefer Sparxsystem's Enterprise Architect. It is a commercial product but relatively cheap compared to other tools. For reengineering purposes you'd need the "Professional" edition or better; its code-to-model import features should come handy.

best,

   MiB.
 

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

#15287

michael.boehnisch@gmail.com wrote:

> On Tuesday, April 10, 2012 5:54:39 PM UTC+2, mathog wrote:
>> In real world programs it seems that the code is always a
>> morass of object types and methods, often with similar names.
> 
> I consider real world code that does not come with sufficient
> documentation to have a value close to zero. Often its less work to
> rewrite the stuff from scratch.

This approach doesn't appear to be very reasonable.  If a piece of code 
which may not be documented is already mature then your suggestion to 
reinvent the wheel may end up needlessly reintroducing bugs and other 
issues.  So, just because you can't access the documentation of a piece of 
code you risk ending up needlessly wasting resources to make something worse 
than it already is.  And where's the added value in this?


Rui Maciel

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

#15305

In article <jm1l4g$a6e$1@dont-email.me>, mathog  <dmathog@gmail.com> wrote:
>The C++ books and tutorials are all clear and wonderful about objects
>and methods but they only ever give toy examples.

This was one of my disappointments with college 'education'.

They teach you how to write programs, from scratch, all by yourself,
which are probably no more than ten pages long.

Employers don't give a s--- about that, they want to know if you can
grok an existing codebase, get up to speed, interact with the people who
know about it, deal with people who are no longer there, and mentor the
'new guys' so they can do something useful.

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

#15311 — Re: Methods for understanding complex, real world, C++ code?

On Apr 11, 3:36 pm, j...@panix.com (Joe keane) wrote:
> In article <jm1l4g$a6...@dont-email.me>, mathog  <dmat...@gmail.com> wrote:
> >The C++ books and tutorials are all clear and wonderful about objects
> >and methods but they only ever give toy examples.
>
> This was one of my disappointments with college 'education'.
>
> They teach you how to write programs, from scratch, all by yourself,
> which are probably no more than ten pages long.
>
> Employers don't give a s--- about that, they want to know if you can
> grok an existing codebase, get up to speed, interact with the people who
> know about it, deal with people who are no longer there, and mentor the
> 'new guys' so they can do something useful.

Perhaps one way of instructing classes then would be to shuffle up
peoples' answers from one assignment, hand them out to the students,
ask them to extend the code to do more stuff...and assign them the
task of grading the code they were given to work with.

I can see issues with it, but maybe some variation on that theme could
be instructive?

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

#15313 — Re: Methods for understanding complex, real world, C++ code?

On Wed, 11 Apr 2012 16:05:08 -0700 (PDT), Noah Roberts
<roberts.noah@gmail.com> wrote:

>On Apr 11, 3:36 pm, j...@panix.com (Joe keane) wrote:
>> In article <jm1l4g$a6...@dont-email.me>, mathog  <dmat...@gmail.com> wrote:
>> >The C++ books and tutorials are all clear and wonderful about objects
>> >and methods but they only ever give toy examples.
>>
>> This was one of my disappointments with college 'education'.
>>
>> They teach you how to write programs, from scratch, all by yourself,
>> which are probably no more than ten pages long.
>>
>> Employers don't give a s--- about that, they want to know if you can
>> grok an existing codebase, get up to speed, interact with the people who
>> know about it, deal with people who are no longer there, and mentor the
>> 'new guys' so they can do something useful.
>
>Perhaps one way of instructing classes then would be to shuffle up
>peoples' answers from one assignment, hand them out to the students,
>ask them to extend the code to do more stuff...and assign them the
>task of grading the code they were given to work with.
>
>I can see issues with it, but maybe some variation on that theme could
>be instructive?


Unfortunately the programs you'd be reshuffling would be too small by
a couple of orders of magnitude.

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

#15337

mathog wrote:
> Mostly when I program it is maintenance work - making little tweaks and
> corrections to other people's code. The C++ books and tutorials are all clear
> and wonderful about objects and methods but they only ever give toy examples. In
> real world programs it seems that the code is always a morass of object types
> and methods, often with similar names.
> (Resulting in: "yes, 'print', but which 'print'?"). I find it extremely
> difficult to find in such code where actions actually occur, or in many cases
> what earlier events led to an issue later in the program.
>
> Presumably there are tools to help with this that I should be using but am not.
> What are these tools? If somebody knows of a tutorial or reference on how to
> deal with complex code like this, please share it.
>
> For instance, lately I have had to make some changes to Inkscape. The
> development environment is Mingw. This program uses Cairo, GDK, GTK, Pango, and
> heaven knows what else, in addition to all of its own code. The closest thing I
> have to a class browser is the doxygen web interface, example:
>
> http://fossies.org/dox/inkscape-0.48.3.1/clipboard_8cpp_source.html
>
> One of the tasks on my "to do" list is to add import/export of images to the EMF
> extension. I found the relevant sections in the EMF extension (switch() cases
> provided, but no code in them) by a grep through all of the source code for the
> EMF keyword function associated with images. Looking around for an example of
> how to handle images in Inkscape located the link above by more grep's, since I
> knew one could paste an image into the program from the clipboard. From this
> link, on line 937 we see that rather than converting directly from GDK::Pixbuf
> to an Inkscape object type they punted. First they save from the Pixbuf to a PNG
> file, and then they use a preexisting file_import function to read that object
> back in. The program pastes at the cursor (or something like "at the cursor")
> but how it knows where that is lies in a code segment far far away. Anyway, this
> illustrates the point I'm trying to make. One would imagine that somewhere in
> this heap of code there is a "create/import image of size W,H at position X,Y",
> but good luck finding it.
>
> Figuring out the logic in real C++ programs is also challenging. In Inkscape,
> for instance, much of the program is event driven, so a backtrace will often not
> tell you what happened before a given execution point. Example:
>
> A ->
> B ->
> C (configure: event X will cause E) ->
> D (configure: something else relevant when E runs) ->
> C ->
> B (event X) ->
> E (stops at preset breakpoint)
>
> So the back trace shows
>
> A->B->E
>
> and there is no clue that C and D are important, or even that they ever ran.
> This A->E example is grossly simplified, since in the real program there were
> thousands of function calls before event X. Short of tracing every function call
> how would one ever know that C,D need to be looked at?
>
> Thank you,
>
> David Mathog
>
To browse code Eclipse with CDT is pretty good if you can tame your projects for 
it (it is usually possible, but for some of mine I still have to use the 
immortal combination of gvim, ctags, fgrep and egrep).

Draw diagrams for your own understanding (I use Umbrello) but do not get too 
crazy about it. Mostly no one will be looking at them except yourself.

Try to understand way of thinking of your predecessors and memorize stuff (I 
know first hand how stupid it sounds and how painful it feels but somehow it 
eventually pays off for me).

HTH
-Pavel

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

#15391

On Fri, 2012-04-13, Pavel wrote:
...
> Draw diagrams for your own understanding (I use Umbrello) but do not get too 
> crazy about it. Mostly no one will be looking at them except yourself.

I use pen and paper. I find that half the usefulness of that is
convincing yourself that you /can/ extract this information from the
code any time you want, in a few minutes.

Also, I find such diagrams are most useful if you don't aim for
completeness; i.e. you focus on a specific aspect of the code.
Automated tools on the other hand have no option but to include
/everything/.

/Jorgen

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

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

#15398

Jorgen Grahn wrote:
> On Fri, 2012-04-13, Pavel wrote:
> ...
>> Draw diagrams for your own understanding (I use Umbrello) but do not get too
>> crazy about it. Mostly no one will be looking at them except yourself.
>
> I use pen and paper. I find that half the usefulness of that is
> convincing yourself that you /can/ extract this information from the
> code any time you want, in a few minutes.
>
> Also, I find such diagrams are most useful if you don't aim for
> completeness; i.e. you focus on a specific aspect of the code.
> Automated tools on the other hand have no option but to include
> /everything/.
>
> /Jorgen
>

I fully agree -- I stop at the lowest level of details that gives me just enough 
understanding. I am terrible with organizing my hard copies though and Umbrello 
lets me then grep for a class name etc (it saves models in plain XML (XMI))).

This ability to search is to me one of the main advantages of paper-less 
bureaucracy in general (there are drawbacks, of course; and they say that 
drawing with traditional tools, especially alternating hands, makes you smarter...)

-Pavel

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web