HDTenEightyP/NetNews huggingface dataset:
From: kurr@ctron.com (Ron Kurr)
Newsgroups: comp.lang.c++
Subject: Linking C++ code into a C program
Date: 15 Sep 92 21:47:41 GMT
Reply-To: kurr@ctron.com
Organization: Cabletron Systems, Inc.

Ron D. Kurr kurr@ctron.com

I have C++ code that I would like to reuse in a C environment.  Once I
provide the C interface, I need to link everything together.  C does not
have the facilities to handle static C++ objects.  In a C++ environment,
patch/munch take care of this problem.  How can I reuse C++ code in a C
environment?

One solution is to use Dynamic Link Libraries.  I can give them a
C++ executable that will load a user defined object file at runtime.
The static objects are already set up and the user can add C code.  The
problem is that not all platforms support DLL (Ultrix).

A second solution is to provide a translator process.  The C library
talks to a seperate C++ process.  This process translates calls from C
into C++.  This method solves the patch/munch problem but, obviously,
takes a performance hit.

I would appreciate any other ideas.  I would like a solution that works
on Sun OS4.1, SGI, Solaris, Ultrix and RS600.

Thanks,

Ron
Newsgroups: comp.lang.c++,gnu.g++
From: u895217@bruny.cc.utas.edu.au (Scott Marshall)
Subject: Variable Declarations
Summary: Help!!
Keywords: variables, constructors
Organization: University of Tasmania, Australia.
Date: Thu, 10 Sep 1992 01:51:50 GMT

Hi.
I need a little advice on using C++. When given the following code, would
the variable being declared (and initialised) be re-initialised on every
iteration?

	char buf[whatever];
	f.getline(buf, whatever);
	while (buf[0] != '#') {
		String s = buf;
		if (s.contains("int") ...
		else ...
		f.getline(buf, whatever); }

If this is still ambiguous, I need to know whether, each time round the while
loop, 's' will be modified to have the contents of 'buf', or whether only the
initial read of 'buf' will give 's' its value.
BTW. This is in GNU C++. I'm not sure if the String class is the same for
other C++ compilers.

Any help will save me some time, and will be greatly appreciated.



Scott Marshall.
(u895217@bruny.cc.utas.edu.au)
From: falk@wilbur.coyote.trw.com (Anne Falk)
Newsgroups: comp.lang.c++
Subject: Rogue Wave class libraries
Date: 11 Sep 92 23:54:17 GMT
Organization: TRW Inc., Redondo Beach, CA

Has anyone ever used the Rogue Wave View.h++ class
libraries with a compiler other than SUN?  We are
interested in using View.h++ with Lucid's C++ compiler.
Rogue Wave only supports the SUN compiler for this product
currently on SPARC machines, and has no potential 
dates for supporting LUCID on a SUN at this time.
The only alternative is to do the port ourselves using
their source code which can be purchased.  Has anyone
done this?  If so, how difficult was it?  I can be
contacted at falk@coyote.trw.com. Thanks.
Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
ReplyTo: nikki@trmphrst.demon.co.uk
Subject: Re: Problems with int as enum
Distribution: world
X-Mailer: cppnews $Revision: 1.16 $
Organization: Trumphurst Ltd.
Date: Tue, 15 Sep 1992 11:40:18 +0000


In article <1992Sep13.222623.21562@ra.msstate.edu> cee1@ra.msstate.edu (Charles Evans) writes:

> BC++ 2.0 :
> 
> (Trying to learn some C++ here in my spare time.. well the first real program
> in book I am using, "C++ for C Programmers", has this  [edited for brevity])
> 
> #include <stream.h>
> #include <stdlib.h>  		// optional
> 
> int random(void);
> 
> enum suit { clubs, diamonds, hearts, spades };
> 
> struct card { suit s; int pips };
> 
> ....
> 
> void init_deck(card d[])
> {
> 	for (int i = 0; i < 52; ++i)
> 	{
> 		d[i].s = (i / 13);   // enum as int ? -- WARNING #1
You are assigning an integer to an enum. You need a cast here ...
		d[i].s = (suit)(i / 13);

> 		d[i].pips = 1 + i % 13;
> 	}
> }
> void shuffle(card d[])
> {
> 	for (int i = 0; i < 52; ++i)
> 	{
> 		int k = random() % 52 	// choose a random card
You have a missing semicolon here, which causes the other errors ...
		int k = random() % 52; 	// choose a random card

> 		card t = d[i];		// swap two cards ERROR #2, #3
> 		d[i] = d[k];
> 		d[k] = t;		// ERROR #4
> 	}
> }
> ...
> -----
> 
> WARNING #1 : Assigning int to suit in function init_deck(card far*)
> ERROR #2 : Undefined symbol 'card' in function shuffle(card far*)
> ERROR #3 : Undefined symbol 't' in function shuffle(card far*)
> ERROR #4 : Undefined symbol 't' in function shuffle(card far*)
> 
> ---
---
Nikki Locke              |                        | nikki@trmphrst.demon.co.uk
Trumphurst Ltd.          | Tel: +44 (0)691-670318 | nikki@cix.compulink.co.uk
PC and Unix consultancy  | Fax: +44 (0)691-670316 | nikki@kewill.co.uk
trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.
Demon.co.uk is a dial-up subscription access point to the Internet.
Newsgroups: comp.lang.c++
From: eric@tfs.com (Eric Smith)
Subject: Re: FULL HOUSE
Organization: TFS
Date: Sun, 13 Sep 1992 20:25:32 GMT

In article <1992Sep13.144315.24892@wuecl.wustl.edu> ppc1@cec1.wustl.edu (Peter Pui Tak Chiu) writes:

[poker program with bug]

Your bug is caused by an invalid assumption about the probabilities.
Imagine a 52-card deck, and deal 5 cards, one at a time.  The
probability that the first card will be an ace, for example, is 1/13.
But if it is, then the probability that the 2nd card will also be an
ace is only 1/17.  But your program assumes the probability remains
1/13.
From: rvenu@phoenix.sni-usa.com (Ramakrishnan Venugopal)
Newsgroups: comp.lang.c++
Subject: NIHCL and X11
Date: 9 Sep 92 16:53:40 GMT
Reply-To: rvenu@phoenix.sni-usa.com (Ramakrishnan Venugopal)
Organization: Siemens-Nixdorf Information Systems, Inc. Cambridge, MA



Both NIHCL and X11 both use Object as class name. In the case of X11
it is a struct.  So my C++ compiler complains when I have to use them together.
Has anyone tried to work around this problem?

thanks

venu
Newsgroups: comp.lang.c++
From: mike@taumet.com (Mike Ball)
Subject: Re: inline virtual functions
Organization: TauMetric Corporation, San Diego
Date: Tue, 15 Sep 1992 15:21:47 GMT

In article <1992Sep15.023336.1403@cs.brown.edu> sdm@cs.brown.edu (Scott Meyers) writes:
>For all the compilers with which I am familiar, inline virtual functions
>are oxymoronic:  the function bodies are never inlined, and the object file
>for each translation unit seeing the definition of the function receives a
>static copy of the function.  I tested this using cfront 3.0 and g++ 2.2.2,
>and both behaved as I have described, neither issuing a warning about not
>inlining a function.

In the case of both cfront and our own compiler inline virtual functions
will be generated inline when the compiler can determine the exact function
to execute.  This can be quite hard to determine for a virtual function, but
you can test this on your own compiler by writing A::f() instead of f().
Different compilers go to different amounts of trouble to make this
optimization.

In the example below,

struct s {
  virtual int f();
  inline virtual int g() {return 1;}
  s(){}
};

extern s* sp;
extern int i, j;

void foo() {
    s sv;
    i = sv.g();
    j = sp->g();
}

Our own compiler generates a non-virtual call to initialize i and a virtual
call to initialize j.  I was surprised to discover that cfront 3.0 generates
virtual calls in both cases.

>Many people have discovered this behavior in current compilers, and so the
>following rule is widely followed: "never define an inline virtual
>function."  This is a pity, because it's the kind of rule that is easy to
>remember, hence people will continue to follow it even when C++ compilers
>become agressive enough in their optimization to be able to generate
>inlined calls to virtual functions.

Inlined polymorphic calls to virtual functions are unlikely unless the
compiler is applying specialization techniques or has global knowledge of
the program.  In fact, though, declaring them inline does no harm unless tools
like the debugger can't handle inline functions.

>I was involved in a discussion of this issue today when it was suggested
>that compilers should generate only a single copy of an out-of-line virtual
>function, and that the single translation unit in which the function
>definition should be generated should be the same as the one containing the
>class's vtbl.  This seems sensible to me, so I was wondering: is there some
>reason why compiler implementers don't do this?

No.  In general, that's what will happen.  Both cfront and our own compiler
do exactly that in the case above.

-- 
Michael S. Ball (mike@taumet.com)
TauMetric Corporation
Newsgroups: comp.lang.c++
From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Subject: Re: GOTO, was: Tiny proposal for named loops.
Organization: Texas Instruments Inc
Date: Wed, 9 Sep 1992 21:06:32 GMT

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

>kers@hplb.hpl.hp.com (Chris Dollin) writes:

>|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''? 

>Only that it has been proven that gotos are unecessary.  That any
>algorithm can be written in terms of sequence, selection and
>repetition.

And I will reiterate that the fact that something has been proven to
be possible does NOT necessarily mean it is always a good idea.  As I
said before, one can also implement any algorithm in terms of 'goto'
and a conditional jump.

>Yes, so lets forget the psychological part and focus on the
>mathematical part.  Constructiong your algorithms based on SP causes
>you to separate paths that you might otherwise combine (with gotos).
>This separation decouples the paths from each other, so that changes
>made in one path do not affect the other paths.

The fact that goto CAN be abused is hardly a good rationale for saying
that it is always bad, either.  

>We don't use SP because it makes the code "prettier" or
>psychologically more gratifying.  We use it because it separates the
>code fragments and reduces coupling.  This makes the code easier to
>maintain.

Sorry, but that's hardly the reason.  Where is the 'coupling' or the
difficulty in maintenance when goto is used for things like error
handling or error returns?  Frankly, I find those Pascaloid disasters
of code containing an 8-deep nesting of 'if' and flags to be a lot
less readable and a lot less maintainable than code that makes
judicicious use of what you would categorize as 'bad' constructs.  I
don't think I'm alone in this (or even in the minority, if you want
the truth).

>|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.

>Agreed.
>The last thing I advocate is a reduction of all code to one linear
>stream of sequence, selection and repetition.  

But that is exactly your rataionale for why structured programming
'works'; that it is possible to implement anything using sequence,
selection, and repetition.

-- 
"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++
From: RICHARD@CLYDE.ttt.kth.se
Subject: Re: HELP: aggregate type question.
Organization: Department of TeleTransmission Theory
Date: Wed, 9 Sep 1992 13:05:41 GMT

In article <RICHARD.92Sep7210203@CLYDE.ttt.kth.se> RICHARD@CLYDE.ttt.kth.se writes:
I had this problem with aggregate typedefs failing to be that!

I must say I feel somewhat stupid. It was a recursive inclusion of header files
which caused the problem, and thus, I got a reference to a struct before it was
defined.

And yes, I DO form my header files like this:

	#ifndef _HEADER_H
	#define _HEADER_H
	...
	...
	#endif

so the error was more subtle than that.

Anyway, thank you for the help, and sorry for the waste of net.bandwidth.

--
!+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++!
! Richard Levitte, System manager       ! tel: int+46-8-790 64 23           !
! Royal Institute of Technology         ! fax: int+46-8-791 76 54           !
! Department of Teletransmition Theory  ! Internet: richard@ttt.kth.se      !
! S-100 44 Stockholm, Sweden            !                                   !
!---------------------------------------------------------------------------!
Newsgroups: comp.lang.c++
From: interran@uluru.Stanford.EDU (John Interrante)
Subject: Re: Pointer or Reference Arguments
Organization: Stanford University
Date: 7 Sep 92 22:53:51

In article <rmartin.715871185@thor>, rmartin@thor.Rational.COM (Bob Martin) writes:
> |1) Reference arguments are used only when aliasing 
> |occurs and the parameter is used only during the 
> |lifetime of the function. Pointers are used whenever the 
> |function might keep a copy of the pointer for later use, 
> |e.g., store it in a private list.

> |2) Reference arguments are used whenever you must supply 
> |a valid object to the function. Pointers are used when 0 
> |might be a valid parameter as well.

> My objection to style 1) is that it must compete with zero pointers.
> i.e. an argument which qualifies as a reference under fule 1) might
> still have to be a pointer if it can be zero...

What do you do if you have to keep around a pointer to the object for
later use *and* the caller must always supply a valid object?  If you
use a reference parameter, then you have to take the address of the
reference inside your function.  That opens the door for havoc if the
caller unsuspectingly passes a stack-allocated object.  If you use a
pointer parameter in such cases, then I have no objection.
--
John Interrante / interran@uluru.stanford.edu
Computer Systems Laboratory, Stanford University
From: ziane@nuri.inria.fr (ziane mikal -)
Newsgroups: comp.lang.c++
Subject: Sigh. So, what is a proper class definition ?
Date: 15 Sep 92 17:41:34 GMT
Organization: INRIA Rocquencourt,Le Chesnay, France.

Since nobody replied to the article reproduced below I infer that
posting it in another group might be better.
Any idea ?

Thanx in advance (Mikal.Ziane@inria.fr)


----------------------------
Since nobody replied to my previous posting I'll rephrase differently.

The main motivation is due to always increasing class public parts
while my application is getting more developped.

Is it normal to have a class interface increase constantly ?
I find it very annoying because it becomes very hard to undersatnd
the meaning of the class.

I have the fealing that the interface should be defined once and be
as stable as possible, but I always need more functionality.
The pb is that this functionality could be put outside of the interface
sometimes but it is convenient or efficient to use a public method
rather than a non-member function.


Also, it is not so easy to decide what must be part of the definition
and what must not.
For example if I want a class List with only const objects I have a problem 
to define what a list is. A list can be recursively defined in terms of
a simpler one. Should I define a constructor for each "axiom" of such
a definition ?
For example "insert" would be forbidden, but how shall I define complex
lists ?

Mikal
-----------------------------
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Destructors and exit()
Organization: TauMetric Corporation
Date: Sat, 5 Sep 1992 15:33:09 GMT

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

|The destructors for static objects should be invoked when you call
|exit.  However the destructors for objects which are declared as
|'auto' variables (on the stack) in the function which calls exit,
|probably will not get invoked...
|...  I say probably, because a clever compiler might be
|able to figure out that, upon exit, the enclosing stack frames should
|be destroyed.

Auto objects are NOT destroyed when exit() is called, only static
objects which have been constructed.  My copy of the ARM is not handy,
and I don't remember whether the bit about auto objects is clearly
stated there.  It is made explicit in the C++ Committee Working Paper,
and it is very safe to assume the final Standard will say that.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c++
From: pat@frumious.uucp (Patrick Smith)
Subject: Re: C++ Variable Argument Lists (,...)
Date: Thu, 10 Sep 1992 00:25:46 GMT
Reply-To: uunet.ca!frumious!pat
Organization: None

acanter@sdcc3.ucsd.edu (Adriaan Canter) writes:
|Is there any way that a function with a variable argument list
|(as indicated by ellipses) can tell how many variable arguments have
|been passed to it?

There is no portable way (at least, none that I know of).

But if you're willing to accept a maximum number of arguments,
then there are a couple of solutions.


First, if there is a value that can't be legally used as an
argument, then you can do something like this:

   void foo(int arg1 = 0, int arg2 = 0, int arg3 = 0, int arg4 = 0);

and have foo() ignore any arguments that are set to 0 (or whatever
illegal value you use).


Second, you can have the main function call another function that
does the actual work:

   void bar(unsigned number_of_arguments, ...);

   inline void foo()
      { bar(0); }
   inline void foo(int arg1)
      { bar(1, arg1); }
   inline void foo(int arg1, int arg2)
      { bar(2, arg1, arg2); }
   // etc.

Actually, you don't need bar(); you could just have several overloaded
versions of foo(), with each one doing all the necessary work.
But this duplication of code could quickly become tiresome.

-- 
Patrick Smith
uunet.ca!frumious!pat
pat%frumious.uucp@uunet.ca
Newsgroups: comp.lang.c++
From:  David Tolpin <dat@infos.msk.su>
Subject: Re: can I 'delete' without a 'new'?
Date: Sun, 6 Sep 1992 17:00:05 GMT
Reply-To: dat@infos.msk.su
Organization: InfoSoft (Echo2News)

Hello peter@kentrox.uucp!

Friday September 04 1992 17:10, peter@kentrox.uucp wrote to All:

 pu:> I can't seem to find any references which indicate whether I can do this
 pu:> or not, so I'm appealing to the net.wisdom.  Here's what I've got:

 pu:> class foo {
 pu:>   char *String;
 pu:> public:
 pu:>   foo();
 pu:>   foo( char * );
 pu:>   ~foo();
 pu:>   void set( char * );
 pu:> };

 pu:> foo:foo() { };


 pu:> foo:~foo() {
 pu:>   delete [] String;
 pu:> }

 pu:> The question is what will happen if I create a foo with the empty
 pu:> constructor and never call 'set'?  Since 'new' has never been called,
 pu:> what will 'delete' try to delete?  Looks like a real good way to frazzle
 pu:> the system.  Yes?  No?

1.Initialize pointers that are not allocated in the constructor. foo::foo() { 
String = NULL; }

2.After deleting a pointer that in a place other than destructor, assigns NULL 
to it.

David Tolpin, Moscow, Russia

--- GED
 * Origin: << David Tolpin from Northern Hills, dat@infos.msk.su > (66:66/0.7)
From: haydens@bullwinkle.juliet.ll.mit.edu (Hayden Schultz x3685 g42)
Newsgroups: comp.lang.c++
Subject: Re: zero-length datatype
Date: 10 Sep 92 02:57:05 GMT
Reply-To: haydens@juliet.ll.mit.edu
Distribution: comp
Organization: M.I.T. Lincoln Lab - Group 42

In article <4947@holden.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:

   tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
   : In article <MCGRANT.92Sep7142456@rascals.stanford.edu> mcgrant@rascals.stanford.edu (Michael C. Grant) writes:
   : 
   :    I don't understand why those 4 bytes are causing you such a stink. Perhaps
   :    you could enlighten us as to why a truly zero length data type is even
   :    necessary?
   : 
   : Under the current rules,
   : 
   :       struct nothing {};
   :       HashTable<int,nothing> table(1000000);
   : 
   : table takes up 8Mbytes (on most machines). If you could write
   : 
   :       HashTable<int,void> table(1000000);
   : 
   : table takes up 4Mbytes.

   Note also that the "minimum 4 bytes" effect multiplies, if
   a class has more than one "void" data member:

   // This is not legal C++ code, "void" means "zero-size type"
   class C {
	   long i;
	   void a,b,c,d,e;
   };

   On common implementations, 1 million such objects take up
   24 MB (since a-e take up 4 bytes each), whereas Thomas's
   proposed 'void' type means only 4 MB would be needed.
   Quite a difference!

It's implied in this discussion that code better not either assign to
or rely upon the value of a zero-size data member. Maybe I'm missing
something, but why can't you use unions for this?


#include <stream.h>

typedef long	Ignore;

union C {
    long	i;
    Ignore	a,b,c,d,e;
  public:
    int		Size() { return sizeof(*this); }
};

main()
{
    C	cobj;

    cout << "sizeof(C) is " << cobj.Size() << endl;
}

It prints:

sizeof(C) is 4


I don't know what is supposed to happen if you use or assign to a
mythical zero-size datum, but it's awfully clear what will happen if
you use or assign to a-e in the union above. You can protect them
by making them private.

You really shouldn't have to resort to zero-length data types anyway.
I remember some code posted for a template HashTable class. It went
something like this:

template<class Key, class Value>
class HashTable {
  public:
    Value	lookup(const Key &) const;
    void	add(const Key &);
    int		in_table(Key &) const;
};

Please forgive any stupid template errors, my compilers don't have
them yet. You should be able use abstraction to avoid this problem:

template<class KeyNode>
class HashTable {
  public:
    KeyNode	lookup(const KeyNode &) const;
    void	add(const KeyNode &);
    int		in_table(KeyNode &);
};

This class assumes that KeyNode::Value() and KeyNode::Key() functions
are used to access the key and value.  When you want to only use the
Value(), then you can write your KeyNode class:

class NoValue {
  protected:
    long	i;
  public:
    long	Key() const { return i; }
    void	Value() {
	cout << "NoValue::Value(), Gee, I guess I really did need a value!"
	    << endl;
	abort();
    }
};

	Hayden Schultz
	MIT Lincoln Lab
	haydens@juliet.ll.mit.edu
	haydens@atc.ll.mit.edu
Newsgroups: comp.lang.c++