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

;)

"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

-------------------------------------------------------------------------------

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

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

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

"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