From: Phil Galbiati <Philip DOT S DOT Galbiati AT Tek DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Idea for powerful IDE
Date: Mon, 02 Dec 1996 21:47:23 -0800
Organization: Tektronix
Lines: 319
Message-ID: <32A3BEEB.2130@Tek.com>
References: <32A0FD87 DOT 66AA AT nlc DOT net DOT au>
NNTP-Posting-Host: philipga.cse.tek.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: shaman AT nlc DOT net DOT au
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

<ASBESTOS>
This response may sound more like a flame than I intended.  For that,
I appologise.  Several of the points made by the original poster are
quite valid, specifically, the need for version control / configuration
management packages, and the need for syntax-sensitive editors.  My
points are:
   1) Much of what you want is already out there
   2) I don't agree with some (OK, many) of your implementation ideas
</ASBESTOS>

shaman AT nlc DOT net DOT au wrote:
> 
> I've noticed that a lot of compilers/IDEs are still in the ice
> ages where code organisation is concerned. Even the most expensive
> IDEs cannot do much more than a simple text editor. Some can
> automatically reformat each line so it looks neat (VBasic) and
> some can check for simple things like missing brackets and
> auto-highlight code, but this is all quite simple. When projects
> are being made by several people, most IDEs do not have features
> to help out. Some examples of things that irk me:
> 
> * Have you noticed that linkers will link an entire object file
> even if you only use a single function in it?

That's what they are *supposed* to do.  Object files are *not*
libraries.  If you don't want all the functions in an object file
to be linked in, then break up your source files into more manageable
pieces (like 1 function per file, or 1 class per file), compile each
source file to an object file, and then use a utility like ar to
create a library.

> * A lot of programming is playing about with a small section of code
> over and over again. Backup files are useless if you do it more than
> twice. I want to be able to backup a selected area(s) of code and
> restore them at will in case the mucking about wasn't too good.

If you use RCS or any one of the several commercially available 
configuration management packages and religiously check-in your
changes at each edit-recompile cycle, you will be able to undo
anything you did.  It also helps if you keep your files small (as
in 1 function or class per file) so that you don't recompile
unmodified code.

RCS (Revision Control System) is available for FREE from gnu in
source form (I don't know if it compiles under DJGPP without
modification) or you can look for pre-compiled versions on either
simtel.net or shareware.com.  There are also commercially supported
versions available from MKS and others.

> * I want to be able to get to the function I'm interested in without
> flipping through pages of code. Why can't IDEs put each function/class
> on it's own? (Visual Basic does this)

Why can't *YOU* put each function/class in its own file?

> * What if several people are working on the same project? Keeping
> everyone's version of the code up to date is a bitch, compiling is
> difficult at best and with very large projects it becomes a total
> nightmare. No wonder projects like Windows 95 are so badly organised.

Well, if you put 1 function or class per file (do you detect a theme
yet?) and use RCS or the equivalent, then you can have everybody work
off the same codebase without the risk of stomping on each others work,
and everybody will always be consistent.

Or you could let everyone have their own private copy of the in-work
version (initially identical to the last release), and then coordinate
as changes are completed. 

> * Why can't compilers automatically notice and warn me about common
> mistakes like leaving out semi-colons at the end of class declarations
> using colored highlights?

Eli addressed this.  Use emacs.

> * Why can't ALL the files of a project, including the project be
> kept in a single file that the IDE edits with bits of it exported
> as necessary?  Eg: I could export everything into .h and .cc files
> or the IDE would automatically export everything necessary into a
> temp dir when compiling.

Why on earth would you ever think of organising a large project in
this manner?  Putting everything in one file would force a complete
recompile after every change, even though 99.999% of the codebase
was unmodified.  Furthermore (and more importantly), if more than
one person was working on the project, it would require that their
*editors* stay concurrent (in other words, you would see what your
neighbors are typing).

The *ONLY* benefit provided by stuffing everything into a single
file is that it takes up slightly less space than breaking every
function into its own file (this is due to the cluster mechanism
DOS uses to allocate disk space).  If you have a project consisting
of ten thousand functions with an average length of 100 lines per
function, and an average line-length of 40 characters per line, then
stuffing everything into a single file would require just over 38
megabytes to store the complete source code base.  If you store as
1 function per file, and your cluster size is 32kBytes, then you need
something like 312 megabytes to store the complete source code base.
If your company really has a project of that size (one million source
lines of code == roughly 200 man years I think), then they should be
able to fork out an extra couple hundred bucks for a half-gig disk.

Also, if you are using RCS, then the space disadvantage of breaking
your project up shrinks as the project ages, since the changes are
stored in the same file as the current version.

> * Why aren't there nifty features in compilers like being able to see
> what a typedef/constant/macro actually is in a seperate window just by
> moving the cursor over it?

Eli addressed this, but I admit it would be a handy feature.

> Considering people are thinking of porting RHIDE to Win95/97,
> wouldn't it be smarter to make an IDE that is head and shoulders
> above the rest and can invoke other compilers (Including DJGPP of
> course) by exporting the appropriate files? Some features I would
> like to see in an IDE:
> 
> * If I write a full class declaration, the IDE would parse it and
> automatically create all the empty functions, so I won't have to
> do half an hour of cut and pasting, removing and adding things,
> etc.. (Like putting the xxxx:: in )

I'm not a C++ expert, but it seems to me that you could use Lex and
YACC (or FLEX & BISON) to write a class declaration parser to generate
a skeleton .cc file (or a set of .cc files) based on a .hh input.  It
probably wouldn't take much more than a half-hour to write it, if you
assumed that the input .hh file was syntactically correct.  You could
probably get emacs to invoke it for you also, but I'm not certain how
to do it.  Eli?

> * The IDE could transparently create things like semi-unrolled loops.
> This would make the code more readable, but compilers wouldn't have
> to be changed. Eg: If I wrote:
> 
>         for ( int i = 1; i < count; i++ ) [x16]
>         {
>                 doSomething( somedata );
>         }
> 
> Then the IDE would export that as a loop that executes the loop 16
> times before making a compare. (An [x8] loop would look like this:)
> 
> {
>     int i = count;
>     if ( i > 16 )
>     {
>         for (; i > 8; i-=8 )            // main loop.
>         {
> 
>         }       doSomething( somedata );
>     }
>     for ( ; i; i-- )                            // cleanup loop.
>     {
>         doSomething( somedata );
>     }
> }

Ummmm.... I'm not sure I'm following you.  An 8x unrolling of
   for ( int i = 1; i < count; i++ )
      {
         doSomething( somedata );
      }

would be something like this:
   for ( int i = 1; (i+7) < count; i+=8 )    // main loop
      {
         doSomething( somedata );
         doSomething( somedata );
         doSomething( somedata );
         doSomething( somedata );
         doSomething( somedata );
         doSomething( somedata );
         doSomething( somedata );
         doSomething( somedata );
      }
   for ( ; i < count; i++) {                 // cleanup
         doSomething( somedata );
   }

I'm not sure that I would trust an IDE to do this correctly (in fact,
I'm not sure I'd trust many compilers to do it correctly -- wasn't
there a bug in the loop unrolling optimization in gcc a few releases
back?).  You would have to ensure that the stuff inside the loop was
not dependent upon the loop index -- consider this example:

   for (i=0; i<10; i++) {
      printf ("%d...", i);
   }
   printf ("\n");

If you unrolled this 8 times, it would print:
   0...0...0...0...0...0...0...0...8...9
which is probably not what you intended.

Of course you could require that the programmer use some special
syntax to turn this feature on (which is what I think you probably
meant by the "[x16]" after the for stmt), but then you are no longer
writing ANSI c -- so much for portability.

Or you could require that the index increment get unrolled as well, 
giving the following (which might even be correct):
   i = 1;
   while ((i+7) < count)    // main loop
      {
         doSomething( somedata ); i++;
         doSomething( somedata ); i++;
         doSomething( somedata ); i++;
         doSomething( somedata ); i++;
         doSomething( somedata ); i++;
         doSomething( somedata ); i++;
         doSomething( somedata ); i++;
         doSomething( somedata ); i++;
      }
   while (i < count) {                 // cleanup
         doSomething( somedata );
         i++;
   }

But regardless of how you decide to unroll the loop, I don't see
that the IDE is the appropriate tool for the job -- he purpose of
the the IDE is to present a friendly user interface, regardless
of the compiler or target hardware desired.  Optimizations should
be done by the compiler, since they tend to be machine dependent.
In fact, your loop-unrolling idea could cause the program to execute
slower (under pathalogically bad circumstances -- consider the case
where count is less than 8, and the increased code size happens
to generate one more page fault than would have happened had you
left the loop intact).

> * The IDE could support multiple programmers by allowing coders to
> simultaneously edit the same project file. The file would be stored
> on a central server and if one person starts modifying a
> class/function, he/she would "freeze" it while editing. This would
> mean that others can compile using the original code, but the person
> editing it would compile with the new, edited code. When the person
> is finished, he/she would unfreeze the block and it would be updated.

I've already addressed this.  Your approach would require that all
the programmers are kept consistent on a keystroke-by-keystroke
basis, since two people could accidentally attempt to rewrite the
same block of code.  If the first person decided to add the new
code before deleting the old code, and the second person decided
to delete the old code first and then add the new code, you could
end up stomping on each others work:
   #1 starts adding new code
   #2 locks & deletes old code
   #2 starts adding new code
   #1 attempts to lock & delete old code, but deletes #2's new code
      instead.

RCS provides a mechanism for locking pieces of the source code base,
but it works on a file granularity (i.e. you can only lock an entire
file).  It also saves all versions that get checked in (which is how
you unlock the file when you are done with it), so even if somebody
stomps on your work, you can recover it.  This works quite well, as
long as the files are small enough.  If the files are too big, then
you run into problems where two unrelated changes cannot be made
simultaneously because they both need to modify the same file.

> * The IDE could keep track of who last modified each part, who
> wrote it originally, etc.. If something becomes obscure it would
> make finding the original coder easy.

RCS already does this.

> * The IDE should read in and interpret any headers and automatically
> detect any identifier name conflicts. (Not always possible)

I don't see that this would save that much work.  If your files are
small enough and you avoid the use of global variables, then you won't
have *that* many identifier name conflicts, and even when you do, you
won't have *that* many references to the conflicting identifier.

If you *must* use global variables, then you could always resort to a
variable naming protocol to prevent namespace collisions (for example,
you could require that all globals start with a capital letter or
something).  Of course, this doesn't help much if you have to deal
with an existing codebase which didn't adhere to the protocol.

> * I wonder if it would be possible for a compiler/IDE to link
> individual functions instead of entire object files. This would
> mean the compiler and the linker would have to modified somewhat
> to be able to recognise inter-dependencies.

If you are using DJGPP or pretty much any UNIX system, there is a
utility called ar which will take a bunch of object files and create
a library.  You can then link your program with this library (using
the -l switch I think), and the linker will extract only the objects
it needs.

> etc, etc.. I'm sure everyone can think of hundreds of things that
> annoys them about compilers/IDEs..

What I find most annoying about IDE's is their notion of a "project".
The few IDE's I have tried (3 different Borland products, and one
from somebody else -- I haven't tried RHIDE) provide no mechanism
for printing the project settings.  This, in my opinion, makes them
undesireable (if not unusable), since there is no way to document
how a program was compiled (i.e., what compiler was used, what
switches were set, and what directory was it compiled in).

Furthermore, if I was maintaining a program and I needed to modify
one file, I see no reason to open ALL the files used by the program
as a whole.

As far as I can tell, "projects" are something that was invented by
commercial compiler marketers, in order to reduce the portability of
software written using their products, therby preserving their market
share.  I no longer bother with these "projects" -- I just write a
makefile.

--Phil Galbiati

=================================================
     Any opinions expressed here reflect the
     ignorance of the author, NOT Tektronix.
=================================================