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.

 -- 
 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

 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


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

 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 # error YARD is only compatible with Boost or STLSoft. You must define one of YARD_USE_BOOST or YARD_USE_STLSOFT #endif #ifdef YARD_USE_STLSOFT # include <stlsoft.h> # include <stlsoft_iterator.h> # . . . # if defined(__STLSOFT_COMPILER_IS_COMO # define YARD_COMPILER_IS_COMO # elif defined ... 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