HDTenEightyP/NetNews huggingface dataset:
Distribution: world
Subject: Re: run-time type checking)
X-Mailer: cppnews $Revision: 1.14 $
Organization: Trumphurst Ltd.
Date: Fri, 14 Aug 1992 13:25:17 +0000


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

> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
> :
> :There are other ways than tagged pointers to make downcasting
> :sound. One might be to declare the derived classes that you want
> :to downcast to in the base class FROM which you want to downcast:
> :	class Base { //....
> :		operator Derived1*() =0;
> :		operator Derived2*() =0;
> :	};
> :Now what does this do? Well, it preserved th open/closed principle
> :and encapsulation and the explicit interfaces principle.
> 
> What if someone using your classes decides to add a Derived3 class
> to which downcasting should be possible?  He must modifiy your
> class Base, for which he may not have source code.
> 
> Does not (help) preserve the open/closed principle at all, IMHO.
Perhaps I misunderstand the meaning of the "open/closed principle", but I 
understood that it implies that every operation which can be applied to an
object through a reference or pointer to a Base class should be visible in 
the Base class declaration. An excellent example was presented earlier in 
this thread (but I have expired it, so I'll have to make up a new one).

class Base {
protected:
	int i;
public:
	int get() const { return i; }
	};

class Derived {
public:
	void set(int j) { i = j; }
	};

Now, if downcasting is not allowed, we can guarantee that any operation on
a Base pointer or reference will not modify i. I understood this to be one
of the requirements of the open/closed principle.

As soon as you allow downcasting to class Derived, i may be modified. This
violates (what I understand to be) the principle.

Of course, if you state clearly in the declaration of Base that it may be 
converted into a Derived, you are also stating that i may be modified 
through a Base pointer/reference.

The original poster suggested that some new syntax be invented to state 
this intention. Max's post explained (albeit with a slightly incorrect 
example :-) that no new syntax was needed, just a few (virtual) functions 
in the Base class.

Corrections of any incorrect understanding on my part welcome.
---
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 connected with ANY other sites at demon.co.uk.
Demon.co.uk is a dial-up subscription access point to the Internet.
From: fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Downcasting (was: Re: run-time type checking)
Keywords: polymorphism, RTTI, downcasts.
Organization: Computer Science, University of Melbourne, Australia
Date: Fri, 14 Aug 1992 21:52:24 GMT

adk@Warren.MENTORG.COM (Ajay Kamdar) writes:
>Making the Derived?* functions pure virtuals in the base class also
>forces each derived class to know about its sibling classes. No good.

Yes, that would certainly be a bad idea; I think it was a typo in maxtal's
original post.
ie.	
 	virtual Derived *() = 0;
should have been
	virtual Derived *() { return 0; }

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature VIRUS is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Newsgroups: comp.lang.c++
From: shirleyk@qualix.com (Shirley Kumamoto)
Subject: Re:  SQL and C++
Followup-To: info@qualix.com
Keywords: SQL C++ database
Reply-To: shirleyk@qualix.com
Organization: QUALiX Group, Inc.
Date: Thu, 13 Aug 1992 20:01:53 GMT

In article 22049@nestroy.wu-wien.ac.at, staferne@risc.uni-linz.ac.at (Stefan Taferner) writes:
>We're going to include a SQL database in our C++ application.
>Namely, it's an Oracle database.  I haven't yet written database 
>access functions in C++, and my knowledge of combining both is
>two years old. Two years ago, it was necessary to write SQL-C functions
>and to call this adapter-functions from C++.
>
>Are there other possible methods ? 
>Has anybody experience with SQL in C++ ?
>
>I would be happy to get even the smallest hints / how to do's.
>
>----
>Stefan
>


The Qualix Group has a product called db++ that may be of help
to you.  db++ is a C++ class library for application developers.
It gives the developer a C++ API to a wide variety of databases
(Oracle, Sybase, etc) and hence makes porting your application
easy.  If you are interested in more information, send email to 
or call:
Qualix Group
info@qualix.com
(415) 572-0200 (v)
1-800-245-UNIX (v)

Newsgroups: comp.lang.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Garbage Collection for C++
Organization: Computer Science, University of Melbourne, Australia
Date: Tue, 18 Aug 1992 04:12:12 GMT

tmb@arolla.idiap.ch (Thomas M. Breuel) writes:

>Incidentally, there is a widely used, simple, efficient, more general,
>and completely portable technique for getting the same kinds of
>storage savings as with the XOR trick.

Well, don't keep us in suspense, please explain!

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature VIRUS is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
From: vinoski@apollo.hp.com (Stephen Vinoski)
Subject: template static data members
Originator: vinoski@zep_r.ch.apollo.hp.com
Date: Mon, 17 Aug 1992 22:20:05 GMT
Organization: Hewlett-Packard Company, Apollo Division - Chelmsford, MA


No else seems to have reported this problem, so I thought I'd share it
with the net.

Given these declarations:

	class Simple
	{
	  public:
	    Simple() { // ... }

	    // rest of class...
	};


	template<class T>
	class LessSimple
	{
	  public:
	    // rest of class...

	  private:
	    static Simple s;
	};

and this definition for the template static data member:

	template<class T> Simple LessSimple<T>::s;

Some compilers derived from cfront 3.0 won't be able to handle the
instantiation of the ``s'' data member template correctly, and will
complain about unresolved template references at link time.

The problem is due to the fact that uninitialized static data members
are put into the bss section, and the template instantiation system
does not search the bss section in order to resolve template
references.  The reason the bss section is not searched is because the
language rules state that static data members must have one definition
per program.  If the definition does not appear, the compiler adds the
symbol to the bss section, and therefore missing definitions can be
detected simply by not searching bss.  Good try, but...

Of course, this problem can be avoided by explicitly initializing
static data members in their definitions, so that they wind up in the
data section rather than in bss.  Unfortunately, in the example case
above, ``s'' cannot be explicitly initialized, and the problem cannot
be solved without changing the declaration of Simple so such
initialization is allowed (if possible).

-steve
-- 
Steve Vinoski  (508)436-5904   vinoski@apollo.hp.com
Distributed Object Computing Program
Hewlett-Packard, Chelmsford, MA 01824       These are my opinions.
Newsgroups: comp.lang.c++
From: pjl@sparc10.cs.uiuc.edu (Paul Lucas)
Subject: Re: References as class members
Organization: University of Illinois at Urbana-Champaign
Distribution: usa
Date: Tue, 18 Aug 1992 04:26:40 GMT

In <1992Aug16.221328.4934@sunb10.cs.uiuc.edu> pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:

>In <LVI.92Aug14161521@aste27.ida.liu.se> lvi@ida.liu.se (Lars Viklund) writes:


>>Is the following class declaration legal?

>>class X {
>>    X& r;
>>};

>*****>	Yes.

*****>	I read the question bass-ackwards...could have *sworn* it said 
	illegal.  Now then, given ARM 12.6.2 and some inferrential
	ability, it's not (currently) legal.

>>According to ARM it should be OK, but the ObjectCenter 1.1 compiler
>>and Sun CC 2.1 claims that the reference must have a constructor.

>*****>	And they're both correct.

>>GCC compiles it without complaining.

>*****>	Then GCC has a bug.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Garbage Collection for C++
Date: 20 Aug 92 21:22:00 GMT
Organization: Microsoft Corporation

In article <1992Aug18.045533.7193@actrix.gen.nz> Bruce.Hoult@bbs.actrix.gen.nz writes:
|In article <TMB.92Aug17204854@arolla.idiap.ch> tmb@idiap.ch writes:
|> 
|> Incidentally, there is a widely used, simple, efficient, more general,
|> and completely portable technique for getting the same kinds of
|> storage savings as with the XOR trick.
|
|Well you can trivially subtract the pointers instead of XORing them.
|That would be more portable in practise, although I don't think ANSI C
|guarentees that you can subtract arbitrary pointers. but only ones to
|elements of the same array or struct.

There are Order(100,000,000) computers in the world where subtracting pointers
not to the same array will not produce the results you desire.  -- Not to imply
XORing pointers is a good idea either!   If you want to write portable
code, start by making no assumptions equating pointers to ints.  Historically,
any code that hacks pointer bits sooner or later proves to be a stumbling
block.
Newsgroups: comp.lang.c++
From: niklas@appli.se (Niklas Hallqvist)
Newsgroups: comp.lang.c++
Subject: Re: Garbage Collection for C++
Date: 19 Aug 92 09:01:44 GMT
Organization: Applitron Datasystem AB, GOTHENBURG, SWEDEN

tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
>Incidentally, there is a widely used, simple, efficient, more general,
>and completely portable technique for getting the same kinds of
>storage savings as with the XOR trick.

Is it GC safe as well?
-- 
Niklas Hallqvist	Phone: +46-(0)31-40 75 00
Applitron Datasystem	Fax:   +46-(0)31-83 39 50
Molndalsvagen 95	Email: niklas@appli.se
S-412 63  GOTEBORG, Sweden     mcsun!seunet!appli!niklas
Newsgroups: comp.lang.c++
From: pradeep@tdd.sj.nec.com (Pradeep Badri)
Subject: Task Library Interrupt Handler.
Keywords: Task Library
Organization: NEC-AM TDD, San Jose, California
Distribution: usa
Date: Mon, 17 Aug 1992 23:12:52 GMT

Hello,

I am using AT&T C++ 2.1 Task Library in building my software.
I have already developed a major part of the s/w.  Now, I needed
to implement a timer which I can use for timeout operation. and would
simulate timeout in Real Time.  I started off by using the 
timer class provided in the task library itself.  But I found out that 
the system clock advanced in an arithmetic way i.e. if a task calls 
delay(50), and assuming all other tasks are blocked, the delay call 
returns immediately and system clock advances by 50.  There is no
hook provided so that we can make timer class run on real time.

So I decided to use the interrupt_alerter task using alarm calls which
generates SIGALRM signal.  I have written my own timer object but I have 
some basic problem.  To explain my problem in a nutshell :

        -----------------------------------------------------
        #include "task.h"

        main()
        {
                Interrupt_handler hdlr(SIGALRM) ;

                thistask->wait(&hdlr) ;

        }

        // I have not not used alarm() system call.  So a SIGALRM
        // would never happen.  Hence wait on hdlr would block main
        // task  forever.
        -----------------------------------------------------

        
So my problem is: If I compile and trace the program execution, I find
        that the wait4(......) system call  is made once  main gets blocked .  
        CAN ANYONE LET ME KNOW WHY THIS wait4() IS CALLED.
        In the above case, since there is no child spawned, so the 
        wait4 returns -1 and everything goes fine.
        But If I do fork and exec before main gets blocked , wait4() 
        suspends the entire process  till the child exits.  

I HOPE I EXPLAINED MY PROBLEM.  IT MAY BECOME CLEARER IF YOU COMPILE 
ABOVE PRGM AND TRACE IT.  I WOULD BE VERY HAPPY IF SOMEONE HELPS ME.

PLEASE REPLY TO MY EMAIL ADDR. 
EMAIL::  pradeep@tdd.sj.nec.com
Phone::  408-433-2904.(Pl. leave your number in my voice mail).
 
Thanks a lot.                        (Pradeep Badri).
Newsgroups: comp.lang.c++
Subject: Shouldn't initgraph() work???
From: achaboty@desire.wright.edu
Date: 20 Aug 92 00:38:06 EST
Organization: Wright State University 

	Bonjour.  I'm using BC++ 3.1 and can't get the function initgraph
to find the egavga.bgi file (I keep getting a -3 return value for gdriver
when initgraph is called).  I tried moving the program into the BGI
subdirectory and into the LIBRARY subdirectory, but neither one worked.  The
radio button to enable the graphics driver (option|linker|libraries) has
been checked and the program does compile, yet never wants to run.
	Even when I run the exmple program given by Borland (bgidemo.c), I
still get an error message.  I have tried just about everything I can think
of except the right way.
	Has anyone ever had a similar problem and what can I do to resolve
it?
	Thanks a lot!

P.S.  Is it possible to link any .obj file with a C++ .obj file?
   Specifically a turbo basic program used to control a BOCA printer?  If so,
   how can this be done, or would it be possible to execute that TB program
   while still running the C++ .exe?  Thanks again for your help.

				--- Andrew


+=-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-=-=-=-=+
|  Andrew Chaboty   |  achaboty@desire.wright.edu   |   Why in the world    |
|   "Gamahuche"     |   Wright State University     | would I want to speak |
|     KB8LUQ        |        Dayton, Ohio           | for this university?  |
+=-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-=-=-=-=+
Xref: sparky comp.lang.c++:12337 comp.std.c++:1082
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: Language extensions for run-time type identification
Date: 14 Aug 92 16:54:47 GMT
	<1992Jul24.141611.19647@cadsun.corp.mot.com>
	<1992Jul26.014223.6153@uunet.uu.net!mole-end>
Reply-To: tmb@idiap.ch
Followup-To: comp.lang.c++
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: mat@uunet.uu.net!mole-end's message of 26 Jul 92 01:42:23 GMT

In article <1992Jul26.014223.6153@uunet.uu.net!mole-end> mat@uunet.uu.net!mole-end writes:

   How about this:

   [1]	   Derivation is only useful when used properly with virtualization.
   [2]	   Virtualization is only meaningful in the context of derivation.
   [3]	   Only derivation can make use of RTTI.
     therefore
	   RTTI is only useful in the presence of virtualization.

All your premises are wrong.

 (1) To the limited extent that derivation is useful at all,
     derivation is useful for reuse of functionality even in the
     absence of virtual functions. I use derivation in C++ more
     frequently than virtual functions. Other languages (Oberon,
     CommonLisp DEFSTRUCT, SML) offer derivation without
     virtualization.

 (2) It does make sense to "virtualize" without derivation: you get
     something similar to overloading in C++, except that the
     "overloading" is resolved at runtime. There needs to be no
     inheritance relationship among the types participating in this.
     Among others, CLOS lets you do this.

 (3) Users of Lisp and similar languages have made use of RTTI since
     before derivation even became a concept in programming languages.

The limitations C++ has in all these areas are consequences of
its heritage and the desire to have low-overhead implementations. But
please let us not re-define reality to fit the special circumstances
of the C++ programming language.

					Thomas.
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: destruction of temporaries
Date: 20 Aug 92 23:06:52 GMT
Organization: Microsoft Corporation

In article <TMB.92Aug19113657@arolla.idiap.ch> tmb@idiap.ch writes:
|I don't want my temporaries to hang around until the end of the
|function. I often use large temporaries (megabytes), and I see no
|reason why they should stick around any longer than I need them.

No one disagrees with this statement.  The issue is when should temporaries
be allowed to stay around any shorter than you need them.
Newsgroups: comp.lang.c++
Subject: Free Class Library that uses Templates?
From: Robert.Biddle@comp.vuw.ac.nz (Robert Biddle)
Date: Mon, 17 Aug 1992 00:55:01 GMT
Reply-To: Robert.Biddle@Comp.VUW.Ac.NZ
Organization: Victoria University


Is there a freely available general purpose class library
(data structes etc.) that uses templates?

The GNU libg++ is still pre-template, although with macros
that suggest templates -- I hear that the main libg++ maintainer
is not working on a change to templates.

I am aware of the Borland BIDS, but I cannot re-distribute it
freely.

Anything else out there?

Robert
Newsgroups: comp.lang.c++
From: lam@saifr00.cfsat.honeywell.com (Josh Lam)
Subject: Re: Is C++ "for the rest of us" ?
Organization: Honeywell Air Transport Systems Division
Date: Mon, 17 Aug 92 15:41:33 GMT

I would definitely recommend sufficient training for your team of
programmers if they have little or no prior experience in C++ before they
plunge into the C++ project.  

Like you mentioned, using C++ requires a new way of thinking.  My collegues
and I found that out the hard way. I think the issue here is shifting to
object oriented design and object oriented programming.  Make sure you have
a good object oriented design! If used properly, C++ is a very powerful
and elegant language.  Also, it is fairly easy to interface with existing C
programs and many commercial software written in C.

Having a good, reliable and experience C++ consultant can be a good idea
especially when you need someone to fall back on.


Hope that helps and good luck.

-- 
Josh Lam
Honeywell Inc
lam@saifr00.cfsat.honeywell.com
Newsgroups: comp.lang.c++
From: vadim@cix.compulink.co.uk (Vadim Lebedev)
Subject: Re: Virtual Functions and Shar
Reply-To: vadim@cix.compulink.co.uk
Date: Wed, 19 Aug 1992 16:44:38 +0000


TITLE: Virtual Functions and Shared Memory

In artcile  <1992Aug17.182423.14341@msuinfo.cl.msu.edu>
 baldwin@cps.msu.edu (Reid A Baldwin)
  writes:

> 
> I am developing an application in which multiple processes communicate
> via shared memory (UNIX). Unfortunately, virtual functions don't work for
> objects in shared memory. The process that creates an object gets the
> correct results, but other processes execute the function for the
> base class instead of the derived class (using the pointer type instead
> of the object type). I am not familiar with the implementation of virtual
> functions. Is it possible to use virtual functions on objects that are
> created by other processes and accessed via shared memory?
> 
> Thanks for your help,
> Reid Baldwin
> 
> P.S. I will post a summary of responses if they are interesting.
> 
> 

Well, you can put ALL the methods for shared objects
in sharable library. This works for Windows, it should work fro UNIX too.

-----------------------------------------------------------------------
Vadim Lebedev                      |   Kortex International
vadim@cix.compulink.co.uk          |   139-147 av. Paul-Vaillant Couturier
                                   |   93126 La Courneuve - CEDEX, France




Xref: sparky comp.lang.c++:12773 comp.std.c++:1107
From: jane@mullian.ee.mu.OZ.AU (jane lynette cosham)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Inherited nested classes?
Summary: MSC 7.0 & BC 3.0 - differ about nested classes
Keywords: nested classes, inheritance
Date: 23 Aug 92 14:19:27 GMT
Organization: Computer Science, University of Melbourne, Australia


I recently got a copy of MSC 7.0 and have come up aagainst a brick
wall in converting my BC 3.0 code so it is compatible with both
compilers.

The problem is that MSC 7.0 inherits nested classes and BC 3.0
doesn't.  MSC also takes note of access modifiers for nested classes.

For example :
	class A
	{
		public:
			class nested_A
			{
				...
			};
		private:
			class nested_a2
			{
				...
			};
			
			...
	};


	class B : public A
	{
		...
	};

Under MSC B::nested_A is a valid class. However B::nested_a2 is not
accesible outside of A.

Under BC neither class exists for B, and it is possible to declare a
variable of type A::nested_a2 anywhere.

It is my understanding that Borland's implementation is the norm.

The brick wall I came up with was that it is not possible to declare a
class nested within B of the same name as one nested in A - ie nested
classes cannot be hidden in the way functions can.  This is causing a
problem as I have a large amount of code where a nested 'helper' class
is used within an inheritance structure and is given the same name at
all levels.  This code needs major changes to cope with MSC 7.0.

I am writing this to get more information about nesting classes and
future compatibility.  

Does anyone know if this issue has been considered for the standard
and what the outcome of any discussions was?  Also if the MSC
implementation is not standard, does anyone know if they intend to
continue with this in future versions?  Will future versions of MSC
allow you to hide nested classes?

In my opinion the inheritance of these classes is a useful property
however it causes hassles if the same name cannot be used in more than
one level of the class structure.

Thanks in advance for any comments.

Jane.
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: Doubly-linked list trick (was Re: Garbage Collection for C++)
Date: 19 Aug 92 19:30:36 GMT
	<DAVEG.92Aug14194411@synaptx.synaptics.com> <2009@appli.se>
	<16ovt2INN3nq@early-bird.think.com> <2134@appli.se>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: niklas@appli.se's message of 19 Aug 92 08:33:14 GMT

In article <2134@appli.se> niklas@appli.se (Niklas Hallqvist) writes:

   Emphasises mine!  This means the trick WILL be portable to all platforms
   where there exists an integral type large enough (ie. almost all platforms).
   I agree that this may be a bad habit, BUT... what I wanted to tell was:
   It's REAL HARD (read: impossible) to implement GC on most architectures if
   this rule [allowing conversions of pointers to/from integers] is left in.

No, it's not at all hard. Since C++ programs that rely on
integer/pointer conversions are already unportable, a very small
number of these already unportable programs would simply be unportable
to a larger number of implementations. This can be done without
"legal" conflict with the existing C++ standard.

I think the standard should be modified to say that pointer/integer
casts are legal even in the presence of GC, but that you must continue
to hold an "unencoded" pointer to any object that you don't want to be
garbage collected. As noted above, this statement has no effect on
portable programs; C/C++ has undergone significantly greater changes
than this in the past.

For a more extensive discussion of these issues, I suggest looking at
comp.compilers.

					Thomas.

PS: Where was the outcry of indignation when, all of a sudden,
uninitialized static member definitions didn't count as definitions
anymore? Unlike restricting encoded pointers, this did force me to
change some of _my_ source code.

PPS: As to the XOR trick, you can use doubly linked lists of small
arrays of elements to get equivalent space savings portably.