Re: How can I use unqualified names? (Possibly hard or impossible?)
On Jul 26, 11:11 am, "Alf P. Steinbach" <al...@start.no> wrote:
* 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++?
Because some other tool does the job better? "Pure C++" isn't a
particular goal in my mind, any more than "pure OO" or pure
anything else. I use the tools best fitted for the job.
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.
Why is it necessarily a flaw in the language? No tool can be
perfect for everything. Use the most appropriate tool.
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...
OK. (I'm starting a new job in September, in a purely Windows
environment. It will be the first time in my life I've been in
a purely Windows environment.)
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.
In a way, I'm happy to hear that. It means that I already know
a significant (and for me important) part of the environment
where I'm going:-).
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.
Well, that sounds like another reason to use something else. I
wouldn't use a tool that I didn't at least vaguely understand.
(It's a difficult issue, of course---I suspect that most C++
programmers wouldn't be capable of writing a C++ compiler, and
they shouldn't need that knowledge. But I don't even know what
Boost::mpl---or anything in Loki---really does.)
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 ? ":" : "," ,name=
s
[ 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. :-)
If it's fairly trivial and easy to understand:-).
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 using it, there is one argument in favor of all C++, if it's
straightforward: presumable new people on the project will
understand it immediately. IMHO, as soon as you use Boost::mpl,
or Loki, you've lost that advantage. As for maintenance: the
input file for my AWK script looks something like:
x double 3.14159
y int 42
# ...
It's hard for me to imagine anything easier to maintain---to add
a new attribute, it's one line. (In the form I actually use,
the AWK script is about twice as long, and the input has the
form:
[Option] # the class name...
x double 3.14159
y int 42
# ...
The results are two files, Option.hh and Option.cc.)
Of course, if you really want pure C++... I've also got classes
to facilitate used C++ programs to generate C++, and with even a
minimum of the usual C++ stuff, rewriting the AWK in C++
shouldn't pose any great problem. In this case, the AWK doesn't
really use any of the special functionality of AWK. It's just
that for me, for such small programs, I find AWK simpler. (I
have cases where the generation is significantly more complex,
in which case, I do use C++.)
(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.
Extensible in what way?
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.
I'll look at it, but I'll admit that I've never found any reason
to "extend" an options class. They're normally one-of sort of
things.
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?
First, the AWK stuff doesn't use macros, so doesn't impinge on
the global namespace in anyway. (My actual AWK script handles
options to specify the namespace in which to build the class,
files to include, etc.) And the AWK stuff generates a complete
class; there's absolutely nothing else to do. Still, for a
one-of use, I'd use the above; the AWK script came about because
it fulfilled a more or less recurrent need.
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.
But then you have to maintain the default outside of the macro
declarations. IMHO, it's not usually a big deal, but it does
mean that you have to cite the name of the attribute twice, and
update in two locations if you add one.
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... ;-)
I'm not sure I follow. You need one class for each distinct set
of options. Typically, in a GUI, there will only be one or two
distinct sets of options... in a lot of GUI's, there will only
be one (although some components may ignore certain options).
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.
The basic problem is that you're "generating" code. Which is
fairly simple to express in interpreted languages like Lisp or
the shell, which can interpret the code you've just generated.
(In classical computer science, this is called "self modifying
code", and has a very bad reputation with regards to
maintainability. There are very good reasons why such
interpreted languages aren't used for critical systems.) I've
one or two applications which use such techniques, but they're
written in Unix shell, not in C++. (In one case, I have the
moral equivalent of "awk -f someProgram.awk file1 | awk -f -
file2 | isql", the awk script "someProgram.awk" reads a
configuration file to generate an awk script which is used to
generate SQL. It some ways, it's very elegant, but it can be a
real pain in the ass to maintain. Finding a bug in the SQL is a
pain, when the SQL is generated dynamically at each execution.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34