help-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: C++ / multiple instances / iostreams


From: Laurence Finston
Subject: Re: C++ / multiple instances / iostreams
Date: Wed, 21 Jul 2004 00:01:21 +0200
User-agent: IMHO/0.98.3+G (Webmail for Roxen)

> 
> 4) The acronym POD stands for "plain old data."
> 

Thanks again.  You certainly know your standard.

>> I hesitate to suggest anything without trying it out first, but 
>> generally
> >speaking, I would define `YYSTYPE' to be a pointer if I was using
> >a class type as my semantic value.  Even if using a type with 

non-trivial copy
> >constructors was possible, calling a copy constructor is potentially
> >expensive,
> >whereas copying a pointer is not.
> 
> The idea of C++ is to take those running time expenses in favor of
> programming convenience. If a pointer is replaced with say a class
> maintaining a reference count, then one gets automatic cleanup, also in 

the
> case of errors. Under C, the cleanup will have to be done by hand, or by
> using the still experimental %destructor option.
> 

I don't agree that this is the idea of C++.  I believe C++ is designed to 
support a variety of different programming styles.  One of the important 
goals in the design of C++ was also not to lose the ability to program in a
low-level style efficiently.  I don't quite understand what you mean by 
automatic cleanup, since C++ doesn't do garbage collection.  I assume you mean
something having to do with destructors performing deallocation when a count
reaches 0, or something similar.  I certainly don't dispute that C++ provides
a lot of very useful features, far from it.

> >  My union looks like this:
> >
> >%union
> >{
> >  char string_value[64];
> >  double real_value;
> >  signed int int_value;
> >  void* pointer_value;
> >};
> >
> >I may revise my parser so that I just use the `void*' and don't
> >bother with the other types.  I thought it would be more convenient this 

way,
> >but it's not, really.
> 
> I use:
> 
> class semantic_type {
> public:
>   long number_;
>   std::string text_;
>   my::object object_;
> 
>   semantic_type() : number_(0) {}
> };
> 
> #define YYSTYPE semantic_type
> 
> Here, my::object is the polymorphic type, which maintains a
> reference-counted pointer object_root*. I loose some space, as this is 

not
> a union.
> 
> >Hans' method of deriving all possible rule values from a common base 

class (if
> >I've understood him correctly) will probably work well for a lot of
> >applications.  In my application it wouldn't, but I've found that 

casting the
> >objects to the appropriate types as needed isn't any trouble.
> 
> It will probably work in your case as well, if you were willing to take 

the
> overhead it generates relative your method.
> 

I was wrong to say it wouldn't work.  I believe it would work, I just 
don't think it would be good design for my application.  For example, many of
the types in 3DLDF are derived from the abstract base class `Shape', e.g.,
`Point', `Path', `Circle', etc.  Others are not, e.g., `Transform', `Pen', and
`Color'.  If it would make sense to define virtual functions that might be
called on objects of any of these types in the parser actions, then I think it
would make sense to define an abstract base class for all of them.  Since this
is not the case, I don't see any advantage in doing so over using a `void*'.  

Overhead is also a significant factor.  Currently, 3DLDF produces only
MetaPost code, but ultimately I'd like it to perform its own scan converting
and rendering and produce output in graphics formats such as PNG and MNG. 
Someday, I'd also like it to be able to produce graphics in real-time.  So I
do have to try to program efficiently in way that's not necessary for a lot of
applications in these days of fast processors and cheap memory.  I'm actually
glad of the excuse to program in a somewhat low-level style.  Sadly, it's not
what most employers seem to be looking for these days.

Laurence




reply via email to

[Prev in Thread] Current Thread [Next in Thread]