ctool-develop — Discussion on developing the cTool library.

Re: [Ctool-develop] little fixes

[Shaun F. <fli...@so...>]

Steven,

It sounds to me like we're basically in agreement here.  My plan going 
forward is to, for example, take the time to add accessors to all 
classes I work on, without making the members private.  So, the old API 
continues to work while a better one is available.

Yes, I've been a bit short on time and the necessary motivation lately 
to do cleanup like this.  I was also having some difficultly with the 
early (Mac) versions of gcc 3.0 that led me to spend more time on my 
Metreowerks-using projects. :^)

I think the next thing needing doing has to be improved handling of gcc 
extensions, which is what I was working on during my last major ctool 
development push.  Not being able to cleanly use standard include files 
is quite the bummer.

Thanks,
Shaun


On Friday, August 1, 2003, at 12:03  PM, Steven Singer wrote:

> Shaun Flisakowski wrote:
> > I'm glad to hear that.  I lost a few users in the switch, some just
> > stuck with their CTree code, one person said they wouldn't use it now
> > that it could no longer parse itself.
>
> I can imagine that if you're trying to write a compiler then it's
> important that it be able to compile itself.
>
> My old code written with CTree I've left alone. After all, it works
> so there's no need to break it.
>
> > I agree, but as I mentioned I think API changes need to come in 
> phases;
> > with a plan that allows for slow migration among the user base - I'm 
> not
> > looking to make any new enemies, I'm full up.
>
> I agree. Pissing people off is not a good plan.
>
> However, slowly migrating an API is probably not the best solution.
> The people who are using the old API will complain as soon as it moves
> at all, the people who want a new API will complain that things aren't
> moving quickly enough and everybody else will be coding to a moving
> target.
>
> Probably a better approach is to take some time to decide on a new,
> clean, API - the one you would have had if you'd started from scratch
> knowing all you do now. Then, make the new API available as a wrapper
> to the existing API. This would allow existing users to keep using the
> old API and new users to immediately write to the new API. The old API
> could initially be marked as deprecated but still available.
>
> Then, only as internal changes rendered the old API invalid would
> people be forced to move.
>
> This method has the advantage of delaying pissing people off until
> absolutely necessary and also providing a nice clean API not
> compromised by legacy interfaces.
>
> Another approach would be to have a new set of data structures with
> a new API and provide import and export facilities to the old data
> structures. New features need be added only to the new data
> structures but people could avoid the conversion step if they relied
> on implementation details of the old structures.
>
> However, this is a big job and should only be undertaken if the
> resources are available to see it through to the end. Since I'm not
> offering you any of my time, feel free to tell me to go away.
>
> 	- Steven
> -- 
>
>
>
>
> **********************************************************************
> The information transmitted is intended only for the person or
> entity to which it is addressed and may contain confidential and/or 
> privileged material. Any review, retransmission, dissemination or 
> other use of, or
> taking of any action in reliance upon, this information by persons or 
> entities other than the intended recipient is prohibited.  If you 
> received this in error, please contact the sender and delete the 
> material from any computer.
> **********************************************************************
>

Re: [Ctool-develop] using ctool as a library

[Stefan S. <se...@sy...>]

Shaun Flisakowski wrote:
> 
> On Friday, August 1, 2003, at 10:39  AM, Stefan Seefeld wrote:
> 
>> Shaun Flisakowski wrote:
>>
>>> Stefan,
>>> Rather than send a huge patch like this you could just become a ctool 
>>> developer so you can use cvs also; for a large change it could go in 
>>> on a branch first to be looked over by concerned parties. I'll just 
>>> need your sourceforge username to add you.
>>
>>
>> I'm known as 'stefan' there.
> 
> 
> Great - you are now a developer.

thanks a lot. I hope I'll make good use of that priviledge and not
putting anybody in danger :-)

> As I mentioned in my previous email, we should try to maintain the old 
> API also (redirecting it to the PrintTraversal in this case), at least 
> for a few releases.

yes. Once the PrintTraversal is debugged, we could keep all the 
individual 'print' methods and 'operator <<' and implement them via
the PrintTraversal methods. That way the interface is preserved, without
any unnecessary code duplication.

>> ok, fine. I'll be on vacation starting today for two weeks, but I'm
>> eager to work on this tool. Please let me know whether you have 
>> anything such as a commit policy. Besides dsicussing possible changes
>> before applying them, do you want to review the actual patches ? Etc.
>> Just to avoid later frustrations...
> 
> 
> I don't yet.  There was only one other ctool developer at the moment, 
> and we were just sort of working it out. He's actually working on some 
> larger open-source tool which is using ctool as a component.

sounds familiar :-)

> I want to hear about larger changes, but I can see the diffs in CVS if 
> I'm just given a list of files.  I don't need to be informed of every 
> bug fix.

ok. Let's see how it works out. Now I'm off for two weeks.
See you...

Stefan

Re: [Ctool-develop] little fixes

[Steven S. <ste...@cs...>]

Shaun Flisakowski wrote:
 > I'm glad to hear that.  I lost a few users in the switch, some just
 > stuck with their CTree code, one person said they wouldn't use it now
 > that it could no longer parse itself.

I can imagine that if you're trying to write a compiler then it's
important that it be able to compile itself.

My old code written with CTree I've left alone. After all, it works
so there's no need to break it.

 > I agree, but as I mentioned I think API changes need to come in phases;
 > with a plan that allows for slow migration among the user base - I'm not
 > looking to make any new enemies, I'm full up.

I agree. Pissing people off is not a good plan.

However, slowly migrating an API is probably not the best solution.
The people who are using the old API will complain as soon as it moves
at all, the people who want a new API will complain that things aren't
moving quickly enough and everybody else will be coding to a moving
target.

Probably a better approach is to take some time to decide on a new,
clean, API - the one you would have had if you'd started from scratch
knowing all you do now. Then, make the new API available as a wrapper
to the existing API. This would allow existing users to keep using the
old API and new users to immediately write to the new API. The old API
could initially be marked as deprecated but still available.

Then, only as internal changes rendered the old API invalid would
people be forced to move.

This method has the advantage of delaying pissing people off until
absolutely necessary and also providing a nice clean API not
compromised by legacy interfaces.

Another approach would be to have a new set of data structures with
a new API and provide import and export facilities to the old data
structures. New features need be added only to the new data
structures but people could avoid the conversion step if they relied
on implementation details of the old structures.

However, this is a big job and should only be undertaken if the
resources are available to see it through to the end. Since I'm not
offering you any of my time, feel free to tell me to go away.

	- Steven
-- 




**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: [Ctool-develop] using ctool as a library

[Steven S. <ste...@cs...>]

Stefan Seefeld wrote:
 > Steven Singer wrote:
 >> Can I ask why all the functions have different names? Wouldn't it be
 >> more natural to give them all the same name and then overload on the
 >> argument type?
 >
 > mainly a matter of taste I guess. It's easier to distinguish. The single
 > most important point is if you derive a new Traversal. If you use the
 > same name for all methods, you have to redefine all of them (or specify
 > 'using Base::traverse') or the compiler will complain.

I think this depends what you're doing. For example, this works fine:

#include <iostream>

class V {
public:
	virtual void operator()(int) = 0;
	virtual void operator()(double) = 0;
	virtual void operator()(char *) = 0;
};

class V1 : public V {
public:
	virtual void operator()(int) { std::cout << "A"; }
	virtual void operator()(double) { std::cout << "B"; }
	virtual void operator()(char *) { std::cout << "C"; }
};

class V2 :  public V1 {
public:
	virtual void operator()(char *) { std::cout << "D"; }
};

class Obj {
public:
     void accept(V &v) { v(1); }
};

int main()
{
     Obj ob;
     V2 v_instance;

     ob.accept(v_instance);

     std::cout << std::endl;

     return 0;
}

This works because all the accept routines have a reference to a V,
not to the specific subtype. Provided you're always going through
V then it's OK.

However, the real killer is if you need to inherit from a class over
which you have no control. So if V1 and V2 were in a library and I
wanted to write:

class V3 :  public V2 {
public:
	virtual void operator()(int i) {
             std::cout << "E";
             ????::operator()(i);
         }
};

then it's difficult to know in advance whether I need to put V1 or V2
in place of the ???? to pass control up to the base class. Of course,
I could solve this by delegation:

class V3 :  public V2 {
public:
	virtual void operator()(int i) {
             std::cout << "E";
             ((V &) v2)(i);
         }
private:
	V2 v2;
};

But that's getting needlessly complicated.

So I think your initial objection is valid. Different names make
inheritance easier.

 >> If they all have the same name then instead of calling it traverse,
 >> it could be operator(). Accept code could then look like:
 >
 > yes it could. But I find it much clearer to spell out what it is doing.
 > I find 'operator ()' a little too compact.

OK, that's a completely fair comment. To much use of terse coding
tricks can make things illegible.

	- Steven
-- 




**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: [Ctool-develop] using ctool as a library

[Shaun F. <fli...@so...>]

On Friday, August 1, 2003, at 10:39  AM, Stefan Seefeld wrote:

> Shaun Flisakowski wrote:
>> Stefan,
>> Rather than send a huge patch like this you could just become a ctool 
>> developer so you can use cvs also; for a large change it could go in 
>> on a branch first to be looked over by concerned parties. I'll just 
>> need your sourceforge username to add you.
>
> I'm known as 'stefan' there.

Great - you are now a developer.

>> I like the sound of your PrintTraversal, but I disagree with this not 
>> being in the library itself. This is a very common need: using the 
>> generated AST to swap arguments to a particular function, etc then 
>> reprinting the source.  Having it in the library brings the size of a 
>> simple program like this down to a page or two of code.
>
> sure. I just wanted to make the point that the printing functionality
> could be factored out of the individual nodes. I agree that it is a
> commonly used tool, and in fact the PrintTraversal could be much 
> refined
> by means of strategies to become flexible as to what and how to print.

As I mentioned in my previous email, we should try to maintain the old 
API also (redirecting it to the PrintTraversal in this case), at least 
for a few releases.

>> Also, the bison change is going to need to be an option in the 
>> makefile; my version of bison is apparently older, as its doing the 
>> dumb 'gram.cpp.h' thing.  Autoconf sounds good to me also.
>
> Good. Then we could test for the installed bison version and do the
> right thing.
>
>> Changing the library name to 'libctool.*' makes sense to me for both 
>> the shared and static versions.
>> I'm not going to merge these changes now, I'll wait till I hear from 
>> you about becoming a developer.
>
> ok, fine. I'll be on vacation starting today for two weeks, but I'm
> eager to work on this tool. Please let me know whether you have 
> anything such as a commit policy. Besides dsicussing possible changes
> before applying them, do you want to review the actual patches ? Etc.
> Just to avoid later frustrations...

I don't yet.  There was only one other ctool developer at the moment, 
and we were just sort of working it out. He's actually working on some 
larger open-source tool which is using ctool as a component.

I want to hear about larger changes, but I can see the diffs in CVS if 
I'm just given a list of files.  I don't need to be informed of every 
bug fix.

Thanks,
Shaun

Re: [Ctool-develop] using ctool as a library

[Stefan S. <se...@sy...>]

Steven Singer wrote:
 > Stefan Seefeld wrote:
 >  >   virtual void traverse_base(BaseType *) = 0;
 >  >   virtual void traverse_ptr(PtrType *) = 0;
 >  >   virtual void traverse_array(ArrayType *) = 0;
 >  >   virtual void traverse_bit_field(BitFieldType *) = 0;
 > [etc.]
 >
 > Can I ask why all the functions have different names? Wouldn't it be
 > more natural to give them all the same name and then overload on the
 > argument type?

mainly a matter of taste I guess. It's easier to distinguish. The single
most important point is if you derive a new Traversal. If you use the 
same name for all methods, you have to redefine all of them (or specify
'using Base::traverse') or the compiler will complain. You may want to
read about variations on this theme (and others) in John Vlissides'
excellent book 'Pattern Hatching'.

 > If they all have the same name then instead of calling it traverse,
 > it could be operator(). Accept code could then look like:

yes it could. But I find it much clearer to spell out what it is doing.
I find 'operator ()' a little too compact.

 > I suspect a reference to a Traversal is more helpful than a pointer
 > as references can't be NULL and there's no need to rebind t partway
 > through a function.

true. It's just lazyness as then you have to pass '*this' instead of
'this'. :-)

Regards,
		Stefan

Re: [Ctool-develop] using ctool as a library

[Steven S. <ste...@cs...>]

Stefan Seefeld wrote:
 >   virtual void traverse_base(BaseType *) = 0;
 >   virtual void traverse_ptr(PtrType *) = 0;
 >   virtual void traverse_array(ArrayType *) = 0;
 >   virtual void traverse_bit_field(BitFieldType *) = 0;
[etc.]

Can I ask why all the functions have different names? Wouldn't it be
more natural to give them all the same name and then overload on the
argument type?

If they all have the same name then instead of calling it traverse,
it could be operator(). Accept code could then look like:

virtual void accept(Traversal &t) { t(this); }

I suspect a reference to a Traversal is more helpful than a pointer
as references can't be NULL and there's no need to rebind t partway
through a function.

	- Steven
-- 




**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: [Ctool-develop] little fixes

[Shaun F. <fli...@so...>]

On Thursday, July 31, 2003, at 02:44  PM, Steven Singer wrote:

> Shaun Flisakowski wrote:
>> As for your comment about vectors, cTool was originally written in C 
>> (as the poorly named "CTree", which I now know is also a database 
>> product).  With version 2.0, I changed over to C++ so a class 
>> hierarchy could be used to clean up the resulting AST - I was not 
>> looking to rewrite from scratch using C++.
>
> I know about CTree. I've used that too.
>
> CTool is a huge improvement in usability over CTree, the interfaces are
> much cleaner. The latest program I tried to write I started with CTree
> because that's what I had handy and got into a real mess. When I
> changed to CTool, all the complexities disappeared and I could spend
> my time concentrating on deciding what I wanted to do instead of how to
> do it.

I'm glad to hear that.  I lost a few users in the switch, some just 
stuck with their CTree code, one person said they wouldn't use it now 
that it could no longer parse itself.

> However, CTool is still showing its C roots. Too much of the internal
> workings of the data structure are exposed. This makes it very
> difficult to change any detail of the implementation.

While I agree these things should be hidden, I'd want to do that very 
slowly - I'd be loathe to break people's existing solutions.  The first 
step would have to be accessors for all the classes, then after a few 
more releases pass by, start making the members private.  Where I work, 
we have a define:
	#define	privileged		public

that we use to indicate this is the direction this class (which was 
once C, which was once pascal) is headed.

My preference would be change a particular implementation as needed (to 
be vector or list), perhaps making it private at that point.  This way, 
only users modifying that particular item would be affected.

> For example, suppose I had needed a fast insertBefore method. This
> would have required updating the Statement data structure to be
> doubly linked. Since the next pointers are exposed, I'd have no control
> over what external code is using them to manipulate the data structure.
> If the manipulation did not take into account the new pointers I would
> have needed to add, then the result would have been a complete mess.
>
> Hiding all the implementation details will allow future changes to
> the internal workings. At the moment you don't even have to change
> the implementation, just hide all the variables and work out what
> actions are needed on the objects.
>
> Hiding the variables, however, will break any existing program that
> relies on the current implementation. It would have to be reserved
> for the next major version.

I agree, but as I mentioned I think API changes need to come in phases; 
with a plan that allows for slow migration among the user base - I'm 
not looking to make any new enemies, I'm full up.

> Do you have a good idea what sort of tools people are building with
> CTool amd hence what manipulation options they need?
>
> 	- Steven
> -- 

At the point I switched over to using sourceforge, there were about 50 
people on my mailing list.  Of the ones that asked me questions, many 
were graduate students using ctool in some project.  These are the 
low-end solutions, consisting of: parse, modify AST, and print modified 
output.  One example that comes to mind was someone inserting a 
function call at the beginning of each for/while loop block.

High-end use is using ctool as a front-end to your own compiler (for 
some embedded system, etc).  For example, Cisco was using ctool in 
their testing dept to do something or other. I went over to the company 
(a few blocks from where I work) to talk to them about it.  I met with 
a group of people, one who had already used ctool in a prototype of 
some new testing system - the specifics are their business alone, but 
they were willing to sink some serious resources into their project.  
Assuming they currently have 100K LOC or more in their project, I would 
imagine some unhappiness with a large change to the API unless backward 
compatibility is kept in mind.

Thanks,
Shaun

Re: [Ctool-develop] running tests

[Stefan S. <se...@sy...>]

Shaun Flisakowski wrote:
> 
> Stefan,
> 
> Unfortunately, the problems with 8q and enum2 stem from the inclusion of 
> stdio.h.  On solaris and many other systems, these files are pretty 
> clean - the gcc versions however are chock full of gcc extensions, many 
> of which ctool doesn't support yet.  I've done some work on this, mostly 
> just trying to recognize and ignore them, the 'gcc' test suite is 
> something I was working on to resolve these issues.

I don't know whether this is related, but we have a similar situation
with synopsis where a naive preprocessing with gcc and feeding of the
resulting stream into the C++ parser will results in errors. What I
did is using 'gcc -Wno-gnu-keywords' to strip off the gcc extensions.

You may try that, though I'm not sure the problems fall all into that
category.

[...]

> The STDC thing sounds like you might have WINDOWS defined?, see lexer.l:

hardly. I was running on a RH9 linux box. We'll see...

Regards,
		Stefan

Re: [Ctool-develop] using ctool as a library

[Stefan S. <se...@sy...>]

Shaun Flisakowski wrote:
> Stefan,
> 
> Rather than send a huge patch like this you could just become a ctool 
> developer so you can use cvs also; for a large change it could go in on 
> a branch first to be looked over by concerned parties. I'll just need 
> your sourceforge username to add you.

I'm known as 'stefan' there.

> I like the sound of your PrintTraversal, but I disagree with this not 
> being in the library itself. This is a very common need: using the 
> generated AST to swap arguments to a particular function, etc then 
> reprinting the source.  Having it in the library brings the size of a 
> simple program like this down to a page or two of code.

sure. I just wanted to make the point that the printing functionality
could be factored out of the individual nodes. I agree that it is a
commonly used tool, and in fact the PrintTraversal could be much refined
by means of strategies to become flexible as to what and how to print.

> Also, the bison change is going to need to be an option in the makefile; 
> my version of bison is apparently older, as its doing the dumb 
> 'gram.cpp.h' thing.  Autoconf sounds good to me also.

Good. Then we could test for the installed bison version and do the
right thing.

> Changing the library name to 'libctool.*' makes sense to me for both the 
> shared and static versions.
> 
> I'm not going to merge these changes now, I'll wait till I hear from you 
> about becoming a developer.

ok, fine. I'll be on vacation starting today for two weeks, but I'm
eager to work on this tool. Please let me know whether you have anything 
such as a commit policy. Besides dsicussing possible changes
before applying them, do you want to review the actual patches ? Etc.
Just to avoid later frustrations...

Best regards,
		Stefan

Re: [Ctool-develop] running tests

[Shaun F. <fli...@so...>]

Stefan,

Unfortunately, the problems with 8q and enum2 stem from the inclusion 
of stdio.h.  On solaris and many other systems, these files are pretty 
clean - the gcc versions however are chock full of gcc extensions, many 
of which ctool doesn't support yet.  I've done some work on this, 
mostly just trying to recognize and ignore them, the 'gcc' test suite 
is something I was working on to resolve these issues.

I just checked accept0 and checked in new versions - many had an extra 
#line directive at the top of their results which is not appearing for 
me.

The STDC thing sounds like you might have WINDOWS defined?, see lexer.l:

#ifdef   WINDOWS
#    ifndef  __STDC__
#    define  __STDC__    1
#    endif
....
#endif

Thanks,
Shaun

On Thursday, July 31, 2003, at 05:15  PM, Stefan Seefeld wrote:

> hi there,
>
> I tried running the regression tests, but didn't get very
> far. In fact, the problems I'm seeing look suspiciously like
> configurational errors, so I assume the problem can easily
> be solved (by someone with the necessary knowledge :-)
>
> The output from the 'accept0' run is appended...
>
> Thanks,
> 		Stefan
> Test Suite output from suite(s): accept0
>
> test_suite started at: Thu Jul 31 20:12:33 EDT 2003
>
> Testing the suite accept0
> Test Suite output from suite accept0
>
> Test started at: Thu Jul 31 20:12:33 EDT 2003
>
> Testing the 8q program...<command line>:1:1: warning: "__STDC__" 
> redefined
> <built-in>:9:1: warning: this is the location of the previous 
> definition
> /usr/include/gconv.h:176: Unsized array not allowed as field:
>   __extension__ struct __gconv_step_data __data [];
>                                                   ^
> /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include/stdarg.h:43: Error 
> (parse error) before 'Identifier'
> typedef __builtin_va_list __gnuc_va_list;
>                           ^
> /usr/include/libio.h:195: Warning - old-style declaration or incorrect 
> type:
> };
>  ^
> ctdemo: decl.cpp:971: <Pretty Function Name (gcc only)>: Assertion 
> `comp->name->entry->IsComponentDecl()' failed.
> done.
> Testing the bug1 program...<command line>:1:1: warning: "__STDC__" 
> redefined
> <built-in>:9:1: warning: this is the location of the previous 
> definition
> done.
> Testing the bug2 program...<command line>:1:1: warning: "__STDC__" 
> redefined
> <built-in>:9:1: warning: this is the location of the previous 
> definition
> done.
> Testing the bug3 program...<command line>:1:1: warning: "__STDC__" 
> redefined
> <built-in>:9:1: warning: this is the location of the previous 
> definition
> done.
> Testing the bug4 program...<command line>:1:1: warning: "__STDC__" 
> redefined
> <built-in>:9:1: warning: this is the location of the previous 
> definition
> done.
> Testing the bug5 program...<command line>:1:1: warning: "__STDC__" 
> redefined
> <built-in>:9:1: warning: this is the location of the previous 
> definition
> done.
> Testing the bug7 program...<command line>:1:1: warning: "__STDC__" 
> redefined
> <built-in>:9:1: warning: this is the location of the previous 
> definition
> done.
> Testing the bug8 program...<command line>:1:1: warning: "__STDC__" 
> redefined
> <built-in>:9:1: warning: this is the location of the previous 
> definition
> done.
> Testing the dowhile program...<command line>:1:1: warning: "__STDC__" 
> redefined
> <built-in>:9:1: warning: this is the location of the previous 
> definition
> done.
> Testing the enum program...<command line>:1:1: warning: "__STDC__" 
> redefined
> <built-in>:9:1: warning: this is the location of the previous 
> definition
> done.
> Testing the enum2 program...<command line>:1:1: warning: "__STDC__" 
> redefined
> <built-in>:9:1: warning: this is the location of the previous 
> definition
> /usr/include/gconv.h:176: Unsized array not allowed as field:
>   __extension__ struct __gconv_step_data __data [];
>                                                   ^
> /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include/stdarg.h:43: Error 
> (parse error) before 'Identifier'
> typedef __builtin_va_list __gnuc_va_list;
>                           ^
> /usr/include/libio.h:195: Warning - old-style declaration or incorrect 
> type:
> };
>  ^
> ctdemo: decl.cpp:971: <Pretty Function Name (gcc only)>: Assertion 
> `comp->name->entry->IsComponentDecl()' failed.
> done.
> Testing the funcptr program...<command line>:1:1: warning: "__STDC__" 
> redefined
> <built-in>:9:1: warning: this is the location of the previous 
> definition
> done.
> Testing the idlist program...<command line>:1:1: warning: "__STDC__" 
> redefined
> <built-in>:9:1: warning: this is the location of the previous 
> definition
> done.
> Testing the ken program...<command line>:1:1: warning: "__STDC__" 
> redefined
> <built-in>:9:1: warning: this is the location of the previous 
> definition
> done.
> Testing the main3 program...<command line>:1:1: warning: "__STDC__" 
> redefined
> <built-in>:9:1: warning: this is the location of the previous 
> definition
> done.
> Testing the main3a program...<command line>:1:1: warning: "__STDC__" 
> redefined
> <built-in>:9:1: warning: this is the location of the previous 
> definition
> done.
> Testing the mt program...<command line>:1:1: warning: "__STDC__" 
> redefined
> <built-in>:9:1: warning: this is the location of the previous 
> definition
> Warning: ANSI/ISO C forbids an empty source file.
> done.
> Testing the pnt program...<command line>:1:1: warning: "__STDC__" 
> redefined
> <built-in>:9:1: warning: this is the location of the previous 
> definition
> done.
> Testing the sizeof program...<command line>:1:1: warning: "__STDC__" 
> redefined
> <built-in>:9:1: warning: this is the location of the previous 
> definition
> done.
> Testing the ste program...<command line>:1:1: warning: "__STDC__" 
> redefined
> <built-in>:9:1: warning: this is the location of the previous 
> definition
> done.
> Testing the struct program...<command line>:1:1: warning: "__STDC__" 
> redefined
> <built-in>:9:1: warning: this is the location of the previous 
> definition
> done.
> Testing the struct2 program...<command line>:1:1: warning: "__STDC__" 
> redefined
> <built-in>:9:1: warning: this is the location of the previous 
> definition
> done.
> Testing the v0 program...<command line>:1:1: warning: "__STDC__" 
> redefined
> <built-in>:9:1: warning: this is the location of the previous 
> definition
> done.
> Testing the v1 program...<command line>:1:1: warning: "__STDC__" 
> redefined
> <built-in>:9:1: warning: this is the location of the previous 
> definition
> done.
> Testing the v2 program...<command line>:1:1: warning: "__STDC__" 
> redefined
> <built-in>:9:1: warning: this is the location of the previous 
> definition
> done.
> Testing the v3 program...<command line>:1:1: warning: "__STDC__" 
> redefined
> <built-in>:9:1: warning: this is the location of the previous 
> definition
> done.
> Testing the v4 program...<command line>:1:1: warning: "__STDC__" 
> redefined
> <built-in>:9:1: warning: this is the location of the previous 
> definition
> done.
> Testing the v6 program...<command line>:1:1: warning: "__STDC__" 
> redefined
> <built-in>:9:1: warning: this is the location of the previous 
> definition
> done.
> Testing the wide program...<command line>:1:1: warning: "__STDC__" 
> redefined
> <built-in>:9:1: warning: this is the location of the previous 
> definition
> done.
>
> Testing finished at: Thu Jul 31 20:12:34 EDT 2003
>
> Ouput from 8q does not match expected output.
> Ouput from bug1 does not match expected output.
> Ouput from bug2 does not match expected output.
> Ouput from bug3 does not match expected output.
> Ouput from bug4 does not match expected output.
> Ouput from bug5 does not match expected output.
> Ouput from bug7 does not match expected output.
> Ouput from bug8 does not match expected output.
> Ouput from dowhile does not match expected output.
> Ouput from enum does not match expected output.
> Ouput from enum2 does not match expected output.
> Ouput from funcptr does not match expected output.
> Ouput from idlist does not match expected output.
> Ouput from ken does not match expected output.
> Ouput from main3 does not match expected output.
> Ouput from main3a does not match expected output.
> Ouput from mt does not match expected output.
> Ouput from pnt does not match expected output.
> Ouput from sizeof does not match expected output.
> Ouput from ste does not match expected output.
> Ouput from struct does not match expected output.
> Ouput from struct2 does not match expected output.
> Ouput from v0 does not match expected output.
> Ouput from v1 does not match expected output.
> Ouput from v2 does not match expected output.
> Ouput from v3 does not match expected output.
> Ouput from v4 does not match expected output.
> Ouput from v6 does not match expected output.
> Ouput from wide does not match expected output.
>
> Differing Output: 29
> Tested: 29
>
>
> Percent differing: 100.00%
>
> Percent successful:   0.00%
> Done testing suite accept0.
> test_suite finished at: Thu Jul 31 20:12:34 EDT 2003
>
>

Re: [Ctool-develop] using ctool as a library

[Shaun F. <fli...@so...>]

Stefan,

Rather than send a huge patch like this you could just become a ctool 
developer so you can use cvs also; for a large change it could go in on 
a branch first to be looked over by concerned parties. I'll just need 
your sourceforge username to add you.

I like the sound of your PrintTraversal, but I disagree with this not 
being in the library itself. This is a very common need: using the 
generated AST to swap arguments to a particular function, etc then 
reprinting the source.  Having it in the library brings the size of a 
simple program like this down to a page or two of code.

Also, the bison change is going to need to be an option in the 
makefile; my version of bison is apparently older, as its doing the 
dumb 'gram.cpp.h' thing.  Autoconf sounds good to me also.

Changing the library name to 'libctool.*' makes sense to me for both 
the shared and static versions.

I'm not going to merge these changes now, I'll wait till I hear from 
you about becoming a developer.

Thanks,
Shaun

On Thursday, July 31, 2003, at 11:37  PM, Stefan Seefeld wrote:

> Shaun Flisakowski wrote:
>> Limited forms of visitors exist, see TransUnit in project.h:
>>     void findStemnt( fnStemntCallback cb );
>>     void findFunctionDef( fnFunctionCallback cb );
>> and Expression in express.h:
>>     void findExpr( fnExprCallback cb );
>> The 'cgraph' example in examples/cgraph uses findFunctionDef() to  
>> demonstrate how to create a call-graph for a program.
>> I have my doubts that this method is going to be powerful enough to  
>> transfer the entire AST to another form though - they are intended 
>> for  users who need to collect information from the AST, or to make 
>> slight  tweaks to the AST before reprinting it.
>> If you try it, I'd like to hear your suggestions for improvements.
>
> ok, I had a first try tonight at this: I added 'accept' methods to
> a number of classes, which all accept a 'Traversal' object and call
> an appropriate method on it to resolve the dynamic type.
>
> I wrote a 'PrintTraversal' which should (once debugged and cleaned up)
> do all the work that is now implemented by the various 'print' methods.
> This is just an illustration of the pattern, but if you accept it, you
> could remove all the 'print' methods from the individual classes,
> as that code would then be completely contained in PrintTraversal.cpp.
>
> The idea is then that the actual library would only contain the parser,
> the individual node types, and the Traversal interface.
> The PrintTraversal (and any other Traversal implementations users want
> to implement) are part of the applications that actually use the 
> library.
>
> Specifically, the PrintTraversal would go into the 'ctdemo' 
> application,
> while the library would not contain any print functionality.
>
> Speaking of the library, do you think it would make sense to build
> it as a shared library ? Also, if you want to 'go public' with that,
> I'd suggest a somewhat longer name such as 'libctool.so' instead of the
> short and unspecific name 'libct.so'.
>
> Finally, I'd suggest to rework the build system a little to make the
> whole thing more flexible and portable. I'd suggest to use autoconf for
> that, and I'm willing to provide a patch.
>
> However, I'll be on vacation starting this weekend, so I'm only able
> to work more on this project in two weeks.
>
> Kind regards,
> 		Stefan
> ? src/PrintTraversal.cpp
> ? src/PrintTraversal.h
> ? src/Traversal.h
> Index: src/Makefile
> ===================================================================
> RCS file: /cvsroot/ctool/ctool/src/Makefile,v
> retrieving revision 1.3
> diff -u -r1.3 Makefile
> --- src/Makefile	17 Jul 2002 21:03:54 -0000	1.3
> +++ src/Makefile	1 Aug 2003 06:24:00 -0000
> @@ -53,8 +53,8 @@
>  #	Source files and directories
>  #
>
> -DEMO_C_MAIN = ctdemo.cpp
> -DEMO_C_OBJ = ctdemo.o
> +DEMO_C_MAIN = PrintTraversal.cpp ctdemo.cpp
> +DEMO_C_OBJ = PrintTraversal.o ctdemo.o
>
>  LIBCT_FILES = \
>      context.cpp \
> @@ -197,7 +197,7 @@
>
>  gram.cpp gram.h:	gram.y
>  	$(BISON) $(BISON_V) -d -b gram -o gram.cpp $<
> -	$(MV) gram.cpp.h gram.h
> +	$(MV) gram.hpp gram.h
>

Re: [Ctool-develop] using ctool as a library

[Stefan S. <se...@sy...>]

Shaun Flisakowski wrote:
> 
> Limited forms of visitors exist, see TransUnit in project.h:
> 
>     void findStemnt( fnStemntCallback cb );
>     void findFunctionDef( fnFunctionCallback cb );
> 
> and Expression in express.h:
>     void findExpr( fnExprCallback cb );
> 
> The 'cgraph' example in examples/cgraph uses findFunctionDef() to  
> demonstrate how to create a call-graph for a program.
> 
> I have my doubts that this method is going to be powerful enough to  
> transfer the entire AST to another form though - they are intended for  
> users who need to collect information from the AST, or to make slight  
> tweaks to the AST before reprinting it.
> 
> If you try it, I'd like to hear your suggestions for improvements.

ok, I had a first try tonight at this: I added 'accept' methods to
a number of classes, which all accept a 'Traversal' object and call
an appropriate method on it to resolve the dynamic type.

I wrote a 'PrintTraversal' which should (once debugged and cleaned up)
do all the work that is now implemented by the various 'print' methods.
This is just an illustration of the pattern, but if you accept it, you
could remove all the 'print' methods from the individual classes,
as that code would then be completely contained in PrintTraversal.cpp.

The idea is then that the actual library would only contain the parser,
the individual node types, and the Traversal interface.
The PrintTraversal (and any other Traversal implementations users want
to implement) are part of the applications that actually use the library.

Specifically, the PrintTraversal would go into the 'ctdemo' application,
while the library would not contain any print functionality.

Speaking of the library, do you think it would make sense to build
it as a shared library ? Also, if you want to 'go public' with that,
I'd suggest a somewhat longer name such as 'libctool.so' instead of the
short and unspecific name 'libct.so'.

Finally, I'd suggest to rework the build system a little to make the
whole thing more flexible and portable. I'd suggest to use autoconf for
that, and I'm willing to provide a patch.

However, I'll be on vacation starting this weekend, so I'm only able
to work more on this project in two weeks.

Kind regards,
		Stefan

[Ctool-develop] running tests

[Stefan S. <se...@sy...>]

hi there,

I tried running the regression tests, but didn't get very
far. In fact, the problems I'm seeing look suspiciously like
configurational errors, so I assume the problem can easily
be solved (by someone with the necessary knowledge :-)

The output from the 'accept0' run is appended...

Thanks,
		Stefan

[Ctool-develop] more issues compiling ctool

[Stefan S. <se...@sy...>]

hi there,

I'v now successfully downloaded the cvs version of ctool.

Invoking 'make -C src/' results in an error, as bison
generates gram.hpp, not gram.cpp.h.
But since I'm not sure that that is the same on all platforms,
I'm not sending in a patch, hoping that someone else knows
what to do.

Regards,
		Stefan

Re: [Ctool-develop] little fixes

[Steven S. <ste...@cs...>]

Shaun Flisakowski wrote:
> As for your comment about vectors, cTool was originally written in C (as 
> the poorly named "CTree", which I now know is also a database product).  
> With version 2.0, I changed over to C++ so a class hierarchy could be 
> used to clean up the resulting AST - I was not looking to rewrite from 
> scratch using C++.

I know about CTree. I've used that too.

CTool is a huge improvement in usability over CTree, the interfaces are
much cleaner. The latest program I tried to write I started with CTree
because that's what I had handy and got into a real mess. When I
changed to CTool, all the complexities disappeared and I could spend
my time concentrating on deciding what I wanted to do instead of how to
do it.

However, CTool is still showing its C roots. Too much of the internal
workings of the data structure are exposed. This makes it very
difficult to change any detail of the implementation.

For example, suppose I had needed a fast insertBefore method. This
would have required updating the Statement data structure to be
doubly linked. Since the next pointers are exposed, I'd have no control
over what external code is using them to manipulate the data structure.
If the manipulation did not take into account the new pointers I would
have needed to add, then the result would have been a complete mess.

Hiding all the implementation details will allow future changes to
the internal workings. At the moment you don't even have to change
the implementation, just hide all the variables and work out what
actions are needed on the objects.

Hiding the variables, however, will break any existing program that
relies on the current implementation. It would have to be reserved
for the next major version.

Do you have a good idea what sort of tools people are building with
CTool amd hence what manipulation options they need?

	- Steven
-- 



**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: [Ctool-develop] using ctool as a library

[Shaun F. <fli...@so...>]

Limited forms of visitors exist, see TransUnit in project.h:

     void findStemnt( fnStemntCallback cb );
     void findFunctionDef( fnFunctionCallback cb );

and Expression in express.h:
	void findExpr( fnExprCallback cb );

The 'cgraph' example in examples/cgraph uses findFunctionDef() to  
demonstrate how to create a call-graph for a program.

I have my doubts that this method is going to be powerful enough to  
transfer the entire AST to another form though - they are intended for  
users who need to collect information from the AST, or to make slight  
tweaks to the AST before reprinting it.

If you try it, I'd like to hear your suggestions for improvements.

Thanks,
Shaun

On Thursday, July 31, 2003, at 01:02  PM, Stefan Seefeld wrote:

> Shaun Flisakowski wrote:
>> Stefan,
>> The best example to look at is probably the code that prints out the   
>> AST.  This starts at:
>>     operator<<(std::ostream& out, const TransUnit& tu)
>> in project.cpp
>> Each translation unit is composed of a list of statements, an  
>> hierarchy  of C++ classes for each type (for, while, expression,  
>> etc).  Each of  the statements has members in it that give pointers  
>> to the expressions  it uses, or in some cases, the statement >> required.
>> Most of the members of the AST are public, you can just reach in and   
>> grab what you need.
>
>
> I see. Well, what do you think of the visitor pattern as a general way
> to traverse the tree ? Each type and statement type would implement an
> 'accept' method (say), which only calls a visitor's 'visit' method with
> the appropriate type.
>
> Then you could provide specific visitors to print out what the current  
> 'print' methods do, and I could write my own visitor(s) to map ctool's
> AST to my own.
>
> I think such a traversal is useful because else everybody has to
> reimplement the traversing mechanism.
>
> Regards,
> 		Stefan
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/ 
> direct;at.aspnet_072303_01/01
> _______________________________________________
> Ctool-develop mailing list
> Cto...@li...
> https://lists.sourceforge.net/lists/listinfo/ctool-develop
>

Re: [Ctool-develop] little fixes

[Shaun F. <fli...@so...>]

Steven,

I've committed your insertBefore() method to CVS.

As for your comment about vectors, cTool was originally written in C=20
(as the poorly named "CTree", which I now know is also a database=20
product).  With version 2.0, I changed over to C++ so a class hierarchy=20=

could be used to clean up the resulting AST - I was not looking to=20
rewrite from scratch using C++.

Thanks,
Shaun

On Thursday, July 31, 2003, at 11:29  AM, Steven Singer wrote:

> Stefan Seefeld wrote:
>> +++ src/decl.cpp	2003-07-31 11:09:43.000000000 -0400
>> @@ -128,7 +128,7 @@
> [...]
>> -			cout << " ";
>> +			std::cout << " ";
>
> Nope, should be 'out' not 'cout' or 'std::cout' otherwise when you're
> outputting to a file the spaces go to the wrong place.
>
> This bug has been noted before and has been fixed. It's ID 610027.
> Go to the bugs list on SourceForge and select Status: Any instead of
> the default status Open.
>
> I can't comment on your other fixes. I think my version of gcc is so
> old it lets me get away without the std::.
>
> While we're on the subject of patches ... For a project I was writing
> I needed a way of inserting a statement before another given
> statement. The only function I could see for insertion inserted after
> a given statement, so I wrote a function to do what I wanted. I've =
left
> the linked list singly linked so the insertion time is fairly poor, =
but
> it was fine for my implementation.
>
> Anyway, isn't writing your own linked list code a bit pass=E9 =
nowadays,
> shouldn't we be using the STL. (No, I'm not volunteering).
>
> I've attached the patch to this e-mail rather than putting it inline
> as something in my mail system appears to be messing around with
> spaces at the start of lines. This is kind of unfortunate for diffs.
>
> 	- Steven
> --=20
>

Re: [Ctool-develop] using ctool as a library

[Stefan S. <se...@sy...>]

Shaun Flisakowski wrote:
> Stefan,
> 
> The best example to look at is probably the code that prints out the  
> AST.  This starts at:
>     operator<<(std::ostream& out, const TransUnit& tu)
> in project.cpp
> 
> Each translation unit is composed of a list of statements, an hierarchy  
> of C++ classes for each type (for, while, expression, etc).  Each of  
> the statements has members in it that give pointers to the expressions  
> it uses, or in some cases, the statement required.
> 
> Most of the members of the AST are public, you can just reach in and  
> grab what you need.


I see. Well, what do you think of the visitor pattern as a general way
to traverse the tree ? Each type and statement type would implement an
'accept' method (say), which only calls a visitor's 'visit' method with
the appropriate type.

Then you could provide specific visitors to print out what the current 
'print' methods do, and I could write my own visitor(s) to map ctool's
AST to my own.

I think such a traversal is useful because else everybody has to
reimplement the traversing mechanism.

Regards,
		Stefan

Re: [Ctool-develop] using ctool as a library

[Shaun F. <fli...@so...>]

Stefan,

The best example to look at is probably the code that prints out the  
AST.  This starts at:
	operator<<(std::ostream& out, const TransUnit& tu)
in project.cpp

Each translation unit is composed of a list of statements, an hierarchy  
of C++ classes for each type (for, while, expression, etc).  Each of  
the statements has members in it that give pointers to the expressions  
it uses, or in some cases, the statement required.

Most of the members of the AST are public, you can just reach in and  
grab what you need.

Thanks,
Shaun

On Thursday, July 31, 2003, at 10:06  AM, Stefan Seefeld wrote:

> hi there,
>
> I'm looking into ctool in an attempt to figure out whether
> I could use it as a C parser backend for another introspection
> tool I'm working on (http://synopsis.sf.net). Synopsis uses
> an abstract syntax tree (AST) internally, which is generated
> from parser modules. Right now we have parser modules for C++,
> python, and IDL. Adding C to the list would be quite a win.
>
> I couldn't figure out yet how to traverse the syntax tree
> the ctool internally generates. I'd be grateful for any
> hints. Thanks,
> 		Stefan
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/ 
> direct;at.aspnet_072303_01/01
> _______________________________________________
> Ctool-develop mailing list
> Cto...@li...
> https://lists.sourceforge.net/lists/listinfo/ctool-develop
>

Fwd: [Ctool-develop] little fixes

[Shaun F. <fli...@so...>]

Stefan,

As Steven noted, these have already been fixed on the CVS head.  I was 
able to update fine from sf.net's just now - what kind of troubles are 
you experiencing?

printType: cout -> out
FunctionType() constructor  - default initializer is commented out
StringConstant - uses std:: already

I guess perhaps a new bug-fix release is overdue if the released code 
still has these issues.

Thanks,
Shaun

On Thursday, July 31, 2003, at 08:19  AM, Stefan Seefeld wrote:

> hi there,
>
> trying to compile the ctool code with gcc 3.2, I run into two
> minor issues with missing 'std::' prefixes and a redundant
> default initializer. The patches are appended. (the diff is
> against the latest release (2.11), as sf.net's cvs service
> isn't working properly (sigh).
>
> Regards,
> 		Stefan
> --- src/decl.cpp,orig	2002-03-31 19:29:44.000000000 -0500
> +++ src/decl.cpp	2003-07-31 11:09:43.000000000 -0400
> @@ -128,7 +128,7 @@
>          printBase(out,level);
>
>  		if (name != NULL)
> -			cout << " ";
> +			std::cout << " ";
>  	}
>
>      printBefore(out,name,level);
> @@ -630,7 +630,7 @@
>  }
>
>  // o+o+o+o+o+o+o+o+o+o+o+o+o+o+o+o+o+o+o+o+o+o+o+o+o+o+o+o+o+o+o+o
> -FunctionType::FunctionType(Decl *args_list = NULL)
> +FunctionType::FunctionType(Decl *args_list)
>    : Type(TT_Function), KnR_decl(false), nArgs(0), size(0), 
> args(NULL), subType(NULL)
>  {
>     addArgs (args_list);
> --- src/lexer.l,orig	2002-03-31 19:28:08.000000000 -0500
> +++ src/lexer.l	2003-07-31 11:10:19.000000000 -0400
> @@ -577,7 +577,7 @@
>                           LAST_STATE();
>                           *tokn_ptr = '\0';
>                           lvalp->consValue =
> -                           new 
> StringConstant(string(tokn_buff,tokn_ptr-tokn_buff),HERE,isWide);
> +                           new 
> StringConstant(std::string(tokn_buff,tokn_ptr-tokn_buff),HERE,isWide);
>                           return(err_tok = STRING);
>                         }
>

Re: [Ctool-develop] little fixes

[Steven S. <ste...@cs...>]

Stefan Seefeld wrote:
> +++ src/decl.cpp	2003-07-31 11:09:43.000000000 -0400
> @@ -128,7 +128,7 @@
[...]
> -			cout << " ";
> +			std::cout << " ";

Nope, should be 'out' not 'cout' or 'std::cout' otherwise when you're
outputting to a file the spaces go to the wrong place.

This bug has been noted before and has been fixed. It's ID 610027.
Go to the bugs list on SourceForge and select Status: Any instead of
the default status Open.

I can't comment on your other fixes. I think my version of gcc is so
old it lets me get away without the std::.

While we're on the subject of patches ... For a project I was writing
I needed a way of inserting a statement before another given
statement. The only function I could see for insertion inserted after
a given statement, so I wrote a function to do what I wanted. I've left
the linked list singly linked so the insertion time is fairly poor, but
it was fine for my implementation.

Anyway, isn't writing your own linked list code a bit passé nowadays,
shouldn't we be using the STL. (No, I'm not volunteering).

I've attached the patch to this e-mail rather than putting it inline
as something in my mail system appears to be messing around with
spaces at the start of lines. This is kind of unfortunate for diffs.

	- Steven
-- 


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

[Ctool-develop] using ctool as a library

[Stefan S. <se...@sy...>]

hi there,

I'm looking into ctool in an attempt to figure out whether
I could use it as a C parser backend for another introspection
tool I'm working on (http://synopsis.sf.net). Synopsis uses
an abstract syntax tree (AST) internally, which is generated
from parser modules. Right now we have parser modules for C++,
python, and IDL. Adding C to the list would be quite a win.

I couldn't figure out yet how to traverse the syntax tree
the ctool internally generates. I'd be grateful for any
hints. Thanks,
		Stefan

[Ctool-develop] little fixes

[Stefan S. <se...@sy...>]

hi there,

trying to compile the ctool code with gcc 3.2, I run into two
minor issues with missing 'std::' prefixes and a redundant
default initializer. The patches are appended. (the diff is
against the latest release (2.11), as sf.net's cvs service
isn't working properly (sigh).

Regards,
		Stefan

[Ctool-develop] String problem

[Trampas S. <ts...@st...>]

It has been a long time since I used C++ but I found that the string
needed to be std:string. I also ran into some other minor errors. I
think the ctool demo example for MSVC++ was very old. Therefore I had to
replace the lexer.cpp with a more recent version as well as add the
context.cpp to the project.

 

Basically I would like to take Ctool and make a better preprocessor.
That is I would like a preprocessor which know more about the C syntax.
Imagine a preprocessor that knows the type of the variable passed to it.


 

Regards,

Trampas Stern