HDTenEightyP/NetNews huggingface dataset:
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: Garbage Collection for C++
Date: 29 Aug 92 21:54:19 GMT
	<1992Aug20.213720.16599@microsoft.com> <boehm.714410546@siria>
	<1992Aug25.185458.10190@microsoft.com> <boehm.714847027@siria>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: boehm@parc.xerox.com's message of 26 Aug 92 16:37:07 GMT

In article <boehm.714847027@siria> boehm@parc.xerox.com (Hans Boehm) writes:

   Agreed.  Support for movable objects is a good thing.  But it also has
   a very substantial cost, in that lots of compilers and libraries need to be
   fixed.  Some (nonportable but useful) programming paradigms break (e.g.
   hashing pointers no longer works.  You need an extra counter field per
   allocated object if you want to be able to hash.)  There is a cost (of
   one kind or another) in maintaining enough descriptor information.

To inject some real-world data again, fragmentation can be a problem.
I have a machine with about 200M swap space, and a program that only
needed about half that much memory ran out of memory because of
fragmentation.

I think movable objects ultimately are very important, but, like so
many things that are very important, support for them seems to be
difficult to add cleanly and efficiently to the C++ programming
language.

					Thomas.
Newsgroups: comp.lang.c++
From: feustel@netcom.com (David Feustel)
Subject: CTAGS for C++?
Date: Fri, 28 Aug 92 00:40:57 GMT
Organization: DAFCO: OS/2 Software Support & Consulting

Is there available a CTAGS program for C++ that can be ported to OS/2?
Thanks.
-- 
Dave Feustel N9MYI <feustel@netcom.com>
 
( New .sig under construction. Watch this space! )
Newsgroups: comp.lang.c++
From: trachos@uni-paderborn.de (Konstantin Trachos)
Subject: risky inline
Keywords: inline, safe programming
Organization: Uni-GH Paderborn, Germany
Date: Thu, 27 Aug 1992 12:27:00 GMT

Maybe this topic is well known, but I realy want to know the reason, 
inline has been introduced for.

Inline-expansion is surely more effective than #defines, but it isn't
less risky than that.

Consider folowing example:
C.hxx and C.cxx are used to build C.lib.
After that you use only C.hxx and C.lib:

// Interface C.hxx -----------------------------
   class C{
          int a() {return 0;}	// OK
   inline int b() {return 0;}	// OK
          int c();		// ...
	  int d();		// ...
   };
// EOF C.hxx -----------------------------------

// Code C.cxx ----------------------------------
   #include "C.hxx"
   inline int C::c() {return 1;}// !
          int C::d() {return 0;}// OK
// EOF C.hxx -----------------------------------


The Problem is, that #including C.hxxin your main file
will make the cfront handle the C::c() as a function-call
instead of expanding the code.
You can also build more .libs including code invoking C::c().
But the linker will fail, because he is going to miss c__1CFv.

I think, that a safe compiler requires safe Language-rules,
not only carefull Programmers.


-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=
 _          __  
| |  _    _/ /   Uni-GH Paderborn, FB 14   
| |/ /   /  __/  Dipl.-Inf. K. Trachos   
| |\ \   / /     Pohlweg 47-49                      Tel: +49 5251 60 3227
|_| \_\ /__/     D-4790 Paderborn                   FAX: +49 5251 60 3238
                                      email: trachos@dat.uni-paderborn.de
-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Newsgroups: comp.lang.c++
From: pjl@sparc2.cs.uiuc.edu (Paul Lucas)
Subject: Re: Novice Questions
Organization: University of Illinois at Urbana-Champaign
Distribution: usa
Date: Wed, 26 Aug 1992 00:11:50 GMT

In <1992Aug24.235755.28424@athena.cs.uga.edu> aharris@athena.cs.uga.edu (Austin Harris) writes:

>Hello, I have a couple of novice questions which I haven't been able to find
>answers to in either my Turbo C++ or Waite group books.  1) Can you
>return arrays from functions, if so what is the declaration and definition
>syntax?  I'm writing a simple program that does different types of string
>reversing and thought that I should call a function with a string, and then
>return that string reversed in different ways.

*****>	Array names (almost) always decay into a pointer to the first
	element, so _that's_ what you return--a pointer.

>2) How can I count spaces in a string within a 'while not end of string' loop?
>I know how to count other characters in a loop but not spaces.

*****>	Huh?  If you can count the number of 'a's, you count the number
	of spaces that same way:

		for ( char const *c = s; *c; ++c )
			if ( *c == ' ' )
				++count;

	For whitespace in general:

	#include <ctype.h>

		// ...
			if ( isspace( *c ) )
				// ...


>What is the best way to look for the end of a string, do I just look for the
>null zero?

*****>	Yes.

>What if there are other zeros in my string?

*****>	There can't be; if you need that functionality, you can't use C
	"strings"; you'll have to maintain a character-count (like Pascal
	strings).
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.lang.c++
From: kotula@milli.cs.umn.edu (Jeff Kotula)
Subject: desparate plead for help with Borland ObjectWindows
Organization: University of Minnesota
Date: Wed, 2 Sep 1992 01:12:42 GMT


First, let me apologize for posting a question about a specific compiler.
Last time I did this someone, quite rightly, pointed to other venues for
such questions.  Unfortunately I lost that mail message (accidentally
deleted it, I mean), and I would appreciate it if that person could
send me the information again.

On to the problem...

Actually, I have several problems, but I'll start with the worst one.
I have a small ObjectWindows program that is loosely based off of the
example programs provided on owl/examples/steps.  I'm including owl.h.
My directory search path includes \borlandc\include, \borlandc\owl\include,
and \borland\classlib\include.  All this seems fine as far as I can tell,
yet when I compile, HWindow comes up undefined!

I'm guessing there is something different in my project file from the steps
project file.  However, I'm out of ideas.

Yes, I called Borland's support line, but this being for private use, I
can't afford to stay on hold to California (from Minnesota).  I would
give great praise and eternal servile gratitude to anyone who can help me
figure this out.

Thanks for your patience.

--
-------------------------------------------------------------------------------
jeff                            |     "We've got to make drastic changes to
kotula@cs.umn.edu               |      keep up with the competition.  That's
				|      why I've had these little note pads
From: kers@hplb.hpl.hp.com (Chris Dollin)
Date: Fri, 4 Sep 1992 07:29:31 GMT
Subject: Re: Re: GOTO, was: Tiny proposal for named loops.
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Newsgroups: comp.lang.c++

In article ... rmartin@thor.Rational.COM (Bob Martin) writes:

   You don't have to make up your own rules.  Some other guys, who have
   thought about it alot, have put together a pretty well thought through
   set of rules.  Moreover, the industry has, for the most part, accepted
   those rules as valid.  Moreover, it has been proven that those rules
   are always workable, and it has been shown that they help to make code
   more readable and maintainable.  

In what sense do you claim that ``these rules'' (by which I understand you to
mean the usual rules of structured programming) have been ``proven'' to be
``workable''? 

It's certainly true that any procedure can be rewritten in structured style
(ie, using only while, if, and sequencing as control structures). But the
easiest proof of this -- turn it into a loop wrapped round a case (chained ifs,
if you want to be picky) -- also shows that it's not necessarily a good idea,
if what you want is *clear* code.

And clearness is as much a matter of psychology as of mathematics. There's a
lot of empirical evidence to suggest that traditional SP ``works'', ie, that 
for very many programming problems, they are an effective solution. [The
evidence is the large number of programs written effectively in that style.]
But there's also evidence that they're not *enough* -- that other control
structures are needed for clarity -- consider

    * procedures
    * FOR-loops (of various kinds)
    * N+1/2 times loops
    * Scheme-style use of tail-call
    * Co-routines
    * Higher-order functions

for example.


--

Regards,    | "If taking devious pains was a sign of laziness, he was quite
Kers.       | prepared to call Hazelton the laziest man alive." Blish (m-o-l)
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: Garbage Collection for C++
Date: 27 Aug 92 14:23:43 GMT

jonas@beppe.ericsson.se (Jonas Nygren) writes:

>I believe Apples C++ supports moveable objects. If I am correct pointers in this
>C++ are really pointers to handles which in their turn points to the objects
>current location. This would imply that each dereference in user code p->x
>would be translated by the compiler into (*p)->x.

>Does anybody know if Apple's C++ works this way? If so, how do they handle
>pointers to objects on the stack.

I don't know about MPW C++, but Think C (Kind of a (C++)--) does have
the ability to treat handles as pointers.  Handles are master pointers
which in turn point to the movable block.  When the block gets moved,
the contents of the master pointer change, but the handle still points
to the same master pointer.

This works quite well in the Mac O/S.  The syntactic sugar that lets
Handles be treated as pointers removes a lot of the bugs which used to
occur when programmers dereferenced a handle, and kept the pointer to
the object beyond the point where the object got moved.


--
Robert Martin                        Training courses offered in:
R. C. M. Consulting                       Object Oriented Analysis
2080 Cranbrook Rd.                        Object Oriented Design
Green Oaks, Il 60048 (708) 918-1004       C++
From: plyon@emx.cc.utexas.edu (Paul Lyon)
Newsgroups: comp.lang.c++
Subject: Re: File I/O using C++ (write/read objects...)
Date: 29 Aug 92 00:31:42 GMT
	<DAVIDM.92Aug26132938@consilium.com>
Organization: The University of Texas at Austin
In-reply-to: davidm@consilium.com's message of 26 Aug 92 20:29:38 GMT


In article <DAVIDM.92Aug26132938@consilium.com> davidm@consilium.co
(David S. Masterson) writes:

   As far as I've seen, there is no automatic, reliable approach to
   writing a C++
   object to a file (or sending it in a message).  It requires knowing what the
   format of the object internally looks like and, possibly, converting this
   internal format into a format that is persistent.

   The only generic, portable approach to doing this that I've seen is
   what I'll call "linearization" of an object.  That is, when object
   wants to write itself onto a stream (as defined by operator>>), it
   converts itself into a stream of bytes that will be recognizable on
   the other end of the stream (so that operator<< will understand it).
    With these operators defined on every object, newly derived objects
   simply worry about their internal structure and call the appropriate
   superclass method to handle the rest.  The drawback with this is that
   it suggests a Smalltalk approach to creating objects (everything
   derives from the central controlling Object).  Naturally, there are a
   lot of little "gotchas" in this that must be worked out (like peeking
   into a stream and making a guess about what the next object is that's
   coming out of the stream so that the appropriate object may be
   constructed).

   Comments?
   --

These remarks seem sensible enough to me, but I think it worth noting
that a model of how to do this may be found in the NIH class library.
See, in particular, the "OIO" files in the distribution thereof and
the documentation for same. Both may be ftp'd from
wuarchive.wustl.edu, in the directory ~ftp/mirrors2/gnu. What they do
here is both to have a single derivation tree and also to keep a table
of class information that allows each store-to-stream and
read-from-stream method to keep track of contained class objects and
class derivation so that each object of a class in the system can
reliably be written out and recovered in such a way that each class in
the system only needs to worry about the data peculiar to itself in
the process, leaving its base classe object(s) and contained class
object(s) to take care of their own, and so on.  I do not know how
adaptable their approach would be to other contexts, but pondering the
approach taken should at least be informative about what needs to be
done to make this sort of scheme work.

Hope this helps...

Paul Lyon
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: Destruction of temporaries
Date: 3 Sep 92 12:47:12 GMT

Part of the following suggestion has been gleaned from the postings of
others on this thread.  

There are cases where the lifetime of a temporary appears obvious:

void f()
{
  String& x = String("x");
  String& xx = x+x;
  String& xxx = X+x+x;
}

The temporary created by "String("x")" is being bound to an
auto-variable.  So the temporary should "inherit" the lifetime of the
auto-variable.   So too with the temporary created during the
initialization of xx.

However, there are two temporaries created during the initialization
of xxx.  One gets bound to the xxx variable, but the other is simply
used as an argument to operator+.  Lets call these btemps and utemps
for "bound temporaries" and "unbound temporaries".

I have been suggesting that any time a pointer or reference to a
temporary is taken, that the compiler issue a warning.  This alerts
the programmer to the fact that a long lived alias *may* be being
created to a short lived temporary.  

Many readers have (rightly) complained that this would generate far
too many warnings.  Let me now adjust my suggestion.

A btemp is a temporary which is bound to a reference by
initialization during the DECLARATION of the reference.  This means
that temporaries bound in declarations are btemps, but temporaries
bound to references by argument passing are utemps!

No warnings are issued regarding btemps; they become, in essence, auto
variables. whose lifetime is the lifetime of the current block.  So
the first two lines of my code fragment above, would not issue a warning.

Warnings are issued whenever a pointer or reference is taken of a utemp.


This mitigates the warnings a bit, and I think it is reasonably
straightforward for the compiler to figure out.  There will still be
lots of warnings emitted; line 3 of my function will still issue a
warning for example.

Are there any other "pruning" techniques by which we could recognize
"safe" temporaries that don't require aliasing warnings?


--
Robert Martin                        Training courses offered in:
R. C. M. Consulting                       Object Oriented Analysis
2080 Cranbrook Rd.                        Object Oriented Design
Green Oaks, Il 60048 (708) 918-1004       C++
From: rwk@silver.sbi.com (Richard W. Kreutzer Consultant)
Newsgroups: comp.lang.c++
Subject: gdb-4.6 and C++
Date: 29 Aug 92 22:39:56 GMT
Distribution: comp
Organization: Integra Software Corporation

While using gdb-4.6 with g++-2.2.2 I have noticed that printing:

	1. The "this" pointer
	2. Any static member variable (e.g., foo::bar)

is considerably slower than gdb-4.5 is.

Does anyone know why?  Can it be fixed?

Dick
--

--
        Richard W. (Dick) Kreutzer
Net:    rwk@quark.sbi.com				CIS:	70702,2174
Voice:  +1(801)571-2446					FAX:	+1(801)571-2448
Mail:   Integra Software Corp.; 1378 Jasmine Avenue; Sandy, UT 84092 (USA)
Newsgroups: comp.lang.c++
From: bjornmu@idt.unit.no (Bj|rn P. Munch)
Subject: Re: Problem with templates...
Organization: Div. of CS & Telematics, Norwegian Institute of Technology
Date: Fri, 4 Sep 92 15:48:25 GMT

In article <Bu0xvC.6np@usenet.ucs.indiana.edu>, nsundare@silver.ucs.indiana.edu (Neelakantan Sundaresan) writes:
|> 
|> I am trying to separate compile template definitions and use.
|> For instance,
|>  file1.c has
|>  -----
|> 
|> #include <stdio.h>
|> #include <stdarg.h>
|> #include "file1.h"
|> 
|> template <class T> XT<T>::Xtest(T t)
|> { printf("HEE\n");
|>   return 0;
|> }
|> template <class T> XT<T>::XT(){}
|> 
|>  file2.c has
|>  ------
|> 
|> #include <stdio.h>
|> #include <stdarg.h>
|> #include "file1.h"
|> 
|> main()
|> {
|>   typedef XT<int> Y;
|>   Y x;
|>   x.Xtest(4);
|> }
|> 
|>   file1.h has
|>   -------
|> 
|> template <class T> class XT {
|>  public:
|>    XT();
|>    Xtest(T);
|> };
|> 
|> 
|> ------------ On compiling with g++ and linking I get the error
|>  undefined symbol:
|> 	 ___t2XT1Zi 
|>          _Xtest__t2XT1Zii 
|> 
|> But if I have file1.c and file2.c in the same file, everything seems
|> to be okay.
|> 
|> 
|> Any ideas as to what is going on?
|> thanks
|> Neel.

Yes, I've been struggling with a similar problem.  I assume you want
to have the member functions compiled in file.c only.

Well, that does not happen.  You "instantiate" the template in
file2.c, but there the compiler doesn't have the definitions (bodies)
of the member functions available.  In file.c it's the opposite; you
have the body templates, but don't create any instances of them.

What you need to do, is to #include file1.c also into file2.c; then it
should work.

You'll have to include file.c also into all other files that use
instances of XT.  If you want to avoid this, and have the functions
for XT<int> compiled only in one file (but use it in other files), try
this:

In file1.h, say:

> #ifdef __GNUG__
> #pragma interface
> #endif

I'm not 100% sure that is required, but what _is_ required, is to
include this in the .c file where you want to create the functions:

> #ifdef __GNUG__
> #pragma implementation "file1.h"
> #endif
> #include  "file1.c"

This will make g++ spit out global functions, not local (static) ones.
You can use this file to instantiate all the XT's you need, e.g. by:

> typedef XT<int>  intXT;
> typedef XT<float>  floatXT;
> typedef XT<char *>  strXT;

, and you will have all the functions made for you.  In other files,
you can use these by including file1.h, but you don't have to include
file1.c too.

Hope this was comprehensible?  My earlier post about the same topic
was probably too cryptic, sorry.   :-|

Disclaimer: I haven't read this in docs, but found it out "the hard
way".  Works for me with g++ v 2.2.2 on a Sun4 running SunOS 4.1.2.

- BugWriter

---
Bj|rn P. Munch               | Dept. of Comp. Science & Telematics,
Bjoern.P.Munch@idt.unit.no   | Norwegian Institute of Technology (NTH),
PhD Student                  | N-7034 Trondheim, Norway
Univeristy of Trondheim      | Fingerable addr:  bjornmu@multe.idt.unit.no
Newsgroups: comp.lang.c++
Subject: Re: GOTO, was: Tiny proposal for na
From: hosken@spss.com (Bill Hosken)
Date: Wed, 26 Aug 1992 19:45:38 GMT
Organization: SPSS, Inc.

>In article <1992Aug26.130335.26725@hemlock.cray.com>, dsf@cray.com (Dan Frankowski) writes:
>> In article <6800007@tisdec.tis.tandy.com> kevinl@tisdec.tis.tandy.com writes:
>> 
>> >	For experienced programmers, the goto is a legitamite tactic.
>> >There may not be any cases where a goto is absolutly necessary (I've
>> >heard that there are some, but I have yet to see any), ..
>> 
>> I thought that one of the triumphs of the Structured Programming camp
>> was an honest-to-goodness proof that any code using gotos could be
>> replaced by structured constructs and state variables.  I can imagine
>> some such proof by construction from arbitrary code with a goto.
>> 

It is easy to get rid of goto statements.  If you see goto a; just replace it by
callGOTOa(); and then write a little subroutine that does the stuff at a:.

Now this introduces a lot of "recursion" into the program but the result has 
no goto statements.  The resulting program will be more difficult to read and
probably blow the stack limits, but what the heck.

Clear thinking helps to write good code, gotos whether or not.


___________________

Standard disclaimer.
Newsgroups: comp.lang.c++
From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Subject: Re: GOTO, was: Tiny proposal for na
Organization: Texas Instruments Inc
Date: Tue, 1 Sep 1992 19:20:43 GMT

In <rmartin.714931485@thor> rmartin@thor.Rational.COM (Bob Martin) writes:

>So we have rules.  These rules protect us average types from the guys
>who think they are "real good drivers".  When some guy blows a stop
>sign, it doesn't matter to me, one whit, if he is the greatest driver
>in the world, I will still applaud the cop who pulls him over.

But the problem is that, all too often, we lose sight of what we
wanted the rule to do for us and the means BECOMES the goal.  I've
seen this more times than I care to mention when it comes to 'rules'
and their 'enforcement'.

The real rule on 'goto' ought to be something like, "Presence of a
goto in code MAY indicate poorly structured and/or overly complex
code.  Any use of a goto should be carefully examined to determine if
there are not better alternative structures which will be more easily
understood and maintained by others.  If, and only if, this is the
case, use a 'goto'."  Clearly document the purpose and effect of the
jump at both the 'goto' and 'label'.  Avoid jumps from different
places to the same label.  Similar rules for various other
'questionable' or 'abused' constructs.

The argument, "Well, you never NEED to use a goto." is hardly a
justification for not using them, either.  You can also write
everything in the world (wrt 'structure') with only a conditional test
and a jump.  That's hardly a good reason to say that you SHOULD.


-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.
Newsgroups: comp.lang.c++