C++ code generator

[christopher diggins]

I am considering writing a code generator which takes interfaces
specifications in the following style:

interface IStack<class Elem_T>
invariant: // number of items pushed >= number of items popped
{
Bool IsEmpty();
precondition: result = number of items pushed == number of items popped
void Push(const Elem_T& x);
void Pop();
precondition: IsEmpty() == false
postcondition: // result = most recent pushed item which hasn't been
popped
const Elem_T& Top();
precondition: IsEmpty() == false
}

The code generator would output a C++ class to represent the interface (
using the BIL, see http://www.codeproject.com/cpp/retrofitpolymorphism.asp )
It would also output a contract class which verifies the preconditions /
postconditions / etc. It would also ouput a stub implementation class. That
is a class which implements the interface but does nothing.

This is actually only scratching the surface of what I would do with it: I
would also support pseudo-code class definitions, which implement Heron
style classes.

The feature list for the classes would be considerably more far reaching:
- aspect oriented programming support (
http://www.heron-language.com/aspect...ogramming.html )
- self / inherited keywords
- delegation
- implicit result variables
- properties
- _ctor and _dtor named constructors and destructors

I am trying to gauge the level of interest in such a tool. Thanks in
advance, and feel free to share your two cents.

--
Christopher Diggins
http://www.cdiggins.com
http://www.heron-language.com

[Puppet_Sock]

christopher diggins wrote:

I am considering writing a code generator which takes interfaces
specifications in the following style:

interface IStack<class Elem_T>
invariant: // number of items pushed >= number of items popped
{
Bool IsEmpty();
precondition: result = number of items pushed == number of items popped void Push(const Elem_T& x);
void Pop();
precondition: IsEmpty() == false
postcondition: // result = most recent pushed item which hasn't been popped
const Elem_T& Top();
precondition: IsEmpty() == false
}

Code generation tools are good things in most cases. However,
there's something, um, skewed about requiring psuedo code as
input to such a tool. The level of effort required to create
the input you've typed here is too large compared to the result.

Instead, how about a menu driven something-or-other that lets
you select certain items from a list, then blasts the appropriate
text into a file for you. Put a nice GUI on there and you've got
something.

Of course, with the example you've got, what you've got is a
fairly straightforward template class. So, the question that
arises fairly quickly is, what's wrong with just providing that
fairly straightforward template class? Template classes are
pretty cool.
Socks

[christopher diggins]

"Puppet_Soc k" <pu*********@ho tmail.com> wrote in message
news:11******** **************@ f14g2000cwb.goo glegroups.com.. .

christopher diggins wrote:

I am considering writing a code generator which takes interfaces
specifications in the following style:

interface IStack<class Elem_T>
invariant: // number of items pushed >= number of items popped
{
Bool IsEmpty();
precondition: result = number of items pushed == number of items popped

void Push(const Elem_T& x);
void Pop();
precondition: IsEmpty() == false
postcondition: // result = most recent pushed item which hasn't

been

popped
const Elem_T& Top();
precondition: IsEmpty() == false
}

Code generation tools are good things in most cases. However,
there's something, um, skewed about requiring psuedo code as
input to such a tool. The level of effort required to create
the input you've typed here is too large compared to the result.

I don't see how I could reduce it down further.

Take a look at the code needed to replicate the interface:

template<typena me Elem_T>
BOOST_IDL_BEGIN 1(IStack)
BOOST_IDL_FN1(P ush, void, (const Elem_T&, x))
BOOST_IDL_FN0(P op, const Elem_T&)
BOOST_IDL_FN0(P eek, const Elem_T&)
BOOST_IDL_FN0(I sEmpty, Bool)
BOOST_IDL_END1( IStack)

There is the contract:

template<typena me Stack_T, typename Elem_T>
struct Stack_contract : public Stack_T
{
// type identities
typedef Stack_T inherited;
// constructor
Stack_contract( ) { }
template<typena me Arg_T> Stack_contract( const Arg_T& x) : inherited(X)
{ };
// contract verification
const Elem_T& Pop() { PRE(!IsEmpty()) ; return inherited::Pop( ); }
const Elem_T& Peek() { PRE(!IsEmpty()) ; return inherited::Peek (); }
};

The wrapper :

template<typena me Stack_T, typename Elem_T>
struct Stack_wrapper
{
#ifdef APPLY_CONTRACTS
typedef Stack_ext<Stack _contract<Stack _T, Elem_T>, Elem_T> type;
#else
typedef Stack_ext<Stack _T, Elem_T> type;
#endif
};

And a stub:

template<typena me Elem_T>
struct Stack_strub
{
Stack_stub() { }
// IStack implementation
const Elem_T& Peek() { }
const Elem_T& Pop() { }
void Push(const Elem_T& x) { }
Bool IsEmpty() { }
};
Instead, how about a menu driven something-or-other that lets
you select certain items from a list, then blasts the appropriate
text into a file for you. Put a nice GUI on there and you've got
something.
This is an interesting idea.
Of course, with the example you've got, what you've got is a
fairly straightforward template class. So, the question that
arises fairly quickly is, what's wrong with just providing that
fairly straightforward template class? Template classes are
pretty cool.
All of this is not as easy to implement as it might seem on first glance
check out http://www.ootl.org/src/collections.hpp
Socks

Thanks for your feedback
CD

[fuzzylollipop]

what you have to ask yourself is why create yet another templating
language.

C++ has one built in already.
There is already a standard IDL, for doing just this.
There is XML/UML formats for this also ->
http://www.yy.ics.keio.ac.jp/~suzuki/project/uxf/
Tools like SWIG do this already for other languages to C/C++ mappings.
There are tonnes of template based parsers and frameworks, some like
EMF that are already integrated into an IDE ( Eclipse )

second you have to answer, is your idea and implementation so much
better than everyone elses that people are going to drop what they are
doing, learn your NEW language/syntax/api or whatever and adopt it
because it saves them so much time and effort ( including the learning
curve ).
First pass at your suggestion my answer to the second question is a NO.