HDTenEightyP/NetNews huggingface dataset:
From: randall@utopia.resntl.bhp.com.au (Randall Gallimore)
Newsgroups: comp.lang.c++
Subject: Re: Writing AVS Subroutine/Coroutine Modules in C++
Date: 9 Oct 92 07:31:52 GMT
Organization: BHP Research - Newcastle Laboratories

In article <1992Oct6.043501.25763@lgc.com>, srinivas@lgc.com (Manapragada Srinivas) writes:
|> Hi,
|> 
|> 	I am planning to use C++ for implementing a number of AVS modules, both
|> subroutine, as well as coroutine modules. Has anyone had any experience in this
|> matter. Are there any pitfalls I should be wary about? Is it possible at all?
|> 
|> 	I was planning to put the avs routines in an extern "C" block, and write
|> the module itself in C++. I know one can call C routines from a C++ program, but
|> in this case it will somewhat the other way round, since I have to link to the
|> avs libraries, which contain the 'main,' atleast for subroutine modules. Correct
|> me if I am wrong.
|> 
|> 	Any information would in this matter will be greatly apreciated.
|> 
|> Thanks,
|> Srinivas
|> -- 
|> Yonder, beyond the event horizon!

I've been using C++ for most of my coding efforts recently and have just completed
a class to control our Sony laser video recorder. I decided to encapsulate this 
class within an AVS module to facilitate stop frame animations. 

My approach was to wrap C functions around the necessary C++ class member 
functions, use extern "C" definitions around the wrapper function prototypes, then
compile using C++ to give the required object file. Within the AVS routine, I call
the C wrapper functions to do the required work and compile using the standard C
compiler, linking the previously created object file and C based AVS libraries as 
necessary.

This works but is not very elegant, what's really required is to keep the whole
process in the C++ "domain" to avoid creating C wrappers for everything.
Your idea of wrapping the AVS code is a better approach, all that should
be required is to supply prototypes for all AVS routines and wrap them in
extern "C" blocks to avoid name mangling when compiled under C++. As for the AVS
libraries, I'm not sure if they will link ok or whether they would need to be
re-compiled under C++ (if so, we're out of luck as we'd require access to the
source). I'll have to do some experimenting when and if time permits...

Randall  

--------------------------------------------------------------------/\/\-------
Randall Gallimore, Scientist 1, Process Metallurgy Group.          / / /\
BHP Research - Newcastle Laboratories, Australia.                 / / /  \
Mail     : P.O. Box 188, Wallsend 2287                           / / / /\ \ 
Tel      : +61 49 510622  Fax : +61 49 501336                    \ \/ / / / 
Internet : randall@resntl.bhp.com.au                              \  / / /  
-------------------------------------------------------------------\/\/\/------
From: rwk@silver.sbi.com (Richard W. Kreutzer Consultant)
Newsgroups: comp.lang.c++
Subject: My objects are too big - why?
Date: 7 Oct 92 18:28:33 GMT
Distribution: comp
Organization: Integra Software Corporation

I have discovered something most disconcerting.  The following code displays
the sizeof a derived class to be twice what I need it too be:

	#include "iostream.h"
	
	class Base {
	  // a bunch of function definitions - irrelevant to the problem
	  // some are pure virtual functions - which is why I need Base
	  };
	
	class Derived : public Base {
	  int a;
	  // more irrelevant functions
	  };
	
	main() {
	  cout << sizeof(Derived) << '\n';
	  }
	
When executed on a Sparc (with either AT&T cfront 2.1 or gcc-2.2.2)
sizeof(Derived) displays as 8.  It appears that this is due to the following:

1. The required minimum size of a class is 1 which is accomplished by the
   compiler declaring a hidden 1 character instance variable in Base.

2. The "int" variable in Base is aligned on the next 32 bit boundary following
   the hidden 1 character variable inherited from Base.

My questions are:

	Is this intended by the standard?
	Or, is it purely implementational?

	If implementation dependent, are there any implementations which
	allocate 4 bytes for a Derived instance in this case?

	How hard would it be to "fix" gcc or cfront?

	I am deriving from Base because Base is an abstract class and I have
	several Derived classes (each of which is 4 bytes larger than necessary).
	Is there any way (short of buying a new compiler) to work around this
	problem?
--

--
        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: nikki@trmphrst.demon.co.uk (Nikki Locke)
ReplyTo: nikki@trmphrst.demon.co.uk
Subject: Typedef name and variable name clash
Distribution: world
X-Mailer: cppnews $Revision: 1.19 $
Organization: Trumphurst Ltd.
Date: Mon, 5 Oct 1992 15:34:51 +0000

Is the following C++ code legal, or not ?

typedef unsigned color;

class ColoredButton {
	ColoredButton(color &color);
	};

Zortech C++ and Borland C++ like it, MSC 7 does not. The MSC error message
is a little obtuse ...

x.cpp(4) : error C2629: unexpected 'class ::ColoredButton  ('
x.cpp(4) : error C2238: unexpected token[s] preceding ';'

---
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: zen@syl.dl.nec.com (zen kishimoto)
Subject: NIHCL
Summary: Can we sell a product which uses NIH?
Keywords: C++ NIHCL
Organization: NEC Systems Lab., C&C Software Technology Center (Dallas, TX)
Date: Mon, 12 Oct 1992 18:03:24 GMT

If this is a wrong News group to post, I applogize for it.  But I do not know
where I should post this.

I have a question regarding the use of NIH.  We are considering to use NIH
for our product.  Now if we use NIH as is, can we sell the end product
without any problem?  I understand NIHCL came from NIH and is distributed
for free of charge. But can we use it to develop a product and sell the end 
product?  
What if we make an change on NIHCL (value added) and try to sell the end 
product?  Is it leagal?  If not, what should we do?  



-----------------------------------------------------------------
Zen Kishimoto          C&C Software Technology Center (CSTC)
	       NEC Systems Laboratory, Inc.
		       1525 Walnut Hill Lane Irving, Texas 75038
		       Tel:(214)518-3529  NEC*NET:8722-3529
 		       Fax:(214)518-3552  NEC*NET:8722-3552
		       zen@syl.dl.nec.com
-----------------------------------------------------------------
-- 
-----------------------------------------------------------------
Zen Kishimoto          C&C Software Technology Center (CSTC)
	       NEC Systems Laboratory, Inc.
		       1525 Walnut Hill Lane Irving, Texas 75038
Newsgroups: comp.lang.c++,comp.windows.x.intrinsics
From: geoff@netcom.com (Geoffrey Leach)
Subject: NIHCL C++ class library and X11's libXt both use Object
Followup-To: poster
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Sat, 10 Oct 1992 02:27:33 GMT


It appears that there is an unfortunate interaction between the C++
class library NIHCL and X11's Xt intrinsics, in that both declare "Object".
Is there a workaround, or am I missing something?


Geoffrey Leach		geoff@netcom.com

Raise foot.  Aim.  Fire.
-- 
Geoffrey Leach		geoff@netcom.com
Newsgroups: bnr.lang.c++,comp.lang.c++
From: hildum@ntmtv.UUCP (Eric Hildum)
Subject: Re: Is pointer in my address space?
Organization: Northern Telecom Inc, Mountain View, CA
Date: Sat, 10 Oct 1992 03:41:47 GMT

In C/C++, you can check if a pointer is null before use, but not if it is 
pointing to valid memory. This kind of a check is really an operating system
issue, not a language issue (at least, not in languages such as C and C++).
You should look into the memory related system and library calls that are 
available to you, you may find what you need there. Of course, after determing
whether or not the address is valid for the process, you still have the 
problem of deciding if your pointer is pointing to a valid  object.

					Eric
From: snowdond@cs.man.ac.uk (Dave Snowdon)
Newsgroups: comp.lang.c++
Subject: NIHCL light-weight processes on SUN3
Date: 9 Oct 92 17:19:32 GMT
Organization: Dept Computer Science, University of Manchester, U.K.

Has anyone successfully used the NIHCL lightweight process classes on a 
SUN 3 using g++? If so were there any changes that needed to be made to the
source?

The reason I ask is that I need a library of C functions to give me similar
capability to the NIHCL LWP classes. For the current application I can't use
C++ so I am attempting to re-code the functionality of the classes in C,
compiling with gcc. However, there seems to be a problem in restoring the
contents of the stack and I would like to know whether this is due to an
error in my code or is a portability problem with the NIHCL approach.

			thanks
				Dave


-- 
Dave Snowdon
Department of Computer Science   Tel:    (UK) 061 275 5717
Manchester University            E-mail: snowdond@cs.man.ac.uk
M13 9PL U.K.                          or snowdond@uk.ac.man.cs

  The Devil may care... But I don't mind (T.S.o.M.)
Newsgroups: comp.lang.c++
From: euamts@eua.ericsson.se (Mats Henricson)
Subject: Re: Proposal: Preconditions and PostCondit
Reply-To: euamts@eua.ericsson.se
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden
Date: Wed, 7 Oct 1992 10:06:27 GMT

In article 20443@lth.se, dag@control.lth.se (Dag Bruck) writes:
#In <comp.lang.c++> feathers@serss0 (Michael Feathers) writes:
#
#[Discussion of why pre- and post-conditions are useful deleted.]
#
#>I know that proposed features are routinely vetoed if there is some other
#>way of achieving the same effect using the current features of the language.
#
#Isn't ASSERT(3) good enough?  A failed assertion will not tell you the
#name of the function, but it will give you filename and linenumber.
#
#I expect future C++ compilers to implement assertion failure by
#throwing an exception.

A good starting point for a discussion on this could be the article found in
the USENIX C++ Proceedings by Philippe Gautron, Univerite Paris VI, with
the name An Assertion Mechanism Based on Exceptions. I think he makes it a
bit too complicated, but it is an excellent article if you want to get nice
ideas.

Mats Henricson
Sweden
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.c++
Subject: Re: My objects are too big - why?
Date: 8 Oct 1992 19:49:50 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
Distribution: comp
NNTP-Posting-Host: telecaster.think.com

In article <RWK.92Oct7142833@silver.sbi.com> rwk@silver.sbi.com (Richard W. Kreutzer Consultant) writes:
>When executed on a Sparc (with either AT&T cfront 2.1 or gcc-2.2.2)
>sizeof(Derived) displays as 8.

Since you have virtual functions, the size 8 is due to 4 bytes for the data
member of type int and 4 bytes for the virtual table pointer.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.lang.c++
From: werner@dxds02.cern.ch (Per Werner)
Subject: WANTED : Linked list classes for shared memory (shm)
Keywords: shm,  shared memory 
Reply-To: werner@dxds02.cern.ch (Per Werner)
Organization: CERN - European Laboratory for Particle Physics
Date: Fri, 9 Oct 1992 14:41:27 GMT



         Does anyone out there know about a
          CLASS LIBRARY FOR SHARED MEMORY,
                   especially
                  LINKED LISTS.

I'm making a shared memory (shm) data debugger which can display
information on objects in linked lists, so if you have/know of
a tool of this kind, I am of course very interested.
(I forseen a MOTIF based GUI handling a LIST of LISTHEADs
 which are recieved from a SHM BUFFER MANAGER.
 Data will be displayed in gdb style, e.g.,
     "   ..........
     EventId  eventId  0x0800710F
        .........."
)

To do this I need a generic linked list class which links objects
relative to the segment address as mapping of the segment would not
necessarily be the same in all client processes.

If I get enough E-mail answers I will compile and post summary.

 
Thanks in advance
Per E. Werner

Mail address: werner@dxds02.cern.ch
Organization: CERN - European Laboratory for Particle Physics
              ECP Division - Data Acquisition Systems Group
Newsgroups: comp.lang.c++,comp.object
From: a-kevinp@microsoft.com (Kevin Purcell)
Subject: Re: The "has-a" relation in C++ ? How ? 
Date: 16 Oct 92 22:24:44 GMT
Organization: Microsoft Corp.
Keywords: object,C++,has-a

In article <1992Jul21.153014.23296@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU wrote:
> In article <1992Jul20.212525.5081@dsg.tandem.com> narayan@aravali.everest.tandem.com (Pankaj Narayan) writes:
> >Books typically go over the "is-a" relationship in much detail, saying how
> >C++ has this great inheritance mechanism to support this sort of a relationship.
> >
> >However, when it comes to the "has-a" relationship, they don't really talk about
> >or give implementation examples of how that is done in C++.  The Coad/Yourdon
> >OOD book talks a little about it, and says that it can be done in a couple of ways,
> >but does not give any substantial example.
> >
> 	Thats because you already know how to do it.
> 
> 	struct X { 
> 
> 		Y y;
> 
> 	};
> 
> X 'has-a' Y, namely, y.
> 
>         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au

I find this an interesting point, especially because I had the same problem
for some time before reading Tim Budd's book, and a JOOP article contrasting
object collaboration (has-a) to object inheritance (kind-of). I finally got
the Aha! insight when I realised that inheritance is more often thought about last
near the end of the design and collaboration is applied near the begining.
The arrangement of inheritance trees seemed less like rabbit pulled from
a hat and more like a part of a creative design.

It seems that too many dwell on inheritance and not on collaboration. Perhaps
as John comments "we already know how to do it" even if we don't realise it.

If you're teaching OOP its worth keeping this point in mind, as understanding
collaboration and inheritance is the crux of OOP/OOD. People "get it" when 
they understand why and when they would want to use each technique.

Kevin Purcell
a-kevinp@microsoft.com
Newsgroups: comp.lang.c++,comp.object
From: jjamison@bellahs.com (John Jamison RD AC)
Subject: OOPSLA '92 where&when
Organization: Bell Atlantic Healthcare Systems
Distribution: usa
Date: Tue, 13 Oct 1992 22:12:00 GMT

When is the next OOPSLA conference?  Does anybody have
an announcement with details like where, etc?

Thanks in advance,

-John 
-- 
-----------------
John Jamison
Bell Atlantic Healthcare Systems
jjamison@bellahs.com
Newsgroups: comp.lang.c++
From: ctaylor@sparc7.cs.uiuc.edu (Conrad W Taylor)
Subject: Data structures book for C++...????
Organization: University of Illinois at Urbana-Champaign
Date: Sun, 11 Oct 1992 21:49:16 GMT

         I was wondering, could someone recommend a book on C++
using data structures; prefer a textbook type format?  For
example, "Fundamentals of Data Structures Using C" by Horowitz.
I have seen this book in a university bookstore and I'm looking
for something similar for C++.  The books "Algorithms in C++"
and "C++ Components and Algorithms" are not sufficient for my
needs.  Any help would be greatly appreciated.

Thanks in advance,

-Conrad


Newsgroups: comp.lang.c++
From: bytor@grumpy.bellcore.com (Ross Huitt)
Subject: Re: Proposal: Preconditions and PostConditions in C++
Organization: Bellcore
Date: Wed, 7 Oct 92 18:53:50 GMT

In article <1992Oct7.125441.10012@aut.abb.se>, alindbac@aut.abb.se (Anders Lindbck) writes:
|> In article <Bvq8tF.J3C@fiu.edu> feathers@serss0 (Michael Feathers) writes:
|> >I advance this idea with some trepidation... (ooh! noo! new language 
|> >feature!) but has anyone considered adding Eiffel-style pre and post 
|> >conditions to C++?
|> 
|> Yes, and it is rather trivial to do so using macros.
|> 

No, it is not trivial. It may be trivial for C, but not for C++.
See the A++ work of Doug Lea and Marshall Cline for details.
The major problem that prevents macros from being used is inheritance of conditions.
If I have:

class Base {
protected:
   int i_;
public:
   virtual int i(int newI)  { 
      assert(newI > 10 && newI < 100 && i != 0); // precondition
      return i_ = newI;
      }
};

class Derived : public Base {
   int y(int);
public:
   int i(int newI) {
       i_ = newI;       // possible violation of precondition.
       y(i);
   }
};

Problem:
Base::i(int) has specified a precondition. A user is then free to derive a class and redefine
the method and violate the precondition in a way that is never detected. The user must have
the discipline to copy the precondition down everytime the method is redefined. In Eiffel,
at least, pre-post/conditions and class invariants are inherited. 

There are other problems but, IMNSHO, this is the worst of the lot.

Ross Huitt
bytor@ctt.bellcore.com

|> Anders
From: franke@andrej.informatik.rwth-aachen.de (Christian Franke)
Newsgroups: comp.lang.c++
Subject: Re: Another MSC 7 problem
Date: 13 Oct 92 07:52:38 GMT
Organization: Rechnerbetrieb Informatik  /  RWTH Aachen

nikki@trmphrst.demon.co.uk (Nikki Locke) writes:

>The following program will not compile under MSC 7 (it's O.K. under 
>Zortech and Borland). Is it legal C++ ?
>-----------------------------------------------------------
>struct Base {
>	Base();
>	};
>
>struct Command { 
>	int (Base::*f)(); 
>	Command(const Command &);
>	};
>
>Command::Command(const Command &d)
>: f(d.f)
>{
>}

---
>class Base1 {
>	};
>
>class Base2 {
>    };
>
>class Derived : public Base1, public Base2 {
>	};
>
>class Command {
>	int (Derived::*f)(void); 
>	Derived *to; 
>	virtual int doit();
>	};
>
>int Command::doit()
>{ 
>	return (to && f) ? (to->*f)() : 0; 
>}

I checked both with AT&T CFront 2.1 and with GNU C 2.2.2 on a SPARC
and it compiles with no complaint.


>Is anyone interested in these ?

Sure!

>Is there a better place for them ?

I think "comp.os.{msdos|ms-windows}.programmer"

>Needless to say, I do contact MS support when I find them, but I have the 
>feeling it's not doing me any good (they are hardly likely to rush me a 
>bug fix, are they ?). I wish they would accept bug reports via e-mail, 
>it's so much easier than hanging on the phone.

I called MS Munich some weeks ago, they told me that they are
not allowed to give away their E-Mail address.

Regards,

	Christian Franke

	Aachen University of Technology
	Informatik I
	Ahornstrasse 55
	W-5100 Aachen
	Germany
	Tel.: +49.241.80-21111
	E-Mail: franke@informatik.rwth-aachen.de
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: requirement for overloaded operator must have class
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Thu, 15 Oct 1992 13:58:56 GMT

In article <436@ulogic.UUCP> hartman@ulogic.UUCP (Richard M. Hartman) writes:
>I would like some explanation of the reasoning behind the rule
>that an overloaded operator must take at least one parameter
>of as "class" type.

	Overloading say + on numeric types would *always* cause a
redefinition error, since addition of all combinations of
numeric types is already defined.

	Mutating existing definitions is illegal, including for
class types, the so the rule really says that there are some
implicit definitions in existence.
>
>In particular, it would be real convenient to be able to
>overload the (char *) conversion operator for an enum to print the "symbolic" 
>value instead of being forced to be an int.

	Encapsulate the enum in a class.
-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: doug@monet.ads.com (Doug Morgan)
Subject: Re: My objects are too big - why?
Organization: Advanced Decision Systems, Mountain View, CA 94043, +1 (415)
	960-7300
	<1b23cuINN26n@early-bird.think.com>
	<1992Oct09.141039.18062@watson.ibm.com>
Distribution: comp
Date: Fri, 9 Oct 1992 17:31:58 GMT

In article <1992Oct09.141039.18062@watson.ibm.com> mittle@siena.watson.ibm.com (Josh Mittleman) writes:

   That doesn't entirely answer the question.  The same experiment without the
   virtual function shows that sizeof(Base) = 1 and sizeof(Derived) = 8.   Any
   idea why?

   Josh Mittleman (mittle@watson.ibm.com)

C++ guarantees all objects have nonzero size, therefore the nonzero
sizeof(Base).  I've never been able to completely follow the ARM's
statements about subobjects, but I suspect they somehow imply that
memory space for derived classes can't be reused for data members if
already set aside by a base class.  This and (probable) fullword
alignment requirements give the sizeof(Derived) = 8.

Now for some really gross (and one perhaps not so gross) statistics on
memory usage (in bytes) for a few compilers:

g++: 4 * (number of "virtual"'s that appear in class and base class
          declarations
          +
          number of base classes that are virtual and add new virtual
          functions or are not virtual and add the very first virtual
          function to objects of the base class.
         )
       + storage for data

CC: At least quadratic in number of indirect virtual bases (exactly
    how?)
    + 4 * (number of base classes that are not virtual and add the
           very first virtual function to objects of the base class)
    + storage for data

Lucid CLOS: 24 + storage for data

The upshot for C++ is that a programming style using many abstract
virtual base classes can put an almost unbelievably high memory
overhead on each instance.  (What, your "simple" edge object takes 758
bytes and you need 100,000 of them per image?)  As Stroustrup said:
"My impression is that people seriously underestimate the value of
abstract classes."  Unfortunately, current C++ implementions may
justify such underestimates.

doug
--------------------------------------------------------------------
Doug Morgan, doug@ads.com, (415) 960-7300
Advanced Decision Systems (a division of Booz-Allen & Hamilton Inc.)
1500 Plymouth St., Mountain View, CA 94043-1230
--------------------------------------------------------------------