www.digitalmars.com         C & C++   DMDScript  

c++.stlsoft - New release of the YARD parsing library, version 0.4

reply "christopher diggins" <cdiggins videotron.ca> writes:
I have just made a new release of YARD 
http://www.sf.net/projects/yard-parser . I have also rewritten the 
documentation at http://www.ootl.org/yard/ anbd it contains more examples. 
Matthew's book is mentioned in the documenation and is now part of the 
regular ad rotation throughout OOTL.org. If you refresh any page enough 
times, it is sure to show up eventually.

- I decided to shift right the version numbers to more accurately reflect 
the fact that the library is not mature.
- There is still no makefile with the release, but there is now a 
readme.txt, and a single cpp file containing all of the tests.
- I have removed the dependencies on OOTL.
- I am pretty much decided that I won't be supporting multi-threading at 
least not unless there is significant demand for it, I hope this doesn't 
kill its chances for being accepted into STLSoft in the future.
- There is no large file input format built-in yet, but I am still planning 
on releasing something in the future. If you have any spare time Zz, and the 
energy, you could always volunteer to provide me with an efficient 
implementation of forward iterators for files? Nudge, nudge.
- there are more and more tests

Some other stuff, but I am too fried to go on. Poke around and let me know 
what you think, thanks!

-- 
Christopher Diggins
Object Oriented Template Library (OOTL)
http://www.ootl.org 
Mar 18 2005
next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
Can you email me the zip? I want to play.

Please tell me you've got an example to play with ... :-)

Cheers

Matthew

P.S. Thanks for the advertising. We've moved back up to #21 in the last couple
of weeks.

P.P.S. Specific comments follow:

"christopher diggins" <cdiggins videotron.ca> wrote in message
news:d1g5pc$2s0g$1 digitaldaemon.com...
I have just made a new release of YARD http://www.sf.net/projects/yard-parser .
I have also rewritten the documentation 
at http://www.ootl.org/yard/ anbd it contains more examples. Matthew's book is
mentioned in the documenation and is now 
part of the regular ad rotation throughout OOTL.org. If you refresh any page
enough times, it is sure to show up 
eventually.

Can't download it, as there appears to be nothing available on SF. Did you correctly post the files?
 - I decided to shift right the version numbers to more accurately reflect the
fact that the library is not mature.

Wise choice
 - There is still no makefile with the release, but there is now a readme.txt,
and a single cpp file containing all of 
 the tests.

Ok.
 - I have removed the dependencies on OOTL.

Cool. Just got to add STLSoft dependencies now. ;)
 - I am pretty much decided that I won't be supporting multi-threading at least
not unless there is significant demand 
 for it, I hope this doesn't kill its chances for being accepted into STLSoft
in the future.

Doesn't mean anything at this stage.
 - There is no large file input format built-in yet, but I am still planning on
releasing something in the future. If 
 you have any spare time Zz, and the energy, you could always volunteer to
provide me with an efficient implementation 
 of forward iterators for files? Nudge, nudge.

I still maintain that there is no theoretically sound + efficient forward iterators for files, at least not one based on sequential file reading APIs. I will be doing a memory-mapped file at some point, hopefully before 1.8.3 proper is released. If that helps ... ;)
 - there are more and more tests

 Some other stuff, but I am too fried to go on. Poke around and let me know
what you think, thanks!

Will do, as soon as I can look at it. Since you've got it down to a single source file, I was planning to run it through Arturius, and thereby compile it against ~20 Win32 compilers at once. That'd do some good portability!
Mar 19 2005
parent reply "christopher diggins" <cdiggins videotron.ca> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote in message 
news:d1gtsp$mc1$1 digitaldaemon.com...
 Can you email me the zip? I want to play.

Sure.
 Please tell me you've got an example to play with ... :-)

There are dozens of tests in the file: http://www.ootl.org/yard/tests/yard_test.hpp.htm which serve as good trivial examples. There is a non-trivial C++ to HTML example at: http://www.ootl.org/yard/examples/yard_example_cpp_to_html.hpp.htm But please tell me you will read the new documentation first.
 Cheers

 Matthew

 P.S. Thanks for the advertising. We've moved back up to #21 in the last 
 couple of weeks.

You are welcome.
 Can't download it, as there appears to be nothing available on SF. Did you 
 correctly post the files?

I guess not. I have reuploaded http://sourceforge.net/project/showfiles.php?group_id=126822
 - There is no large file input format built-in yet, but I am still 
 planning on releasing something in the future. If you have any spare time 
 Zz, and the energy, you could always volunteer to provide me with an 
 efficient implementation of forward iterators for files? Nudge, nudge.

I still maintain that there is no theoretically sound + efficient forward iterators for files, at least not one based on sequential file reading APIs.

I'll post one soon, and you can take it apart, okay?
 I will be doing a memory-mapped file at some point, hopefully before 1.8.3 
 proper is released. If that helps ... ;)

It is not the ideal solution. I want to avoid platform specific compilation in the library as much as possible.
 Since you've got it down to a single source file, I was planning to run it 
 through Arturius, and thereby compile it against ~20 Win32 compilers at 
 once. That'd do some good portability!

Wow! That would be great. Thanks, - Christopher
Mar 19 2005
parent reply "christopher diggins" <cdiggins videotron.ca> writes:
"christopher diggins" <cdiggins videotron.ca> wrote in message 
news:d1hhb8$1a77$1 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 Please tell me you've got an example to play with ... :-)

There are dozens of tests in the file: http://www.ootl.org/yard/tests/yard_test.hpp.htm which serve as good trivial examples. There is a non-trivial C++ to HTML example at: http://www.ootl.org/yard/examples/yard_example_cpp_to_html.hpp.htm But please tell me you will read the new documentation first.

I meant this light-hearted, upon rereading it seems disrespectful. Sorry :)
 I still maintain that there is no theoretically sound + efficient forward 
 iterators for files, at least not one based on sequential file reading 
 APIs.

I'll post one soon, and you can take it apart, okay?

I have just completed a first version of a file-reader class based upon the fopen, fseek, ftell and fread routines (are those considered a sequential file reading API?) which uses a vector of dynamically allocated reference counted buffers. The code is available at http://www.ootl.org/ootl/ootl_file_reader.hpp.htm . I tested it on Visual C++ 7.1 and GCC 3.4 using the test at http://www.ootl.org/ootl/tests/ootl_test_file_reader.hpp.htm . In the worst case there is one buffer allocated for each iterator but in common usage iterators often share buffers (at least during parsing). The performance seems acceptable, but I haven't profiled it and compared with other file access routines. Obviously I can also not say how this compares to a memory mapping approach. I believe the code is theoretically sound, but I am not completely certain. IIRC the fopen(..., "rb") routine should block file writing while my file reader class is active, or else it is just wishful thinking. Note that the only iterators provided are const_iterators. Any comments are appreciated. -D
Mar 19 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"christopher diggins" <cdiggins videotron.ca> wrote in message 
news:d1ia1g$24b3$1 digitaldaemon.com...
 "christopher diggins" <cdiggins videotron.ca> wrote in message 
 news:d1hhb8$1a77$1 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 Please tell me you've got an example to play with ... :-)

There are dozens of tests in the file: http://www.ootl.org/yard/tests/yard_test.hpp.htm which serve as good trivial examples. There is a non-trivial C++ to HTML example at: http://www.ootl.org/yard/examples/yard_example_cpp_to_html.hpp.htm But please tell me you will read the new documentation first.

I meant this light-hearted, upon rereading it seems disrespectful. Sorry :)

No worries. There was no offense taken. FYI: I have an _almost_ Bright-like thick skin. (Note the 'almost'. <g>)
 I still maintain that there is no theoretically sound + efficient forward 
 iterators for files, at least not one based on sequential file reading APIs.

I'll post one soon, and you can take it apart, okay?

I have just completed a first version of a file-reader class based upon the fopen, fseek, ftell and fread routines (are those considered a sequential file reading API?) which uses a vector of dynamically allocated reference counted buffers. The code is available at http://www.ootl.org/ootl/ootl_file_reader.hpp.htm . I tested it on Visual C++ 7.1 and GCC 3.4 using the test at http://www.ootl.org/ootl/tests/ootl_test_file_reader.hpp.htm . In the worst case there is one buffer allocated for each iterator but in common usage iterators often share buffers (at least during parsing). The performance seems acceptable, but I haven't profiled it and compared with other file access routines. Obviously I can also not say how this compares to a memory mapping approach. I believe the code is theoretically sound, but I am not completely certain. IIRC the fopen(..., "rb") routine should block file writing while my file reader class is active, or else it is just wishful thinking. Note that the only iterators provided are const_iterators. Any comments are appreciated.

I'll dig into this. Remind me in a day or so if I've not responded. Naturally, as you say, an opened file, in non-shared mode, takes away the 'theoretical' uncertainty I was gassing on about. But "rb" doesn't cut it. For one, "b" is a Microsoft / Windows extension. (On UNIX, there is no \r\n, so no need for \n <=> \r\n translation.) Also - and I may need to check my facts on this - "r", in and of itself, does not prevent another process sharing for write. But I'd have to check this again, and the interrelationship between fopen() and open() (and open()'s pmode argument). But all of this is conjecture, since it's been a long time since I've had to be concerned about sharing wrt stdio (or even io), as I tend to use OS-specific file system calls when I care about it. Finally, although I've only just scanned it, I'm not seeing either any dup or multiple fopen calls, which makes me wonder how you support forward iterators. If you're seeking the same file-handle back and forth on the demands of different (concurrent) iterator instances, then there's certainly potential there for poor performance. But however well designed/implemented it is, it is very unlikely that it'll approach the performance of memory-mapped file reading. The question will be whether the gap is significant c/w other latencies within YARD. I'll try and get a mo to play with it, and let you know. Cheers Matthew
Mar 19 2005
next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
Is written and tested. It's a read-only adaptation of a more
flexible (i.e. does read, write read/write) Synesis class that
I've never been terribly happy with (hence it's not being
included in STLSoft thus far.)

Because it's read-only, it's very easy to keep it really nice and
simple.

I'm going to do the UNIXSTL version now, and then you'll be able
to use string_view. Peachy, or what?

:-)

Matthew
Mar 19 2005
next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
I've done the UNIXSTL one. It's structurally compliant with the WinSTL one, so
you can do simple platform 
discrimination, a la.

    #if defined(unix)

    # include <unixstl/memory_mapped_file.hpp>
    namespace platform_stl
    {
        typedef ::unixstl::memory_mapped_file    memory_mapped_file;
    }

    #elif defined(WIN32)

    # include <winstl/memory_mapped_file.hpp>
    namespace platform_stl
    {
        typedef ::winstl::memory_mapped_file    memory_mapped_file;
    }

    #else
    # error Platform not recognised
    #endif /* platform */

There are lots of these structurally compliant components between the two
OS-specific subprojects, and I'm starting to 
think about doing a PlatformSTL sub-project, to encapsulate them. (I have *no*
intention of adding any 
platform-dependent code to the STLSoft main project, ever).

Does anyone (else) have any opinions on this? I use the namespace aliasing
technique - documented in 
http://www.cuj.com/documents/s=9152/cujexp0404wilson/ - quite a bit in recls,
so it may be time to start a real project 
for it.

Anyway, I'm waffling. The memory_mapped_file classes will be in STLSoft 1.8.3
beta 4 very shortly.

Cheers

Matthew


"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:d1j3ab$2qie$1 digitaldaemon.com...
 Is written and tested. It's a read-only adaptation of a more
 flexible (i.e. does read, write read/write) Synesis class that
 I've never been terribly happy with (hence it's not being
 included in STLSoft thus far.)

 Because it's read-only, it's very easy to keep it really nice and
 simple.

 I'm going to do the UNIXSTL version now, and then you'll be able
 to use string_view. Peachy, or what?

 :-)

 Matthew

 

Mar 19 2005
next sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:d1j4g9$2rgf$1 digitaldaemon.com...
 I've done the UNIXSTL one. It's structurally compliant with the WinSTL one, so
you can do simple platform 
 discrimination, a la.

    #if defined(unix)

    # include <unixstl/memory_mapped_file.hpp>
    namespace platform_stl
    {
        typedef ::unixstl::memory_mapped_file    memory_mapped_file;
    }

    #elif defined(WIN32)

    # include <winstl/memory_mapped_file.hpp>
    namespace platform_stl
    {
        typedef ::winstl::memory_mapped_file    memory_mapped_file;
    }

    #else
    # error Platform not recognised
    #endif /* platform */

 There are lots of these structurally compliant components between the two
OS-specific subprojects, and I'm starting to 
 think about doing a PlatformSTL sub-project, to encapsulate them. (I have *no*
intention of adding any 
 platform-dependent code to the STLSoft main project, ever).

 Does anyone (else) have any opinions on this? I use the namespace aliasing
technique - documented in 
 http://www.cuj.com/documents/s=9152/cujexp0404wilson/ - quite a bit in recls,
so it may be time to start a real 
 project for it.

 Anyway, I'm waffling. The memory_mapped_file classes will be in STLSoft 1.8.3
beta 4 very shortly.

I've done the PlatformSTL sub-project. Now one simple #includes the requisite platformstl header, e.g. #include <platformstl/memory_mapped_file.hpp> and use the type ::platformstl::memory_mapped_file. I'll naturally be making all structurally compliant components between UNIXSTL and WinSTL available in this form, and it'll be included in 1.8.3 beta 4 Cheers Matthew
Mar 19 2005
prev sibling parent "christopher diggins" <cdiggins videotron.ca> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote in message 
news:d1j4g9$2rgf$1 digitaldaemon.com...
 I've done the UNIXSTL one. It's structurally compliant with the WinSTL 
 one, so you can do simple platform discrimination, a la.

    #if defined(unix)

    # include <unixstl/memory_mapped_file.hpp>
    namespace platform_stl
    {
        typedef ::unixstl::memory_mapped_file    memory_mapped_file;
    }

    #elif defined(WIN32)

    # include <winstl/memory_mapped_file.hpp>
    namespace platform_stl
    {
        typedef ::winstl::memory_mapped_file    memory_mapped_file;
    }

    #else
    # error Platform not recognised
    #endif /* platform */

 There are lots of these structurally compliant components between the two 
 OS-specific subprojects, and I'm starting to think about doing a 
 PlatformSTL sub-project, to encapsulate them. (I have *no* intention of 
 adding any platform-dependent code to the STLSoft main project, ever).

Which brings up a good point. If the YARD includes the memory_mapped_file routines as part of the main library then it can't be put in the STLSoft main project. I think the solutation to this is that the file reading code should be placed outside of the main YARD project. The generic design of YARD input makes this an appropriate design choice I think.
 Does anyone (else) have any opinions on this? I use the namespace 

 http://www.cuj.com/documents/s=9152/cujexp0404wilson/ - quite a bit in 
 recls, so it may be time to start a real project for it.

This appears to be the poster child for namespace aliasing, and it would save a lot of code.
 Anyway, I'm waffling. The memory_mapped_file classes will be in STLSoft 
 1.8.3 beta 4 very shortly.

I look forward to it, thanks for responding so quickly. -D
Mar 20 2005
prev sibling next sibling parent "christopher diggins" <cdiggins videotron.ca> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote in message 
news:d1j3ab$2qie$1 digitaldaemon.com...
 Is written and tested. It's a read-only adaptation of a more
 flexible (i.e. does read, write read/write) Synesis class that
 I've never been terribly happy with (hence it's not being
 included in STLSoft thus far.)

 Because it's read-only, it's very easy to keep it really nice and
 simple.

 I'm going to do the UNIXSTL version now, and then you'll be able
 to use string_view. Peachy, or what?

 :-)

Very peachy! -- Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org
Mar 20 2005
prev sibling parent "Zz" <Zz Zz.com> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote in message 
news:d1j3ab$2qie$1 digitaldaemon.com...
 Is written and tested. It's a read-only adaptation of a more
 flexible (i.e. does read, write read/write) Synesis class that
 I've never been terribly happy with (hence it's not being
 included in STLSoft thus far.)

 Because it's read-only, it's very easy to keep it really nice and
 simple.

 I'm going to do the UNIXSTL version now, and then you'll be able
 to use string_view. Peachy, or what?

is just over 2GB, the largest XML file I have is about 4.5 GB, Postscript files could run over 8GB. On the other hand memory mapped files are very flexible, fast and preferable when you have to access the file sequentially. As I mentioned our method is very close to the one LCC compiler and RE2C use. this paper covers the method used in LCC http://www.cs.princeton.edu/software/lcc/doc/06.pdf Zz.
Mar 20 2005
prev sibling next sibling parent "christopher diggins" <cdiggins videotron.ca> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
news:d1ik3p$2dgp$1 digitaldaemon.com...
 I'll dig into this. Remind me in a day or so if I've not responded.

 Naturally, as you say, an opened file, in non-shared mode, takes away the 
 'theoretical' uncertainty I was gassing on about. But "rb" doesn't cut it. 
 For one, "b" is a Microsoft / Windows extension. (On UNIX, there is no 
 \r\n, so no need for \n <=> \r\n translation.)

Thanks for pointing that out. There are a lot of facts like these that I simply don'ty know, because I have only ever done windows development my whole career.
 Also - and I may need to check my facts on this - "r", in and of itself, 
 does not prevent another process sharing for write.

Any operating system that allowed files opened with fopen to be written to would make that API unsound. It would seem ludicrous for them to not have blocking read modes.
 But I'd have to check this again, and the interrelationship between 
 fopen() and open() (and open()'s pmode argument).

I don't know the function open(). Isn't it a unix thing?
 But all of this is conjecture, since it's been a long time since I've had 
 to be concerned about sharing wrt stdio (or even io), as I tend to use 
 OS-specific file system calls when I care about it.

 Finally, although I've only just scanned it, I'm not seeing either any dup 
 or multiple fopen calls, which makes me wonder how you support forward 
 iterators. If you're seeking the same file-handle back and forth on the 
 demands of different (concurrent) iterator instances, then there's 
 certainly potential there for poor performance.

The iterators access memory through a buffer. Fseek/fread is only used if an iterator requests memory from a currently unallocated buffer. Buffers are freed automatically when an iterator no longer references it.
 But however well designed/implemented it is, it is very unlikely that 
 it'll approach the performance of memory-mapped file reading. The question 
 will be whether the gap is significant c/w other latencies within YARD.
 I'll try and get a mo to play with it, and let you know.

Thank you. -- Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org
Mar 20 2005
prev sibling parent reply "Zz" <Zz Zz.com> writes:
.. snip ..
 Naturally, as you say, an opened file, in non-shared mode, takes away the 
 'theoretical' uncertainty I was gassing on about. But "rb" doesn't cut it. 
 For one, "b" is a Microsoft / Windows extension. (On UNIX, there is no 
 \r\n, so no need for \n <=> \r\n translation.)

and don't forget \r for the mac. \r\n = Windows \n = Unix \r = Mac. While parsing we usually open files in binary and keep track of line endinds on our own. Zz
Mar 20 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Zz" <Zz Zz.com> wrote in message news:d1kopq$1b6c$1 digitaldaemon.com...
 .. snip ..
 Naturally, as you say, an opened file, in non-shared mode, takes away the 
 'theoretical' uncertainty I was gassing on about. But "rb" doesn't cut it. For 
 one, "b" is a Microsoft / Windows extension. (On UNIX, there is no \r\n, so no 
 need for \n <=> \r\n translation.)

and don't forget \r for the mac. \r\n = Windows \n = Unix \r = Mac. While parsing we usually open files in binary and keep track of line endinds on our own.

Indeed! I tend to, out of instinct, distrust stdio translation, and tend to cater for all possible permutations of line-ending sequences. Of course, one must always write out the appropriate thing on the appropriate platform, but reading 'intelligently' has saved me much hassle in the past.
Mar 20 2005
parent reply "Zz" <Zz Zz.com> writes:
..snip..
 \r\n = Windows
 \n   = Unix
 \r    = Mac.

 While parsing we usually open files in binary and keep track of line 
 endinds on our own.

Indeed! I tend to, out of instinct, distrust stdio translation, and tend to cater for all possible permutations of line-ending sequences. Of course, one must always write out the appropriate thing on the appropriate platform, but reading 'intelligently' has saved me much hassle in the past.

IBM OS/390 uses [NEL] ASCII 133 for line endings. Zz
Mar 21 2005
parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"Zz" <Zz Zz.com> wrote in message news:d1njpj$vkj$1 digitaldaemon.com...
 ..snip..
 \r\n = Windows
 \n   = Unix
 \r    = Mac.

 While parsing we usually open files in binary and keep track of line endinds
on our own.

Indeed! I tend to, out of instinct, distrust stdio translation, and tend to cater for all possible permutations of line-ending sequences. Of course, one must always write out the appropriate thing on the appropriate platform, but reading 'intelligently' has saved me much hassle in the past.

IBM OS/390 uses [NEL] ASCII 133 for line endings.

Ouch! I originally designed string_tokeniser to work with 'intelligent' delimiters, but never really took it very far; char and string has always sufficed thus far. I reckon I might try and take a look at a general delimiter type sometime that'd enable line-ising of a file. Imagine passing in a file name, and receiving an object that holds the mem-map, and provides access to string slices (i.e. vector<basic_string_view<char>>) for all the lines. Now that'd be both fast and convenient! :-) Cheers Matthew
Mar 21 2005
prev sibling next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
One thing: it doesn't unzip into the structure required by the include
statements 
in the source!

That's quite inhibiting ...

"christopher diggins" <cdiggins videotron.ca> wrote in message 
news:d1g5pc$2s0g$1 digitaldaemon.com...
I have just made a new release of YARD http://www.sf.net/projects/yard-parser .
I 
have also rewritten the documentation at http://www.ootl.org/yard/ anbd it 
contains more examples. Matthew's book is mentioned in the documenation and is 
now part of the regular ad rotation throughout OOTL.org. If you refresh any
page 
enough times, it is sure to show up eventually.

 - I decided to shift right the version numbers to more accurately reflect the 
 fact that the library is not mature.
 - There is still no makefile with the release, but there is now a readme.txt, 
 and a single cpp file containing all of the tests.
 - I have removed the dependencies on OOTL.
 - I am pretty much decided that I won't be supporting multi-threading at least 
 not unless there is significant demand for it, I hope this doesn't kill its 
 chances for being accepted into STLSoft in the future.
 - There is no large file input format built-in yet, but I am still planning on 
 releasing something in the future. If you have any spare time Zz, and the 
 energy, you could always volunteer to provide me with an efficient 
 implementation of forward iterators for files? Nudge, nudge.
 - there are more and more tests

 Some other stuff, but I am too fried to go on. Poke around and let me know
what 
 you think, thanks!

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

Mar 19 2005
parent "christopher diggins" <cdiggins videotron.ca> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
news:d1iaov$24ul$1 digitaldaemon.com...
 One thing: it doesn't unzip into the structure required by the include 
 statements in the source!

 That's quite inhibiting ...

Thank you for pointing that out. I just updated the package at http://sourceforge.net/project/showfiles.php?group_id=126822 which fixes this problem. -- Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org
Mar 19 2005
prev sibling next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
Here's an initial set of results from Arturius. Despite how it looks, it's 
actually pretty encouraging.

I've got to go out now, but will have a deeper dig in a couple of hours. Some
of 
the things, like -EHsc missing, will be instantly resolved (by my specifying
the 
appropriate Arturius cmd-line params.)

Back soon ...

"christopher diggins" <cdiggins videotron.ca> wrote in message 
news:d1g5pc$2s0g$1 digitaldaemon.com...
I have just made a new release of YARD
 http://www.sf.net/projects/yard-parser . I have also rewritten the
 documentation at http://www.ootl.org/yard/ anbd it contains more examples.
 Matthew's book is mentioned in the documenation and is now part of the
 regular ad rotation throughout OOTL.org. If you refresh any page enough
 times, it is sure to show up eventually.

 - I decided to shift right the version numbers to more accurately reflect
 the fact that the library is not mature.
 - There is still no makefile with the release, but there is now a
 readme.txt, and a single cpp file containing all of the tests.
 - I have removed the dependencies on OOTL.
 - I am pretty much decided that I won't be supporting multi-threading at
 least not unless there is significant demand for it, I hope this doesn't
 kill its chances for being accepted into STLSoft in the future.
 - There is no large file input format built-in yet, but I am still planning
 on releasing something in the future. If you have any spare time Zz, and the
 energy, you could always volunteer to provide me with an efficient
 implementation of forward iterators for files? Nudge, nudge.
 - there are more and more tests

 Some other stuff, but I am too fried to go on. Poke around and let me know
 what you think, thanks!

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

 

Mar 19 2005
parent "christopher diggins" <cdiggins videotron.ca> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
news:d1ij1b$2ckn$1 digitaldaemon.com...
 Here's an initial set of results from Arturius. Despite how it looks, it's 
 actually pretty encouraging.

 I've got to go out now, but will have a deeper dig in a couple of hours. 
 Some of the things, like -EHsc missing, will be instantly resolved (by my 
 specifying the appropriate Arturius cmd-line params.)

You should have a special congratualatory message replete with ascii art, when something does in fact compile correctly on a given compiler. Emphasize the positive ;-) Thanks for giving it a run on Arturius. -- Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org
Mar 20 2005
prev sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
It's generally accepted to be a really bad principle to use using directives 
within headers. I also swim somewhat against the stream in suggesting that it's
a 
bad idea to use them in implementation files, but that's less universally 
accepted.

Your use of

  namespace yard
  {
    using namespace std;
  }

in yard.hpp is causing problems for me in playing around with YARD from within 
Visual Studio '98 + Intel 8.0 + STLport. That's obviously one case in which the 
bad side of using directives crops up. I don't doubt that, if you leave it in, 
we'll encounter cause more.

Also, yard.hpp includes a *lot* of things - pretty much the fattest headers in
the 
standard library. Are they *all* necessary for *all* parts of the library?

(Note: I realise that at the moment you're wisely focusing on functionality,
and 
will trim later. But sometimes it can be really hard to un-engineer things with 
such wide ramifications.)

Cheers

Matthew

"christopher diggins" <cdiggins videotron.ca> wrote in message 
news:d1g5pc$2s0g$1 digitaldaemon.com...
I have just made a new release of YARD http://www.sf.net/projects/yard-parser .
I 
have also rewritten the documentation at http://www.ootl.org/yard/ anbd it 
contains more examples. Matthew's book is mentioned in the documenation and is 
now part of the regular ad rotation throughout OOTL.org. If you refresh any
page 
enough times, it is sure to show up eventually.

 - I decided to shift right the version numbers to more accurately reflect the 
 fact that the library is not mature.
 - There is still no makefile with the release, but there is now a readme.txt, 
 and a single cpp file containing all of the tests.
 - I have removed the dependencies on OOTL.
 - I am pretty much decided that I won't be supporting multi-threading at least 
 not unless there is significant demand for it, I hope this doesn't kill its 
 chances for being accepted into STLSoft in the future.
 - There is no large file input format built-in yet, but I am still planning on 
 releasing something in the future. If you have any spare time Zz, and the 
 energy, you could always volunteer to provide me with an efficient 
 implementation of forward iterators for files? Nudge, nudge.
 - there are more and more tests

 Some other stuff, but I am too fried to go on. Poke around and let me know
what 
 you think, thanks!

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

Mar 19 2005
parent reply "christopher diggins" <cdiggins videotron.ca> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
news:d1iloo$2f6q$1 digitaldaemon.com...
 It's generally accepted to be a really bad principle to use using 
 directives within headers. I also swim somewhat against the stream in 
 suggesting that it's a bad idea to use them in implementation files, but 
 that's less universally accepted.

Could you quickly summarize your position here?
 Your use of

  namespace yard
  {
    using namespace std;
  }

 in yard.hpp is causing problems for me in playing around with YARD from 
 within Visual Studio '98 + Intel 8.0 + STLport. That's obviously one case 
 in which the bad side of using directives crops up. I don't doubt that, if 
 you leave it in, we'll encounter cause more.

Sweet lord, give me strength. Someday Heron will be ready, and all of this will be a thing of the past.
 Also, yard.hpp includes a *lot* of things - pretty much the fattest 
 headers in the standard library. Are they *all* necessary for *all* parts 
 of the library?

I really doubt they are. Header inclusion is never something I paid any detail to.
 (Note: I realise that at the moment you're wisely focusing on 
 functionality, and will trim later. But sometimes it can be really hard to 
 un-engineer things with such wide ramifications.)

Good point, I will try to address the problem sometime soon. -- Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org
Mar 20 2005
parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"christopher diggins" <cdiggins videotron.ca> wrote in message
news:d1k2uo$lvt$1 digitaldaemon.com...
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d1iloo$2f6q$1 digitaldaemon.com...
 It's generally accepted to be a really bad principle to use using directives
within headers. I also swim somewhat 
 against the stream in suggesting that it's a bad idea to use them in
implementation files, but that's less 
 universally accepted.

Could you quickly summarize your position here?

Sure: my position is that I *never* use using directives in header files, and I 'never' use them in implementation files. (The first never is absolute, the latter almost absolute.) To be more specific: Neither using directives or using declarations should be used in header files at global scope. Using directives should not be used in header files at namespace scope. I personally avoid using directives in implementation files. There are small exceptions to these, in terms of glueing things together and workarounds and such, but they are excellent general principles that I'd recommend to anyone.
 Your use of

  namespace yard
  {
    using namespace std;
  }

 in yard.hpp is causing problems for me in playing around with YARD from within
Visual Studio '98 + Intel 8.0 + 
 STLport. That's obviously one case in which the bad side of using directives
crops up. I don't doubt that, if you 
 leave it in, we'll encounter cause more.

Sweet lord, give me strength. Someday Heron will be ready, and all of this will be a thing of the past.

We can but hope. :-)
 Also, yard.hpp includes a *lot* of things - pretty much the fattest headers in
the standard library. Are they *all* 
 necessary for *all* parts of the library?

I really doubt they are. Header inclusion is never something I paid any detail to.

It's fair enough at this point of the game. But it's something you'd want to look at before the first cut ...
 Good point, I will try to address the problem sometime soon.

... cool.
Mar 21 2005