Newsgroups: comp.object,comp.lang.c++,comp.lang.ada,comp.lang.cobol,comp.lang.clos
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!gatech!usenet.ins.cwru.edu!news.csuohio.edu!news
From: jabaker@grail.cba.csuohio.edu (jason baker)
Subject: Re: C++ not OOP? (Was: Language Efficiency
In-Reply-To: gclements@keps.com's message of Thu, 18 May 1995 07:59:42 -0500
Message-ID: <jabakerzndrzo5jb6qv@grail.cba.csuohio.edu>
Sender: news@news.csuohio.edu (USENET News System)
Organization: Cleveland State University
X-Newsreader: (ding) Gnus v0.32
References: <dewar.797512974@gnat> <3mbmd5$s06@icebox.mfltd.co.uk>
	<3n8jdv$jer@watnews1.watson.ibm.com> <3n8rjd$90a@disunms.epfl.ch>
	<19950421T230840Z.enag@naggum.no>
	<rshapiro-1305951849430001@ipa.bbn.com>
	<GIROD.95May15105836@dshp01.trs.ntc.nokia.com>
	<rshapiro-1605952054040001@ipa.bbn.com>
	<1995May17.175411.9737@rcmcon.com>
	<gclements-1805950759420001@155.50.21.58>
Date: Sat, 20 May 1995 13:55:09 GMT
Lines: 58
Xref: glinda.oz.cs.cmu.edu comp.object:31216 comp.lang.c++:129244 comp.lang.ada:30140 comp.lang.cobol:3420 comp.lang.clos:2973

>>>>> "G" == Geoffrey Clements <gclements@keps.com> writes:
In article <gclements-1805950759420001@155.50.21.58> gclements@keps.com (Geoffrey Clements) writes:


    G> In article <1995May17.175411.9737@rcmcon.com>,
    G> rmartin@rcmcon.com (Robert Martin) wrote:

    >> rshapiro@bbn.com (R Shapiro) writes:
    >> 
    >> >In article <GIROD.95May15105836@dshp01.trs.ntc.nokia.com>,
    >> Marc Girod ><girod@trshp.trs.ntc.nokia.com> wrote: >>Static
    >> typing provides with something very valuable too, even for
    >> >>rapid prototyping
    >> 
    >> >Explain to me how any C++ environment could possibly support
    >> rapid >prototyping without dynamic, incremental compilation at
    >> the function/class >level. Static typing is irrelevant. The
    >> problems are (1) the edit-cycle >time in C++ gets way too long
    >> as soon as your system gets bigger than a >toy; and (2) the
    >> language doesn't support debug-time code change and
    >> >recovery. In both dimensions, C++ stands in sharp contrast to
    >> Lisp, >Smalltalk and probably Dylan.
    >> 
    >> C++ neither allows nor disallows incremental compilation.

    G> I have been thinking about this for the last couple of
    G> days. The main difficulty in creating a dynamic, incremental
    G> environment is C/C++'s UNIX background. When a programmer sits
    G> down to write C/C++ code he expects to use emacs to edit his
    G> files, make to build his project, cc to compile his files and
    G> link to create executables. These are all separate tools that
    G> read and emit a stream of bytes. There is no integration
    G> between the parts. Once the tool is finished there is no
    G> remembered state. UNIS loves separate little tools for every
    G> little operation.

	When I write c/c++ code, I use emacs to edit it, emacs'
compile mode, and make to compile it, and emacs' gdb mode and gdb to
run it.  When I make a change, I can do M-x compile, ^X-^B
*gud-whatever*, and run.  gdb might mention that the program is
already running, it will see that there is a new executable, read it
and reinstall it's breakpoints.  This process is time consuming, but
really isn't any more work than any rapid C(++)? environment I can
imagine.

    G> I asked myself what would it take to create a dynamic C or C++
    G> development environment. The main stumbling block is an
    G> environment that can remeber the state of all code compiled up
    G> to the current time including what file that code came out of
    G> so that the static keyword could be honored. This is just a

	Make already knows these things.  I would like to be able to
make new object modules, then somehow inform the debugger that they
should be relinked with the debugged executable.  I doubt that C
debuggers keep enough information to do that kind of relinking, but if
they did, I beleive it would be faster than building a new executable
from scratch.  Note, I know very little about linking and may be
completely full of shit.
