Re: How can I use unqualified names? (Possibly hard or impossible?)
* James Kanze:
On Jul 25, 11:23 am, "Alf P. Steinbach" <al...@start.no> wrote:
* James Kanze:
I don't know. I don't really understand what's going on,
without seeing the definitions of the macros you're using.
They're ugly! :-)
Or "in-elegant"...
Hence the plea for simpler pure-C++ solution that supports the
same, in particular extension and simple notation (client
code).
Just curious, but why does it have to be "pure-C++"? As I said
earlier, a short AWK script does the job just fine.
Why not pure C++?
If something as simple as this can't be expressed easily, then at least we can
(perhaps, hopefully) find out where the flaws in the language are.
BTW: What is the Windows equivalent of AWK?
VBScript.
There must be one,
or do all Windows programmers have CygWin or something similar
installed?
Yes. Plus freestanding *nix tools for Windows. And there must be some who run
Microsoft Services for Unix (SFU), which gives you *nix in Windows, with g++
redistributed by Microsoft...
Or Perl---you could easily do it in Perl, if you
can stand Perl? Or probably Python or Ruby, or just about any
"small language" that's text oriented. (All of the Windows
programmers I know do use CygWin, so maybe there is something
essential for program development missing in Windows.)
Not so much that Windows is missing stuff (it is, e.g. backquoting is horrible)
so much that e.g. most build scripts for libraries depend on *nix tools.
Anyway...
<code>
#include <boost/mpl/clear.hpp>
#include <boost/mpl/front.hpp>
#include <boost/mpl/inherit.hpp>
#include <boost/mpl/inherit_linearly.hpp>
#include <boost/mpl/list.hpp>
#include <boost/mpl/pop_front.hpp>
namespace cppx { namespace typelist {
typedef boost::mpl::clear< boost::mpl::list<> >::type Empty;
You've already lost me. I don't have the slightest knowledge of
Boost::mpl, and in general, I find most of the advanced
meta-programming idioms too complicated for general use.
I don't have the slightest knowledge either. I just used the MPL typelist,
checking the docs as I wrote, instead of locating or downloading new version of
Loki, or writing one from scratch (it's pretty simple, really). The above
expression is probably overkill for its purpose: it addresses that the type of
'mpl::list<>', a logically empty list of types, is not the same as the type of
an empty list produced by reduction of a list. Probably just
typedef boost::mpl::list<>::type Empty;
would suffice to define the "real" empty list type.
But I don't know, I've never used that typelist implementation before, and was a
bit surprised that this was necessary.
At any rate, you've something like 200 lines of very complicated
code, to do something that can be done much simpler outside of
the language, or even with macros. Whereas something like:
#! /usr/bin/awk -f
/ *#/ { next }
NF == 3 || (NF > 3 && $4 ~ /^#/) {
++ optionCount
names[ optionCount ] = $1
types[ optionCount ] = $2
defaults[ optionCount ] = $3
next
}
{
printf( "[%s:%d]: syntax error\n", FILENAME, FNR ) > "/dev/
stderr"
}
END {
printf( "class Options\n" )
printf( "{\n" )
printf( "public:\n" )
printf( " Options::Options()\n" )
for ( i = 1 ; i <= optionCount ; ++ i ) {
printf( " %c %s( %s )\n", i == 1 ? ":" : "," ,names
[ i ], defaults[ i ] )
}
printf( " {\n" )
printf( " }\n" )
for ( i = 1 ; i <= optionCount ; ++ i ) {
name = names[ i ]
type = types[ i ]
printf( " %s %s() const\n", type, name )
printf( " {\n" )
printf( " return my_%s;\n", name )
printf( " }\n" )
printf( " Options& %s( %s new_%s )\n", name, type,
name )
printf( " {\n" )
printf( " my_%s = new_%s ;\n", name, name )
printf( " return *this ;\n" )
printf( " }\n" )
}
printf( "private:\n" )
for ( i = 1 ; i <= optionCount ; ++ i ) {
printf( " %s my_%s ;\n", types[ i ], names[ i ] )
}
printf( "} ;\n" )
}
, invoked with "genOptions.awk -v className=Options
options.lst", is less than 50 lines (and would be less if I'd
compromize on the formatting of the generated class),
Well 150 lines of code isn't much to talk about, really. :-)
and is a lot simpler.
Only where it doesn't matter: for producing that support code in the first place.
For using it I think an all C++ solution such as my Friday code is much simpler,
both with respect to using it from scratch, with respect to maintainance (no
redundancy), and with respect to build configuration.
(For one time use, this could be made even
simpler, by dropping support for comments, error checking, etc.
Or with very little effort and additional code, it could be made
more generic, supporting more than one specification in the same
file, with the class name specified in the file, and generating
two files, a header and source, for each class.
For that matter, if you're willing to use macros, what does your
solution buy you over:
#define MYPREFIX_DECLARE_ATTR( class ,name, type,
defaultValue ) \
private: \
Fallible< type > my_ ##
name ; \
public: \
type name()
const \
{ \
return my ## name.elseDefaultTo
( defaultValue ) ; \
}
\
class& name( type new_ ##
name ) \
{ \
my ## name.validate( new_ ##
name ) ; \
return
*this ; \
}
class Options
{
#define MYPREFIX_OPTION( name, type, defaultValue ) \
MYPREFIX_DECLARE_ATTR( Options, name, type, defaultValue )
MYPREFIX_OPTION( x, double, 3.14159 ) ;
MYPREFIX_OPTION( y, int, 42 ) ;
// ...
#undef MYPREFIX_OPTION
} ;
?
This does not produce an extensible class.
In particular it can not, AFAICS, be used to produce the two option classes in
my example usage code shown earlier in thread (natural modifications OK, of
course), which you'll see if you try.
But you make me wonder: what does the script buy you over the above, which
AFAICS offers the same functionality with less code and easier maintainance?
The resulting class will be bigger than necessary (since each
Fallible requires an additional bool), and slightly slower, at
least if the types involved are cheap to construct, but I doubt
that it really matters in most cases.
If that's all that you require of the class then that scheme is superb, because
it's simple. :-) But the little inefficiency is not necessary. Just replace
Fallible with a class that constructs the contained value with the specified
default. Of course you need one such class per option, even when the options are
of the same type. And then you have the basic options-as-types scheme... ;-)
But the above is not a superb solution to my little problem, for it does not let
you extend the resulting class except by requiring the code that uses the
setters to always use base class setters last, which to me feels very wrong.
I think that problem indicates that there's a missing feature in C++, because it
"should" be trivial to express, and indeed is trivial in any scripting language.
Cheers, & thanks,
- Alf