<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>I figured out a way that probably works.<br>I use -1 for the typeid of the made up record, and hope<br>that I don't need it.<br> <br> <br> <br>What C++ does makes a lot of sense actually.<br>What you are missing is that "classes" or "types" have<br>different use-cases. More than 2. Stroustrup identifies<br>a few. Off the top of my head, though:<br> <br> <br> <br>1) value types like std::string<br>Here the value semantics are what you want.<br>This also includes container classes like std::vector,<br>std::queue, etc., that you don't often want to assign,<br>but when you do, they offer a good way to do it.<br> <br> <br> <br>2) typical "object oriented stuff" like "Window" with virtual<br>functions that get overridden<br> <br> <br> <br>3) "object oriented stuff" w/ plugins like how<br>Modula-3 Rd/Wr work and how C++ iostreams work -- you<br>plugin a "buffer". You always call "toplevel" non-overridden<br>functions that selectively call more derived overrides.<br>The toplevel provides a "framework" and common code is lifted<br>out of the derived types, leaving them only to implement "what varies".<br> <br> <br> <br>I think actually in general #2 is overrused and #3 is kind of better.<br>#1 is different and appropriately often used.<br><br><br> <br>4) Sometimes just for scoping globals, i.e. "singleton" / "manager" classes.<br><br><br> <br>The way you enforce stuff is that types that aren't meant to<br>be assigned should have abstract functions, so you can't instantiate<br>them directly.<br><br><br> <br>And then, also, you wrap up #2/#3 in #1 -- std::unique_ptr / std::shared_ptr and such.<br><br><br> <br>Modula-3 favors only #2 or #3.<br>Many languages don't have good support for #1 really.<br>You know -- Modula-3 TEXT and java String get special treatment<br>by the compiler and w/o compiler support, nobody can implement<br>anything quite like them, whereas C++ std::string is implemented<br>with powers available to anyone.<br><br> <br> <br>Anyway, I think I solved my problem.<br>Aside from opaque types always being "ADDRESS", I have good typeinfo<br>in the C backend now. Also exluding global variables, which remain awful.<br>Now to start using these types for locals/parameters...<br> <br> <br> - Jay<br><br><br><br><br><br><div><div id="SkyDrivePlaceholder"></div>> Date: Sun, 7 Apr 2013 14:37:46 -0400<br>> From: hendrik@topoi.pooq.com<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] computing a typeid in backend for a pointer to a declared type??<br>> <br>> On Sun, Apr 07, 2013 at 11:02:51AM -0500, Rodney M. Bates wrote:<br>> > <br>> > <br>> > On 04/07/2013 12:56 AM, Jay K wrote:<br>> > >In the C backend, I would like to share code for records and objects.<br>> > ><br>> > ><br>> > >As I understand, objects are always pointers.<br>> > <br>> > Yes.<br>> > <br>> > ><br>> > ><br>> > >In my framework, I map typeids to type information.<br>> > ><br>> > ><br>> > >For this to work, given an object, I need to declare both a record<br>> > >and a pointer to it. I need two typeids for that.<br>> > ><br>> > ><br>> > >I'm in the position where I need to compute a typeid.<br>> > >Is that feasible?<br>> > ><br>> > ><br>> > ><br>> > >I have two choices if I can't do that:<br>> > ><br>> > ><br>> > > 1) map from strings instead, where the strings tend to be<br>> > > a string form of a typeid, but where I can make up other forms;<br>> > > quite an inefficiency<br>> > ><br>> > ><br>> > > 1b) have two maps maybe<br>> > ><br>> > ><br>> > ><br>> > > 2) build a flag into my record data that indicates "record or object"<br>> > <br>> > FWIW, I believe it is true that every way of using an object type in Modula-3<br>> > implicitly and uniquely identifies whether it works on the pointer or the<br>> > heap object. For example, := and = mean the pointer, while any use of . implies<br>> > dereferencing. There is no whole-object assignment or whole-object comparison,<br>> > as there are for REF RECORD (which has two types).<br>> > <br>> > Maybe this distinction is lost in the lowering that happens by the time M3C gets it,<br>> > or later.<br>> <br>> I this matter Modula 3 is very different from C++, which idenntifies <br>> classes wiith structure types. It even treats struct and class as <br>> equivalent keywords. That was a big mistake in C++, and <br>> results in pathological behavior when assigning class <br>> values instead of class pointers.<br>> <br>> -- hendrik<br>> k<br></div> </div></body>
</html>