[Moose-g3-devel] #lines (was "questions about MOOSE")

[Josef S. <js...@ya...>]

--- "Upinder S. Bhalla" <bh...@nc...> wrote:

> Greg Hood said:
> > 3. mpp preprocessor
> > If someone has an X.mh file and runs it through the mpp preprocessor,
> then
> > they get X.h, XWrapper.h, and XWrapper.cpp files out.  Under what
> circumstances
> > does one need to hand modify these files?  I would argue that this
> should
> > never be happen.  Here's a thought: why not have a single X.moose file
> that
> > contains all information about the MOOSE classes, and let mpp translate
> this
> > into read-only X.h, X.cpp, XWrapper.h, and XWrapper.cpp files, possibly
> locating these in a C++/ subdirectory so they will not clutter up the
> developer's working directory.  The MOOSE developer should not have to
> directly deal with these .h and .cpp files anyway.  By judicious use of
> #line directives in the .h and .cpp files, any errors in the C++
> compilations can be referred back to the original X.moose file.
> 
> This is almost exactly what I would like and am working toward. At this
> point the preprocessor is incomplete, partly because the base code still
> has some way to go. But you'll find that revision 5 is _much_ improved and
> can do about 95% of the job of generating X.h, XWrapper.h and XWrapper.cpp
> files without user intervention. More like 100% in the case of
> straightforward classes, which are what most users would need.
> One difference is that the X.cpp file is intentionally not supported. The
> idea is that this is stuff that the user will want to code independently
> of the wrapper stuff. For example, if there were serious calculations
> needed inside an object, we don't want to squash it all into the X.mh file
> (think of the X.mh file as a super 'header' file). These would then go
> into X.cpp. The X.cpp functions need not know about MOOSE at all.
> BTW, I am not keen to use #lines. Phenomenally ugly!

I agree that these are ugly, but you can take some license with generated code
since the hope is that ultimately noone should ever have to look at it.



js...@ya...
Software Engineer
Linux/OSX C/C++/Java