www.digitalmars.com         C & C++   DMDScript  

c++.stlsoft - latest YARD parser release

reply "christopher diggins" <cdiggins videotron.ca> writes:
I have just made a new release of the YARD parser at 
http://www.sf.net/projects/yard-parser/ , which fixes a lot of the microsoft 
specific dependencies.

-- 
Christopher Diggins
Object Oriented Template Library (OOTL)
http://www.ootl.org
Mar 02 2005
next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
No makefiles, project files, readme.

Where does one start?

"christopher diggins" <cdiggins videotron.ca> wrote in message 
news:d050g9$ejl$1 digitaldaemon.com...

I have just made a new release of the YARD parser at 
http://www.sf.net/projects/yard-parser/ , which fixes a lot of the 
microsoft specific dependencies.

 -- 
 Christopher Diggins
 Object Oriented Template Library (OOTL)
 http://www.ootl.org
Mar 02 2005
parent reply "christopher diggins" <cdiggins videotron.ca> writes:
Whoops, sorry.

Added a project file.
http://sourceforge.net/project/showfiles.php?group_id=126822&package_id=139243&release_id=309752

-- 
Christopher Diggins
Object Oriented Template Library (OOTL)
http://www.ootl.org
Mar 02 2005
parent reply "Zz" <Zz Zz.com> writes:
Hi,

Just out of curiosity, I now see that Yard requires OOTL, I thought that it
was supposed to be independent of other libraries.

I got it to compile under Visual Studio but not after changing the paths.

Zz
"christopher diggins" <cdiggins videotron.ca> wrote in message
news:d058v4$nq5$1 digitaldaemon.com...

 Whoops, sorry.

 Added a project file.


http://sourceforge.net/project/showfiles.php?group_id=126822&package_id=139243&release_id=309752

 -- 
 Christopher Diggins
 Object Oriented Template Library (OOTL)
 http://www.ootl.org
Mar 02 2005
parent reply "christopher diggins" <cdiggins videotron.ca> writes:
"Zz" <Zz Zz.com> wrote in message news:d05eoi$vi2$1 digitaldaemon.com...

 Hi,

 Just out of curiosity, I now see that Yard requires OOTL, I thought that 
 it
 was supposed to be independent of other libraries.


YARD itself should only need char_set. I should probably move char_set back 
into the YARD namespace, I just can't make up my mind. Apart from this the 
tests themselves need other parts of the OOTL.


 I got it to compile under Visual Studio but not after changing the paths.


Is this a bad thing I did? How should I deal with this? I am new to sharing 
libraries of code with other people.

Did it pass the tests successfully? Would you mind trying to compile it 
under Metrowerks as well?

Thanks!

-- 
Christopher Diggins
Object Oriented Template Library (OOTL)
http://www.ootl.org
Mar 02 2005
next sibling parent "Zz" <Zz Zz.com> writes:
Hi,


 YARD itself should only need char_set. I should probably move char_set


back

 into the YARD namespace, I just can't make up my mind. Apart from this the
 tests themselves need other parts of the OOTL.


 I got it to compile under Visual Studio but not after changing the




paths.

 Is this a bad thing I did? How should I deal with this? I am new to


sharing

 libraries of code with other people.


I just move the stuff up so that ../../cpp can be found. (I'm a CodeWarrior
user).


 Did it pass the tests successfully? Would you mind trying to compile it
 under Metrowerks as well?


Under Visual Studio the tests compiled passed.

CodeWarrior complains of a lot of things I actually get 100 errors and 17
warnings.
It also fails under Intel's compiler.

Zz.
Mar 02 2005
prev sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"christopher diggins" <cdiggins videotron.ca> wrote in message 
news:d05g94$11dt$1 digitaldaemon.com...

 "Zz" <Zz Zz.com> wrote in message 
 news:d05eoi$vi2$1 digitaldaemon.com...

 Hi,

 Just out of curiosity, I now see that Yard requires OOTL, I thought 
 that it
 was supposed to be independent of other libraries.


 YARD itself should only need char_set. I should probably move char_set 
 back into the YARD namespace, I just can't make up my mind. Apart from 
 this the tests themselves need other parts of the OOTL.


 I got it to compile under Visual Studio but not after changing the 
 paths.


 Is this a bad thing I did? How should I deal with this? I am new to 
 sharing libraries of code with other people.


It should have a single make file that is used to build the libs (if 
any), the test file, and execute the test file.

Right now I'm using one of my tools - tmpl2make.py - to generate 
makefiles for Win32 and UNIX (for Borland, CodeWarrior, Comeau, DMC++, 
GCC, Intel, Visual C++, Watcom). It takes a template and a tools file 
(XML describing what tools there are, and what capabilities they have), 
and spits out makefiles (e.g. "makefile" for Borland/DMC++/VC++, 
"makefile.win32" + "makefile.unix" for CodeWarrior/Comeau/GCC/Intel)

The makefile should either be all relative, i.e. its -I commands are 
like -I../../include, or you should assume (and discriminate for, with 
MAKEs that can do so) the definition of environment/make cmd-line 
variables. You should _not_ have any absolutes.

Also, it's been my experience that one must step away from the IDDE 
(esp. VC++ .NET) as soon as possible, as it just makes this whole 
process more painful in the long run. (I still use such libs within 
IDEs, but with projects that do not necessarily form part of the 
distribution, and which certainly do not form part of the automated 
build/test/release process.)

I'd be happy to share (privately) the script with you, but it's not for 
public dissemination because it's, er, a bit scrappy. ;)
Mar 02 2005
parent reply "christopher diggins" <cdiggins videotron.ca> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
news:d05rnd$1duk$1 digitaldaemon.com...

 "christopher diggins" <cdiggins videotron.ca> wrote in message 
 news:d05g94$11dt$1 digitaldaemon.com...

 "Zz" <Zz Zz.com> wrote in message news:d05eoi$vi2$1 digitaldaemon.com...

 Hi,

 Just out of curiosity, I now see that Yard requires OOTL, I thought that 
 it
 was supposed to be independent of other libraries.


 YARD itself should only need char_set. I should probably move char_set 
 back into the YARD namespace, I just can't make up my mind. Apart from 
 this the tests themselves need other parts of the OOTL.


 I got it to compile under Visual Studio but not after changing the 
 paths.


 Is this a bad thing I did? How should I deal with this? I am new to 
 sharing libraries of code with other people.


 It should have a single make file that is used to build the libs (if any), 
 the test file, and execute the test file.

 Right now I'm using one of my tools - tmpl2make.py - to generate makefiles 
 for Win32 and UNIX (for Borland, CodeWarrior, Comeau, DMC++, GCC, Intel, 
 Visual C++, Watcom). It takes a template and a tools file (XML describing 
 what tools there are, and what capabilities they have), and spits out 
 makefiles (e.g. "makefile" for Borland/DMC++/VC++, "makefile.win32" + 
 "makefile.unix" for CodeWarrior/Comeau/GCC/Intel)

 The makefile should either be all relative, i.e. its -I commands are 
 like -I../../include, or you should assume (and discriminate for, with 
 MAKEs that can do so) the definition of environment/make cmd-line 
 variables. You should _not_ have any absolutes.

 Also, it's been my experience that one must step away from the IDDE (esp. 
 VC++ .NET) as soon as possible, as it just makes this whole process more 
 painful in the long run. (I still use such libs within IDEs, but with 
 projects that do not necessarily form part of the distribution, and which 
 certainly do not form part of the automated build/test/release process.)

 I'd be happy to share (privately) the script with you, but it's not for 
 public dissemination because it's, er, a bit scrappy. ;)



I don't have a python interpreter, but this gives me some excellent ideas. 
My next release will have make files.

Thanks!

-- 
Christopher Diggins
Object Oriented Template Library (OOTL)
http://www.ootl.org
Mar 03 2005
parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"christopher diggins" <cdiggins videotron.ca> wrote in message 
news:d07bdn$30o1$1 digitaldaemon.com...

 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
 news:d05rnd$1duk$1 digitaldaemon.com...

 "christopher diggins" <cdiggins videotron.ca> wrote in message 
 news:d05g94$11dt$1 digitaldaemon.com...

 "Zz" <Zz Zz.com> wrote in message 
 news:d05eoi$vi2$1 digitaldaemon.com...

 Hi,

 Just out of curiosity, I now see that Yard requires OOTL, I thought 
 that it
 was supposed to be independent of other libraries.


 YARD itself should only need char_set. I should probably move 
 char_set back into the YARD namespace, I just can't make up my mind. 
 Apart from this the tests themselves need other parts of the OOTL.


 I got it to compile under Visual Studio but not after changing the 
 paths.


 Is this a bad thing I did? How should I deal with this? I am new to 
 sharing libraries of code with other people.


 It should have a single make file that is used to build the libs (if 
 any), the test file, and execute the test file.

 Right now I'm using one of my tools - tmpl2make.py - to generate 
 makefiles for Win32 and UNIX (for Borland, CodeWarrior, Comeau, 
 DMC++, GCC, Intel, Visual C++, Watcom). It takes a template and a 
 tools file (XML describing what tools there are, and what 
 capabilities they have), and spits out makefiles (e.g. "makefile" for 
 Borland/DMC++/VC++, "makefile.win32" + "makefile.unix" for 
 CodeWarrior/Comeau/GCC/Intel)

 The makefile should either be all relative, i.e. its -I commands are 
 like -I../../include, or you should assume (and discriminate for, 
 with MAKEs that can do so) the definition of environment/make 
 cmd-line variables. You should _not_ have any absolutes.

 Also, it's been my experience that one must step away from the IDDE 
 (esp. VC++ .NET) as soon as possible, as it just makes this whole 
 process more painful in the long run. (I still use such libs within 
 IDEs, but with projects that do not necessarily form part of the 
 distribution, and which certainly do not form part of the automated 
 build/test/release process.)

 I'd be happy to share (privately) the script with you, but it's not 
 for public dissemination because it's, er, a bit scrappy. ;)



 I don't have a python interpreter, but this gives me some excellent 
 ideas. My next release will have make files.


Free at www.activestate.com (along with Perl)

Also I strongly suggest you install Ruby, as it's much the nicest of the 
three (IMO), and I've plenty of Ruby scripts that you might find 
helpful.

If you're wanting to create makefiles for multiple compilers, I suggest 
you come up with some kind of automation, otherwise your life's going to 
get very tough very quickly.

;)
Mar 03 2005
prev sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
For grins, I just ran it on a suite of compilers.

It's got a lot of problems, including:

    - uses non-standard std::exception::exception(char const *) ctor
    - uses undiscriminated #pragma once
    - plenty of missing typename type qualifiers
    - etc. etc.

I'd have to do a full run to get you all the details, but I suggest your 
best course of action is to get DMC++ 8.42beta and/or GCC 3.4 and ensure 
that it at least compilers with that/them along with VC++ 7.1. Once 
you've got that done, I'll lend a hand and get it compiling on the rest 
of the (Win32) majors. :-)

btw, I note you're using statics. Makes it non-thread-safe. You might 
want to check out the spin mutex technique in Chapters 10+11 of 
Imperfect C++. (STLSoft has spin mutexes, in both WinSTL and UNIXSTL.)

Cheers

Matthew

"christopher diggins" <cdiggins videotron.ca> wrote in message 
news:d050g9$ejl$1 digitaldaemon.com...

I have just made a new release of the YARD parser at 
http://www.sf.net/projects/yard-parser/ , which fixes a lot of the 
microsoft specific dependencies.

 -- 
 Christopher Diggins
 Object Oriented Template Library (OOTL)
 http://www.ootl.org
Mar 02 2005
next sibling parent reply "christopher diggins" <cdiggins videotron.ca> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
news:d05r59$1dfo$1 digitaldaemon.com...

 For grins, I just ran it on a suite of compilers.

 It's got a lot of problems, including:

    - uses non-standard std::exception::exception(char const *) ctor
    - uses undiscriminated #pragma once
    - plenty of missing typename type qualifiers
    - etc. etc.


Damn Microsoft. I really chose the wrong compiler to get familiar with. I 
miss the good old days of Turbo Pascal.


 I'd have to do a full run to get you all the details, but I suggest your 
 best course of action is to get DMC++ 8.42beta and/or GCC 3.4 and ensure


Okay then. I am going to use VC++ from now on as a last resort.


 that it at least compilers with that/them along with VC++ 7.1. Once you've 
 got that done, I'll lend a hand and get it compiling on the rest of the 
 (Win32) majors. :-)


Thanks.


 btw, I note you're using statics. Makes it non-thread-safe. You might want 
 to check out the spin mutex technique in Chapters 10+11 of Imperfect C++. 
 (STLSoft has spin mutexes, in both WinSTL and UNIXSTL.)


Sorry, but I don't own your book, I am poor as a pauper. Is thread-safety a 
requirement of STLSoft inclusion? I am not an expert in techniques for 
thread-safety, isn't it an enormous amount of work to write and test code 
for thread-safety? Or would spin mutexes automatically solve that problem? 
My personal preference is to ignore multi-threaded use scenarios.


 Cheers

 Matthew


Thanks for you help.

-- 
Christopher Diggins
Object Oriented Template Library (OOTL)
http://www.ootl.org
Mar 03 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"christopher diggins" <cdiggins videotron.ca> wrote in message 
news:d07aqf$2vt3$1 digitaldaemon.com...

 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
 news:d05r59$1dfo$1 digitaldaemon.com...

 For grins, I just ran it on a suite of compilers.

 It's got a lot of problems, including:

    - uses non-standard std::exception::exception(char const *) ctor
    - uses undiscriminated #pragma once
    - plenty of missing typename type qualifiers
    - etc. etc.


 Damn Microsoft. I really chose the wrong compiler to get familiar 
 with. I miss the good old days of Turbo Pascal.


 I'd have to do a full run to get you all the details, but I suggest 
 your best course of action is to get DMC++ 8.42beta and/or GCC 3.4 
 and ensure


 Okay then. I am going to use VC++ from now on as a last resort.


Well, I use VC++ 6.0 and Intel 8.0 as my workaday compilers, simply 
because I am very adept and comfortable in Visual Studio '98, and I 
refuse to use VS.NET. (Anything that makes me use the mouse more than 
once a day is a heap of flatulent dung, IMO. To be fair, it may be that 
one can customise VS.NET to obviate the need for mouse use, but I've not 
had time to work it out in the last couple of years. In any case, the 
load time on my machines - even on with 1GB memory - is just howlingly 
bad. I'm a very impatient person ...)

Having said all that, VC++ 7.1 is a very good compiler, and is *always* 
included on my build list. It, along with CodeWarrior, Comeau, GCC and 
Intel form the 'authoritative' quintet: when I get them to agree, I have 
a very high confidence that any other compiler that demurs is wrong.)

(One of the more frivulous aims of the Arturius Compiler Multiplexer 
project - woefully behind - is to enable me to use VC++ 7.1 within 
VS'98. Then I'll *never* have to "upgrade". <g>)


 that it at least compilers with that/them along with VC++ 7.1. Once 
 you've got that done, I'll lend a hand and get it compiling on the 
 rest of the (Win32) majors. :-)


 Thanks.


No worries.

To do this, YARD'll have to include STLSoft headers (for compiler 
discrimination, dealing with iterators and such) at a high level. 
Naturally this is not commensurate with Boost, so what I'd recommend if 
you want it to work with both is a <yard.hpp> wherein all the STLSoft / 
Boost stuff's brought in and abstracted into YARD_-specific stuff. For 
example, you'd do something like the following:

    #if defined(YARD_USE_BOOST)
    #elif defined(YARD_USE_STLSOFT)
    #else

define one of YARD_USE_BOOST or YARD_USE_STLSOFT
    #endif

    #ifdef YARD_USE_STLSOFT








    etc. etc.


    #endif /* YARD_USE_STLSOFT */


It'd be a fair amount of work, but it depends on what spectrum of 
compiler capabilities YARD requires, and how forgiving of crappy old 
compilers you want to be. If you're happy to stick with the most modern 
versions of the most modern compilers Comeau 4.3.3, CodeWarrior 8+, VC++ 
7.1+, DMC++ 8.42+, GCC 3.3+, Intel 7+, then you probably won't have too 
much trouble. However, if you want, as I generally do, to support VC++ 
6.0 ('cos this increases your potential user base enormously), then 
you'll have more hoop jumping than you might like.



 btw, I note you're using statics. Makes it non-thread-safe. You might 
 want to check out the spin mutex technique in Chapters 10+11 of 
 Imperfect C++. (STLSoft has spin mutexes, in both WinSTL and 
 UNIXSTL.)


 Sorry, but I don't own your book, I am poor as a pauper. Is 
 thread-safety a requirement of STLSoft inclusion?


Yes and no. It assumes roughly the same as most implementations of the 
STL: instances need not be accessible to multiple threads, but APIs 
should be thread-safe. Hence, because you've got statics, this makes 
your API not thread-safe.


 I am not an expert in techniques for thread-safety,


No-one is, but I've a fair amount of knowledge on the subject. ;)


 isn't it an enormous amount of work to write and test code for 
 thread-safety?


Yes, and no. If you go for the definition as given above, then it's 
pretty easy.


 Or would spin mutexes automatically solve that problem?


They would solve the problem I identified. I assume that YARD does not 
have any deeper threading issues, but of course I've not looked deeply.


 My personal preference is to ignore multi-threaded use scenarios.


Hallelujah! Except that one cannot do so when writing libraries ...

Cheers


-- 
Matthew Wilson

Author: "Imperfect C++", Addison-Wesley, 2004
    (http://www.imperfectcplusplus.com)
Contributing editor, C/C++ Users Journal
    (http://www.synesis.com.au/articles.html#columns)
STLSoft moderator
    (http://www.stlsoft.org)

"If I'm curt with you it's because time is a factor. I think fast, I 
talk fast, and I need you guys to act fast" -- Mr Wolf

-------------------------------------------------------------------------------
Mar 03 2005
parent reply "christopher diggins" <cdiggins videotron.ca> writes:
YARD relies on explicit-static-member-function-template-specializations 
which GCC 3.3.3 does not allow! This is crucial for writing semantic 
actions.

consider:

 struct MyParser
    // common practice is to inherit from BasicParser
    // but you can write your own parsers
    : BasicParser<StringParserInput>
  {
    // ctor
    MyParser() { }

    // this is absolutely neccessary. We need
    // it for the specializations to work
    // this provides a default action for matching
    template<typename Rules_T> static bool
    Match(StringParserInput& in) {
      return Rules_T::template Accept<MyParser>(in);
    }

    // this is a custom matcher for MyGrammar::Word
    // NON-STANDARD?!
    template<> static bool
    Match<MyGrammar::Word>(StringParserInput& in) {
      // we ask the pattern whether it matches
      if (MyGrammar::Word::template Accept<MyParser>(in))
      {
        // assuming success we output the a new number for the token
        // (this is just for demonstration)
        cout << count++;
        return true;
      }
      else
      {
        return false;
      }
    }
  };

Visual C++ 7.1 lets this pass without a whimper even with the Microsoft 
extensions disabled. This functionality is the whole crux of YARD.

Is this planned for the next version of C++? Any suggestions for 
work-arounds? Do other compilers allow this?

- C
Mar 04 2005
next sibling parent "christopher diggins" <cdiggins videotron.ca> writes:
I have found the following discussion which points out that gcc allows
partial template specialization within structs but not full template
specializations.

http://lists.debian.org/debian-gcc/2004/09/msg00015.html

- D
Mar 04 2005
prev sibling parent "christopher diggins" <cdiggins videotron.ca> writes:
I solved my own problem.

I had to move the body of the Match out of the declaration. This is not very
pretty though (comments stripped):

  struct MyParser
    : BasicParser<StringParserInput>
  {
    MyParser() { }
    template<typename Rules_T> static bool
    Match(StringParserInput& in) {
      return Rules_T::template Accept<MyParser>(in);
    }
  };

  template<> bool MyParser::Match<MyGrammar::Word>(StringParserInput& in) {
    if (MyGrammar::Word::Accept<MyParser>(in)) {
      cout << count++;
      return true;
    }
    else {
      return false;
    }
  }


Christopher Diggins
Object Oriented Template Library (OOTL)
http://www.ootl.org
Mar 04 2005
prev sibling parent "christopher diggins" <cdiggins videotron.ca> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
news:d05r59$1dfo$1 digitaldaemon.com...

 For grins, I just ran it on a suite of compilers.

 It's got a lot of problems, including:

    - uses non-standard std::exception::exception(char const *) ctor
    - uses undiscriminated #pragma once
    - plenty of missing typename type qualifiers
    - etc. etc.



I just released a new version which is much happier on GCC 3.3.3

But I just realized that I still have the non-standard exception ctor 
problem.

The download is at http://sourceforge.net/projects/yard-parser/

There are now known bugs in the examples which aren't tested. So I need to 
significantly extend the test coverage. I also need to update the 
documentation, provide more examples, and write a full non-validating XML 
parser. So we still have a ways to go yet.

But progress is being made, thanks for your help!

-- 
Christopher Diggins
Object Oriented Template Library (OOTL)
http://www.ootl.org
Mar 04 2005