From 7317286591256334484 X-Google-Thread: f78e5,4176870a6d7b2d6 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.freenet.de!216.196.110.149.MISMATCH!border2.nntp.ams.giganews.com!nntp.giganews.com!news-hub.cableinet.net!blueyonder!peer-uk.news.demon.net!kibo.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: skaller@nospam.com.au ("John Max Skaller") Newsgroups: comp.std.c++ Subject: Re: Union fun Date: Wed, 27 Oct 2004 18:39:59 GMT Lines: 94 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <1a0929fa.0410191124.162d57ee@posting.google.com> <194c1211.0410220336.5bdc63f9@posting.google.com> <2u7uonF272r7kU3@uni-berlin.de> NNTP-Posting-Host: news.news.demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: news.demon.co.uk 1098902411 1704 158.152.254.254 (27 Oct 2004 18:40:11 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Wed, 27 Oct 2004 18:40:11 +0000 (UTC) X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-User-Agent: Pan/0.13.3 (That cat's something I can't explain) X-Virus-Scanned: by amavisd-new at cs.mu.OZ.AU X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id i9RIdx2I005523; Thu, 28 Oct 2004 04:39:59 +1000 (EST) X-Path: comp-std-cpp-robomod!not-for-mail X-Delivered-To: std-c++@ucar.edu X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Newsgroups: comp.std.c++ Xref: g2news1.google.com comp.std.c++:3210 On Tue, 26 Oct 2004 22:00:51 +0000, Frank Birbacher wrote: >> You use a strcut containing a char-array. It's size is that of the >> largest object you want to store (-> sizeof()). >> Than you create objects using placement new in this array (and you >> destroy them manually calleng thir destructor). > > After some days of debugging you resort to boost::any, which > already does that. I'm not sure exactly what you mean by that. However, please note boost mainly serves the need of people having to hand code solutions. I have a full scale compiler generating code, so I'm treating C++ as a compiler target language. The needs of a target language are different to what you need for human writing, although not unrelated. In my opinion -- C++ offers a number os *significant* advantages as a target language over the traditional choices -- C or assmebler. These include much stronger type checking, which helps debugging the compiler, constructors and friends, which help reduce the amount of work the compiler needs to do by delegating it to the underlying C++ compiler, virtual functions, which make it easy to build an execution model which is fairly simple to maintain and modify .. in general, many of the advantages C++ give a human coder also apply when generating code. Unfortunately, code generators are *greatly* hampered by lack of coherence, orthogonality, generality, etc. When you have this in a target language you have to add lots of special cases to the compiler. The failure of unions to allow constructible types is one such case. Perhaps this protects the human writer and perhaps not, but there's no doubt it creates a significant obstacle to systematic code generation. The need arises in at least two distinct situations, which are universal in the sense all code generators have to handle the problem: implementation of variants and representation of the stack. The latter occurs when you try to build a data structure to model the stack for code like: { int x; } { double y; } where the correct model of the stack is: union { int x; double y; }; This saves storage. Even if x and y here were constructible types it doesn't matter .. the appropriate store will be initialised and destroyed as control flows through the code (when the program counter hits the { and } brackets, more or less .. :) Unions aren't the only problem -- the type system is a pain, the lack of support for recursion in templates makes it much easier to do all generic instantiation in the compiler, rather than try to generate templates, pointers to members are incomplete (you can't add them) etc etc. Still, the union problem is already out of character with the rest of C++, the changes required are fairly clear, and they break nothing. So this obstacle could be fairly easily fixed .. if anyone bothered to consider the idea that C++ might be a useful target language seriously. I personally think that it is important, because C++ is never going to be very good for human coding. Many people have adopted a grossly inferior platform -- Java -- just to get a slighly saner syntax plus garbage collection. Felix tries to provide an alternative which extends C++, rather than requiring you abandon it, so it ought to be worth at least considering the idea that it might just be useful to C++ programmers to make C++ easier to use as a target language. Another example easily fixed: offsetof() macro isn't allowed for non-POD, yet is necessary because pointers to members incomplete and so worthless for a code generator. I happen to use it systematically already .. luckily g++ just gives a warning. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]