[M3devel] computing a typeid in backend for a pointer to a declared type??

[Jay K]

I figured out a way that probably works.
I use -1 for the typeid of the made up record, and hope
that I don't need it.
 
 
 
What C++ does makes a lot of sense actually.
What you are missing is that "classes" or "types" have
different use-cases. More than 2. Stroustrup identifies
a few. Off the top of my head, though:
 
 
 
1) value types like std::string
Here the value semantics are what you want.
This also includes container classes like std::vector,
std::queue, etc., that you don't often want to assign,
but when you do, they offer a good way to do it.
 
 
 
2) typical "object oriented stuff" like "Window" with virtual
functions that get overridden
 
 
 
3) "object oriented stuff" w/ plugins like how
Modula-3 Rd/Wr work and how C++ iostreams work -- you
plugin a "buffer". You always call "toplevel" non-overridden
functions that selectively call more derived overrides.
The toplevel provides a "framework" and common code is lifted
out of the derived types, leaving them only to implement "what varies".
 
 
 
I think actually in general #2 is overrused and #3 is kind of better.
#1 is different and appropriately often used.


 
4) Sometimes just for scoping globals, i.e. "singleton" / "manager" classes.


 
The way you enforce stuff is that types that aren't meant to
be assigned should have abstract functions, so you can't instantiate
them directly.


 
And then, also, you wrap up #2/#3 in #1 -- std::unique_ptr / std::shared_ptr and such.


 
Modula-3 favors only #2 or #3.
Many languages don't have good support for #1 really.
You know -- Modula-3 TEXT and java String get special treatment
by the compiler and w/o compiler support, nobody can implement
anything quite like them, whereas C++ std::string is implemented
with powers available to anyone.

  
 
Anyway, I think I solved my problem.
Aside from opaque types always being "ADDRESS", I have good typeinfo
in the C backend now. Also exluding global variables, which remain awful.
Now to start using these types for locals/parameters...
 
   
 - Jay





> Date: Sun, 7 Apr 2013 14:37:46 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] computing a typeid in backend for a pointer to a declared type??
> 
> On Sun, Apr 07, 2013 at 11:02:51AM -0500, Rodney M. Bates wrote:
> > 
> > 
> > On 04/07/2013 12:56 AM, Jay K wrote:
> > >In the C backend, I would like to share code for records and objects.
> > >
> > >
> > >As I understand, objects are always pointers.
> > 
> > Yes.
> > 
> > >
> > >
> > >In my framework, I map typeids to type information.
> > >
> > >
> > >For this to work, given an object, I need to declare both a record
> > >and a pointer to it. I need two typeids for that.
> > >
> > >
> > >I'm in the position where I need to compute a typeid.
> > >Is that feasible?
> > >
> > >
> > >
> > >I have two choices if I can't do that:
> > >
> > >
> > >  1) map from strings instead, where the strings tend to be
> > >     a string form of a typeid, but where I can make up other forms;
> > >     quite an inefficiency
> > >
> > >
> > >  1b) have two maps maybe
> > >
> > >
> > >
> > >  2) build a flag into my record data that indicates "record or object"
> > 
> > FWIW, I believe it is true that every way of using an object type in Modula-3
> > implicitly and uniquely identifies whether it works on the pointer or the
> > heap object.  For example, := and  = mean the pointer, while any use of . implies
> > dereferencing.  There is no whole-object assignment or whole-object comparison,
> > as there are for REF RECORD (which has two types).
> > 
> > Maybe this distinction is lost in the lowering that happens by the time M3C gets it,
> > or later.
> 
> I this matter Modula 3 is very different from C++, which idenntifies 
> classes wiith structure types.  It even treats struct and class as 
> equivalent keywords.  That was a big mistake in C++, and 
> results in pathological behavior when assigning class 
> values instead of class pointers.
> 
> -- hendrik
> k
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130407/12ca60bb/attachment-0002.html>