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

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!

"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

"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

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
> 

"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

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

"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

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
> 

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