• christopher diggins (25/25) Mar 18 2005 I have just made a new release of YARD
• Matthew (18/33) Mar 19 2005 Can you email me the zip? I want to play.
• christopher diggins (18/38) Mar 19 2005 Sure.
• christopher diggins (21/33) Mar 19 2005 I meant this light-hearted, upon rereading it seems disrespectful. Sorry...
• Matthew (25/60) Mar 19 2005 No worries. There was no offense taken. FYI: I have an _almost_ Bright-l...
• Matthew (10/10) Mar 19 2005 Is written and tested. It's a read-only adaptation of a more
• Matthew (27/38) Mar 19 2005 I've done the UNIXSTL one. It's structurally compliant with the WinSTL o...
• Matthew (8/32) Mar 19 2005 I've done the PlatformSTL sub-project. Now one simple #includes the requ...
• christopher diggins (12/38) Mar 20 2005 Which brings up a good point. If the YARD includes the memory_mapped_fil...
• christopher diggins (7/16) Mar 20 2005 Very peachy!
• Zz (12/20) Mar 20 2005 I really like memory mapped files but under Windows I think the maximum ...
• christopher diggins (17/38) Mar 20 2005 Thanks for pointing that out. There are a lot of facts like these that I...
• Zz (8/12) Mar 20 2005 and don't forget \r for the mac.
• Matthew (6/17) Mar 20 2005 Indeed!
• Zz (4/15) Mar 21 2005 I forgot on that really took me by surprise the first time.
• Matthew (10/24) Mar 21 2005 Ouch!
• Matthew (5/30) Mar 19 2005 One thing: it doesn't unzip into the structure required by the include s...
• christopher diggins (9/12) Mar 19 2005 Thank you for pointing that out. I just updated the package at
• Matthew (757/783) Mar 19 2005 Here's an initial set of results from Arturius. Despite how it looks, it...
• christopher diggins (10/15) Mar 20 2005 You should have a special congratualatory message replete with ascii art...
• Matthew (22/47) Mar 19 2005 It's generally accepted to be a really bad principle to use using direct...
• christopher diggins (12/31) Mar 20 2005 Could you quickly summarize your position here?
• Matthew (12/32) Mar 21 2005 Sure: my position is that I *never* use using directives in header files...

"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 

"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


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!

"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


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

"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

"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

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


    namespace platform_stl
    {
        typedef ::unixstl::memory_mapped_file    memory_mapped_file;
    }

    #elif defined(WIN32)


    namespace platform_stl
    {
        typedef ::winstl::memory_mapped_file    memory_mapped_file;
    }

    #else

    #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

 

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


    namespace platform_stl
    {
        typedef ::unixstl::memory_mapped_file    memory_mapped_file;
    }

    #elif defined(WIN32)


    namespace platform_stl
    {
        typedef ::winstl::memory_mapped_file    memory_mapped_file;
    }

    #else

    #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

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


    namespace platform_stl
    {
        typedef ::unixstl::memory_mapped_file    memory_mapped_file;
    }

    #elif defined(WIN32)


    namespace platform_stl
    {
        typedef ::winstl::memory_mapped_file    memory_mapped_file;
    }

    #else

    #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 

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.


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 

"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 

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

I really like memory mapped files but under Windows I think the maximum size 
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. 

"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 

"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 

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

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

I forgot on that really took me by surprise the first time.
IBM OS/390 uses [NEL]  ASCII 133 for line endings.

Zz 

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

 I forgot on that really took me by surprise the first time.
 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

"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
 

"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 

"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

 


begin 666 arturius.results

M.B!%<G)O<B!%,C$W." Z(%9)4D1%1B!N86UE(&-O;F9L:6-T(&9O<B G;6%I
M;BAI;G0L8VAA<B J("HI)PT*;6%I;BYC<' H.2DZ($5R<F]R($4R,3(P(#H 
M0V%N;F]T(&-A;&P )VUA:6XG(&9R;VT =VET:&EN('1H92!P<F]G<F%M(&EN
M(&9U;F-T:6]N(&UA:6XH:6YT+&-H87( *B J*0T*5&]O;#H 8W<O-PT*(R,C
M(&UW8V,N97AE($-O;7!I;&5R. T*(R  ("!&:6QE.B!M86EN+F-P< T*(R M

M("  17)R;W(Z("  ("  ("  ("  7 T*(R  ('5N9&5F:6YE9"!I9&5N=&EF






M;5]F:6QT97)=("XN7"XN7'EA<F0O>6%R9%]I;G!U="YH<' H-C<I(#H 17)R
M;W(Z('5S:6YG+61E8VQA<F%T:6]N(&-A;FYO="!N86UE('1E;7!L871E+6ED
M("=087)S97));G!U="<-"EM!<G1U<FEU<SID;5]F:6QT97)=("XN7"XN7'EA
M<F0O>6%R9%]I;G!U="YH<' H-C I(#H 17)R;W(Z('5S:6YG+61E8VQA<F%T
M:6]N(&-A;FYO="!N86UE('1E;7!L871E+6ED("=087)S97));G!U="<-"EM!
M<G1U<FEU<SID;5]F:6QT97)=("XN7"XN7'EA<F0O>6%R9%]I;G!U="YH<' H

M;7!L871E+6ED("=087)S97));G!U="<-"EM!<G1U<FEU<SID;5]F:6QT97)=

M+61E8VQA<F%T:6]N(&-A;FYO="!N86UE('1E;7!L871E+6ED("=087)S97))
M;G!U="<-"EM!<G1U<FEU<SID;5]F:6QT97)=("XN7"XN7'EA<F0O97AA;7!L
M97,O>6%R9%]E>&%M<&QE7VAT='!?=&]?:')E9BYH<' H,S4I(#H 17)R;W(Z
M($-O;7!I;&4 86QL(&9I;&5S('=I=&  +4%E('1O('-U<'!O<G0 97AC97!T





M($5R<F]R.B!U<VEN9RUD96-L87)A=&EO;B!C86YN;W0 ;F%M92!T96UP;&%T


M87)A=&EO;B!C86YN;W0 ;F%M92!T96UP;&%T92UI9" G4&%R<V5R26YP=70G



M=&5R72 N+EPN+EQY87)D+V5X86UP;&5S+WEA<F1?97AA;7!L95]H='1P7W1O

M("U!92!T;R!S=7!P;W)T(&5X8V5P=&EO;B!H86YD;&EN9PT*5&]O;#H 9V-C

M+FAP<" Q,"DZ(&ES=')E86TZ($YO('-U8V  9FEL92!O<B!D:7)E8W1O<GD-

M*3H ;W-T<F5A;3H 3F\ <W5C:"!F:6QE(&]R(&1I<F5C=&]R>0T*5&]O;#H 
M9V-C+S,N, T*6T%R='5R:75S.F=C8U]F:6QT97)=("XN+RXN+WEA<F0O>6%R

M)R!T;VME; T*6T%R='5R:75S.F=C8U]F:6QT97)=("XN+RXN+WEA<F0O>6%R

M)R!T;VME; T*6T%R='5R:75S.F=C8U]F:6QT97)=("XN+RXN+WEA<F0O>6%R

M)R!T;VME; T*6T%R='5R:75S.F=C8U]F:6QT97)=("XN+RXN+WEA<F0O>6%R
M9%]B87-E7V=R86UM87(N:'!P*#DW*3H <&%R<V4 97)R;W( 870 96YD(&]F
M('-A=F5D(&9U;F-T:6]N('1E>'0-"EM!<G1U<FEU<SIG8V-?9FEL=&5R72 N
M+B\N+B]Y87)D+WEA<F1?=&]K96YI>F5R+FAP<" R."DZ('!A<G-E(&5R<F]R
M(&)E9F]R92! 4G5L95]4)PT*6T%R='5R:75S.F=C8U]F:6QT97)=("XN+RXN

M;W)E(&!])R!T;VME; T*6T%R='5R:75S.F=C8U]F:6QT97)=("XN+RXN+WEA



M92!E<G)O<B!B969O<F4 8#HZ)R!T;VME; T*6T%R='5R:75S.F=C8U]F:6QT

M97)R;W( 8F5F;W)E(& L)R!T;VME; T*6T%R='5R:75S.F=C8U]F:6QT97)=


M=7,Z9V-C7V9I;'1E<ET +BXO+BXO>6%R9"]Y87)D7W1O:V5N:7IE<BYH<' H
M-30I.B!)4T\ 0RLK(&9O<F)I9', 9&5C;&%R871I;VX ;V8 8&QI<W0G('=I

M7W1O:V5N:7IE<BYH<' H-30I.B!T96UP;&%T92UI9"! ;&ES=#QI;G0^)R!U
M<V5D(&%S(&$ 9&5C;&%R871O< T*6T%R='5R:75S.F=C8U]F:6QT97)=("XN

M8F5F;W)E(& Z.B< =&]K96X-"EM!<G1U<FEU<SIG8V-?9FEL=&5R72 N+B\N
M+B]Y87)D+WEA<F1?=&]K96YI>F5R+FAP<" U-2DZ('!A<G-E(&5R<F]R(&)E
M9F]R92! *2< =&]K96X-"EM!<G1U<FEU<SIG8V-?9FEL=&5R72 N+B\N+B]Y
M87)D+WEA<F1?=&]K96YI>F5R+FAP<" T-"DZ('!A<G-E(&5R<F]R(&)E9F]R
M92! 96YD)PT*6T%R='5R:75S.F=C8U]F:6QT97)=("XN+RXN+WEA<F0O>6%R


M+BXO+BXO>6%R9"]Y87)D7W1O:V5N:7IE<BYH<' H-38I.B!S>6YT87  97)R
M;W( 8F5F;W)E(& H)R!T;VME; T*6T%R='5R:75S.F=C8U]F:6QT97)=("XN


M9V-C7V9I;'1E<ET +BXO+BXO>6%R9"]Y87)D7W1O:V5N:7IE<BYH<' H-38I
M.B! =&MN<R< =6YD96-L87)E9" H9FER<W0 =7-E('1H:7, 9G5N8W1I;VXI

M:7IE<BYH<' H-38I.B H16%C:"!U;F1E8VQA<F5D(&ED96YT:69I97( :7, 
M<F5P;W)T960 ;VYL>2 -"EM!<G1U<FEU<SIG8V-?9FEL=&5R72 N+B\N+B]Y
M87)D+WEA<F1?=&]K96YI>F5R+FAP<" U."DZ('!A<G-E(&5R<F]R(&)E9F]R
M92! ?2< =&]K96X-"EM!<G1U<FEU<SIG8V-?9FEL=&5R72 N+B\N+B]Y87)D
M+WEA<F1?=&]K96YI>F5R+FAP<" V,BDZ(&!7;W)D)R!W87, ;F]T(&1E8VQA
M<F5D(&EN('1H:7, <V-O<&4-"EM!<G1U<FEU<SIG8V-?9FEL=&5R72 N+B\N
M+B]Y87)D+WEA<F1?=&]K96YI>F5R+FAP<" V-"DZ(&!)9&5N="< =V%S(&YO

M<ET +BXO+BXO>6%R9"]Y87)D7W1O:V5N:7IE<BYH<' H-C0I.B!S>6YT87  
M97)R;W( 8F5F;W)E(& [)R!T;VME; T*6T%R='5R:75S.F=C8U]F:6QT97)=

M96YT)R!W87, ;F]T(&1E8VQA<F5D(&EN('1H:7, <V-O<&4-"EM!<G1U<FEU
M<SIG8V-?9FEL=&5R72 N+B\N+B]Y87)D+WEA<F1?=&]K96YI>F5R+FAP<" V


M*3H 25-/($,K*R!F;W)B:61S(&1E8VQA<F%T:6]N(&]F(& -"EM!<G1U<FEU
M<SIG8V-?9FEL=&5R72 N+B\N+B]Y87)D+WEA<F1?=&]K96YI>F5R+FAP<" W

M:71H( T*6T%R='5R:75S.F=C8U]F:6QT97)=("XN+RXN+WEA<F0O>6%R9%]T

M96X-"EM!<G1U<FEU<SIG8V-?9FEL=&5R72 N+B\N+B]Y87)D+WEA<F1?=&]K
M96YI>F5R+FAP<" W-BDZ('!A<G-E(&5R<F]R(&)E9F]R92! 8B<-"EM!<G1U
M<FEU<SIG8V-?9FEL=&5R72 N+B\N+B]Y87)D+WEA<F1?=&]K96YI>F5R+FAP
M<" X,"DZ('-E;6EC;VQO;B!M:7-S:6YG(&%F=&5R(&1E8VQA<F%T:6]N(&]F
M(& -"EM!<G1U<FEU<SIG8V-?9FEL=&5R72 N+B\N+B]Y87)D+WEA<F1?=&]K
M96YI>F5R+FAP<" X,"DZ('!A<G-E(&5R<F]R(&)E9F]R92! +"< =&]K96X-
M"EM!<G1U<FEU<SIG8V-?9FEL=&5R72 N+B\N+B]Y87)D+WEA<F1?=&]K96YI

M:71H:6X <F5T=7)N( T*6T%R='5R:75S.F=C8U]F:6QT97)=("XN+RXN+WEA







M87)S92!E<G)O<B!B969O<F4 8#XG

M:6YG)R!W87, ;F]T(&1E8VQA<F5D(&EN('1H:7, <V-O<&4-"EM!<G1U<FEU
M<SIG8V-?9FEL=&5R72 N+B\N+B]Y87)D+WEA<F1?=&]K96YI>F5R+FAP<" X
M-RDZ("=L:7-T)R!I<R!U<V5D(&%S(&$ ='EP92P 8G5T(&ES(&YO="!D969I
M;F5D( T*6T%R='5R:75S.F=C8U]F:6QT97)=("XN+RXN+WEA<F0O>6%R9%]T
M;VME;FEZ97(N:'!P*#DP*3H 8'-T<FEN9R< =V%S(&YO="!D96-L87)E9"!I

M9"]Y87)D7W1O:V5N:7IE<BYH<' H.3 I.B!S>6YT87  97)R;W( 8F5F;W)E
M(& Z.B< =&]K96X-"EM!<G1U<FEU<SIG8V-?9FEL=&5R72 N+B\N+B]Y87)D
M+WEA<F1?=&]K96YI>F5R+FAP<" Y,2DZ('!A<G-E(&5R<F]R(&)E9F]R92! 
M*2< =&]K96X-"EM!<G1U<FEU<SIG8V-?9FEL=&5R72 N+B\N+B]Y87)D+WEA
M<F1?=&]K96YI>F5R+FAP<" Y,BDZ('!A<G-E(&5R<F]R(&)E9F]R92! *2< 
M=&]K96X-"EM!<G1U<FEU<SIG8V-?9FEL=&5R72 N+B\N+B]Y87)D+WEA<F1?
M=&]K96YI>F5R+FAP<" Y,RDZ(')E9&5F:6YI=&EO;B!O9B! <VEZ95]T('-I
M>F4H*2<-"EM!<G1U<FEU<SIG8V-?9FEL=&5R72 N+B\N+B]Y87)D+WEA<F1?
M=&]K96YI>F5R+FAP<" U-RDZ(&!S:7IE7W0 <VEZ92 I)R!P<F5V:6]U<VQY
M(&1E9FEN960 :&5R90T*6T%R='5R:75S.F=C8U]F:6QT97)=("XN+RXN+WEA
M<F0O>6%R9%]T;VME;FEZ97(N:'!P*#DS*3H <F5D969I;FET:6]N(&]F(&!S
M:7IE7W0 <VEZ92 I)PT*6T%R='5R:75S.F=C8U]F:6QT97)=("XN+RXN+WEA


M+BXO+BXO>6%R9"]Y87)D7W1O:V5N:7IE<BYH<' H.30I.B!P87)S92!E<G)O





M:" -"EM!<G1U<FEU<SIG8V-?9FEL=&5R72 N+B\N+B]Y87)D+W1E<W1S+WEA
M<F1?=&5S="YH<' H,3$P*3H :6YI=&EA;&EZ97( ;&ES="!B96EN9R!T<F5A
M=&5D(&%S(&-O;7!O=6YD( T*6T%R='5R:75S.F=C8U]F:6QT97)=("XN+RXN
M+WEA<F0O=&5S=',O>6%R9%]T97-T+FAP<" Q,3 I.B!C86YN;W0 8V]N=F5R




M(&UE;6)E<B! 96YD)R!I;B! =&MN<R<L('=H:6-H( T*5&]O;#H 9V-C+S,N
M,PT*6T%R='5R:75S.F=C8U]F:6QT97)=("XN+RXN+WEA<F0O>6%R9%]B87-E

M8#LG
M87)D7V)A<V5?9W)A;6UA<BYH<' H-3$I.B!E<G)O<CH <WEN=&%X(&5R<F]R
M(&)E9F]R92! .R< =&]K96X-"EM!<G1U<FEU<SIG8V-?9FEL=&5R72 N+B\N
M+B]Y87)D+WEA<F1?8F%S95]G<F%M;6%R+FAP<" X,RDZ(&5R<F]R.B!S>6YT
M87  97)R;W( 8F5F;W)E(& [)R!T;VME; T*6T%R='5R:75S.F=C8U]F:6QT
M97)=("XN+RXN+WEA<F0O>6%R9%]B87-E7V=R86UM87(N:'!P*#DW*3H 97)R
M;W(Z('!A<G-E(&5R<F]R(&%T(&5N9"!O9B!S879E9" -"EM!<G1U<FEU<SIG
M8V-?9FEL=&5R72 N+B\N+B]Y87)D+WEA<F1?=&]K96YI>F5R+FAP<" R."DZ

M=7,Z9V-C7V9I;'1E<ET +BXO+BXO>6%R9"]Y87)D7W1O:V5N:7IE<BYH<' H
M,S4I.B!E<G)O<CH <WEN=&%X(&5R<F]R(&)E9F]R92! ?2< =&]K96X-"EM!
M<G1U<FEU<SIG8V-?9FEL=&5R72 N+B\N+B]Y87)D+WEA<F1?=&]K96YI>F5R
M+FAP<" T,BDZ(&5R<F]R.B!)4T\ 0RLK(&9O<F)I9', 9&5C;&%R871I;VX 
M;V8 8'-T<FEN9PT*6T%R='5R:75S.F=C8U]F:6QT97)=("XN+RXN+WEA<F0O

M969O<F4 8#HZ)R!T;VME; T*6T%R='5R:75S.F=C8U]F:6QT97)=("XN+RXN


M+BXO+BXO>6%R9"]Y87)D7W1O:V5N:7IE<BYH<' H-3$I.B!E<G)O<CH )VQI
M<W0G(&ES('5S960 87, 82!T>7!E+"!B=70 :7, ;F]T( T*6T%R='5R:75S



M:V5N:7IE<BYH<' H-30I.B!E<G)O<CH =&5M<&QA=&4M:60 8&QI<W0\:6YT
M/B< =7-E9"!A<R!A( T*6T%R='5R:75S.F=C8U]F:6QT97)=("XN+RXN+WEA

M<B!B969O<F4 8#HZ)R!T;VME; T*6T%R='5R:75S.F=C8U]F:6QT97)=("XN



M<WEN=&%X(&5R<F]R(&)E9F]R92! 96YD)PT*6T%R='5R:75S.F=C8U]F:6QT


M=7)I=7,Z9V-C7V9I;'1E<ET +BXO+BXO>6%R9"]Y87)D7W1O:V5N:7IE<BYH
M<' H-38I.B!E<G)O<CH <WEN=&%X(&5R<F]R(&)E9F]R92! *"< =&]K96X-
M"EM!<G1U<FEU<SIG8V-?9FEL=&5R72 N+B\N+B]Y87)D+WEA<F1?=&]K96YI
M>F5R+FAP<" U-BDZ(&5R<F]R.B!)4T\ 0RLK(&9O<F)I9', 9&5C;&%R871I

M9"]Y87)D7W1O:V5N:7IE<BYH<' H-38I.B!E<G)O<CH 8'1K;G,G('5N9&5C
M;&%R960 *&9I<G-T('5S92!T:&ES( T*6T%R='5R:75S.F=C8U]F:6QT97)=

M86-H('5N9&5C;&%R960 :61E;G1I9FEE<B!I<R -"EM!<G1U<FEU<SIG8V-?
M9FEL=&5R72 N+B\N+B]Y87)D+WEA<F1?=&]K96YI>F5R+FAP<" U."DZ(&5R
M<F]R.B!S>6YT87  97)R;W( 8F5F;W)E(&!])R!T;VME; T*6T%R='5R:75S

M*3H 97)R;W(Z(&!7;W)D)R!W87, ;F]T(&1E8VQA<F5D(&EN('1H:7, <V-O
M<&4-"EM!<G1U<FEU<SIG8V-?9FEL=&5R72 N+B\N+B]Y87)D+WEA<F1?=&]K
M96YI>F5R+FAP<" V-"DZ(&5R<F]R.B! 261E;G0G('=A<R!N;W0 9&5C;&%R
M960 :6X =&AI<R!S8V]P90T*6T%R='5R:75S.F=C8U]F:6QT97)=("XN+RXN

M<G)O<B!B969O<F4 8#LG
M+BXO+BXO>6%R9"]Y87)D7W1O:V5N:7IE<BYH<' H-C I.B!E<G)O<CH 8%=O

M=7,Z9V-C7V9I;'1E<ET +BXO+BXO>6%R9"]Y87)D7W1O:V5N:7IE<BYH<' H

M07)T=7)I=7,Z9V-C7V9I;'1E<ET +BXO+BXO>6%R9"]Y87)D7W1O:V5N:7IE
M<BYH<' H-C I.B!E<G)O<CH 25-/($,K*R!F;W)B:61S(&1E8VQA<F%T:6]N
M(&]F(& -"EM!<G1U<FEU<SIG8V-?9FEL=&5R72 N+B\N+B]Y87)D+WEA<F1?
M=&]K96YI>F5R+FAP<" W-2DZ(&5R<F]R.B!)4T\ 0RLK(&9O<F)I9', 9&5C
M;&%R871I;VX ;V8 8'-T<FEN9PT*6T%R='5R:75S.F=C8U]F:6QT97)=("XN

M>"!E<G)O<B!B969O<F4 8#HZ)R!T;VME; T*6T%R='5R:75S.F=C8U]F:6QT




M=7)I=7,Z9V-C7V9I;'1E<ET +BXO+BXO>6%R9"]Y87)D7W1O:V5N:7IE<BYH

M"EM!<G1U<FEU<SIG8V-?9FEL=&5R72 N+B\N+B]Y87)D+WEA<F1?=&]K96YI
M>F5R+FAP<" X,"DZ(&5R<F]R.B!)4T\ 0RLK(&9O<F)I9', 9&5F:6YI;F< 
M='EP97, =VET:&EN( T*6T%R='5R:75S.F=C8U]F:6QT97)=("XN+RXN+WEA




M07)T=7)I=7,Z9V-C7V9I;'1E<ET +BXO+BXO>6%R9"]Y87)D7W1O:V5N:7IE

M96X-"EM!<G1U<FEU<SIG8V-?9FEL=&5R72 N+B\N+B]Y87)D+WEA<F1?=&]K
M96YI>F5R+FAP<" X,RDZ(&5R<F]R.B!S>6YT87  97)R;W( 8F5F;W)E(& ^
M)R!T;VME; T*6T%R='5R:75S.F=C8U]F:6QT97)=("XN+RXN+WEA<F0O>6%R

M9&5C;&%R960 :6X =&AI<R -"EM!<G1U<FEU<SIG8V-?9FEL=&5R72 N+B\N
M+B]Y87)D+WEA<F1?=&]K96YI>F5R+FAP<" X-RDZ(&5R<F]R.B G;&ES="< 

M7V9I;'1E<ET +BXO+BXO>6%R9"]Y87)D7W1O:V5N:7IE<BYH<' H.3 I.B!E
M<G)O<CH 8'-T<FEN9R< =V%S(&YO="!D96-L87)E9"!I;B!T:&ES( T*6T%R
M='5R:75S.F=C8U]F:6QT97)=("XN+RXN+WEA<F0O>6%R9%]T;VME;FEZ97(N
M:'!P*#DP*3H 97)R;W(Z('-Y;G1A>"!E<G)O<B!B969O<F4 8#HZ)R!T;VME
M; T*6T%R='5R:75S.F=C8U]F:6QT97)=("XN+RXN+WEA<F0O>6%R9%]T;VME
M;FEZ97(N:'!P*#DQ*3H 97)R;W(Z('-Y;G1A>"!E<G)O<B!B969O<F4 8"DG

M7W1O:V5N:7IE<BYH<' H.3(I.B!E<G)O<CH <WEN=&%X(&5R<F]R(&)E9F]R
M92! *2< =&]K96X-"EM!<G1U<FEU<SIG8V-?9FEL=&5R72 N+B\N+B]Y87)D
M+WEA<F1?=&]K96YI>F5R+FAP<" Y,RDZ(&5R<F]R.B!R961E9FEN:71I;VX 

M+BXO>6%R9"]Y87)D7W1O:V5N:7IE<BYH<' H-3<I.B!E<G)O<CH 8'-I>F5?
M="!S:7IE*"DG('!R979I;W5S;'D 9&5F:6YE9" -"EM!<G1U<FEU<SIG8V-?
M9FEL=&5R72 N+B\N+B]Y87)D+WEA<F1?=&]K96YI>F5R+FAP<" Y,RDZ(&5R

M=7,Z9V-C7V9I;'1E<ET +BXO+BXO>6%R9"]Y87)D7W1O:V5N:7IE<BYH<' H
M-3<I.B!E<G)O<CH 8'-I>F5?="!S:7IE*"DG('!R979I;W5S;'D 9&5F:6YE
M9" -"EM!<G1U<FEU<SIG8V-?9FEL=&5R72 N+B\N+B]Y87)D+WEA<F1?=&]K
M96YI>F5R+FAP<" Y-"DZ(&5R<F]R.B!S>6YT87  97)R;W( 8F5F;W)E(&!]
M)R!T;VME; T*6T%R='5R:75S.F=C8U]F:6QT97)=("XN+RXN+WEA<F0O=&5S
M=',O>6%R9%]T97-T+FAP<" Q,3 I.B!E<G)O<CH ;F]N+71E;7!L871E('1Y
M<&4 8 T*6T%R='5R:75S.F=C8U]F:6QT97)=("XN+RXN+WEA<F0O=&5S=',O
M>6%R9%]T97-T+FAP<" Q,3 I.B!E<G)O<CH 25-/($,K*R!F;W)B:61S(&1E






M.B!R97%U97-T(&9O<B!M96UB97( 8&)E9VEN)R!I;B! =&MN<PT*6T%R='5R
M:75S.F=C8U]F:6QT97)=("XN+RXN+WEA<F0O=&5S=',O>6%R9%]T97-T+FAP
M<" Q,3,I.B!E<G)O<CH <F5Q=65S="!F;W( ;65M8F5R(&!E;F0G(&EN(&!T

M;2!&:6QE<UQ-:6-R;W-O9G0 5FES=6%L(%-T=61I;UQ60SDX7&EN8VQU9&5<
M=71I;&ET>2 X,2DZ(&5R<F]R.B!T:&4 9VQO8F%L('-C;W!E(&AA<R!N;R B




M;W(Z('1H92!G;&]B86P <V-O<&4 :&%S(&YO(")V86QU95]T>7!E( T*4#I<
M4')O9W)A;2!&:6QE<UQ-:6-R;W-O9G0 5FES=6%L(%-T=61I;UQ60SDX7&EN
M8VQU9&5<=71I;&ET>2 X,BDZ(&5R<F]R.B!E>'!E8W1E9"!A("([( T*4#I<
M4')O9W)A;2!&:6QE<UQ-:6-R;W-O9G0 5FES=6%L(%-T=61I;UQ60SDX7&EN
M8VQU9&5<=71I;&ET>2 X,RDZ(&5R<F]R.B!T:&4 9VQO8F%L('-C;W!E(&AA
M<R!N;R B9&ES=&%N8V5?='EP92(-"E Z7%!R;V=R86T 1FEL97-<36EC<F]S

M<G)O<CH 97AP96-T960 82 B.R(-"BXN7"XN7'EA<F0O>6%R9%]I;G!U="YH
M<' H,3 I.B!E<G)O<CH 8VQA<W, (G-T9#HZ:71E<F%T;W)?=')A:71S/'EA
M<F0Z.E!A<G-E<DEN<'5T/'-T9#HZ8F%S:6-?<W1R:6YG/&-H87(L('-T9#HZ
M8VAA<E]T<F%I=',\8VAA<CXL('-T9#HZ86QL;V-A=&]R/&-H87(^/CHZ8V]N
M<W1?:71E<F%T;W(]>W-T9#HZ86QL;V-A=&]R/&-H87(^.CIC;VYS=%]P;VEN
M=&5R/7MC;VYS="!C:&%R("I]?3XZ.FET97)A=&]R/7MS=&0Z.F)A<VEC7W-T
M<FEN9SQC:&%R+"!S=&0Z.F-H87)?=')A:71S/&-H87(^+"!S=&0Z.F%L;&]C
M871O<CQC:&%R/CXZ.F-O;G-T7VET97)A=&]R/7MS=&0Z.F%L;&]C871O<CQC
M:&%R/CHZ8V]N<W1?<&]I;G1E<CU[8V]N<W0 8VAA<B J?7U]/B( :&%S(&YO
M(&UE;6)E<B B=F%L=65?='EP92(-"BXN7"XN7'EA<F0O>6%R9%]I;G!U="YH
M<' H-S8I.B!E<G)O<CH 8VQA<W, (G-T9#HZ8F%S:6-?<W1R:6YG/&-H87(L
M('-T9#HZ8VAA<E]T<F%I=',\8VAA<CXL('-T9#HZ86QL;V-A=&]R/&-H87(^
M/B( :&%S(&YO(&UE;6)E<B B<'5S:%]B86-K( T*5&]O;#H :6-L+S<-"E1O

M9%QY87)D+FAP<" Y*3H 17)R;W(A($4P-3DZ(&-O;" R,"D =6YA8FQE('1O
M(&]P96X )W-S=')E86TG( T*+BY<+BY<>6%R9%QY87)D+FAP<" Y*3H 17)R
M;W(A($4P-3DZ(&-O;" R,"D =6YA8FQE('1O(&]P96X )W-S=')E86TG( T*
M6T]7.U)U8GE=.B N+EPN+EQY87)D7'EA<F0N:'!P*#DI.B!.;W1E(2!.,SDS
M.B!C;VPH,C I(&EN8VQU9&5D(&9R;VT +BY<+BY<>6%R9%QT97-T<UQY87)D
M7W1E<W0N:'!P*#DI( T*+BY<+BY<>6%R9%QY87)D+FAP<" Y*3H 3F]T92$ 

M>6%R9%]T97-T+FAP<" Y*2 -"EM/5SM2=6)Y73H +BY<+BY<>6%R9%QY87)D




M;" R,"D =6YA8FQE('1O(&]P96X )VES=')E86TG( T*+BY<+BY<>6%R9%QY

M<&5N("=I<W1R96%M)R -"EM/5SM2=6)Y73H +BY<+BY<>6%R9%QY87)D+FAP

M<W1R96%M)R -"BXN7"XN7'EA<F1<>6%R9"YH<' H,3$I.B!%<G)O<B$ 13 U

M>5TZ("XN7"XN7'EA<F1<>6%R9"YH<' H,3,I.B!%<G)O<B$ 13 U.3H 8V]L



M17)R;W(A($4P-3DZ(&-O;" Q-RD =6YA8FQE('1O(&]P96X )VQI<W0G( T*

M('5N86)L92!T;R!O<&5N("=L:7-T)R -"EM/5SM2=6)Y73H +BY<+BY<>6%R

M;R!O<&5N("=S970G( T*+BY<+BY<>6%R9%QY87)D+FAP<" Q-BDZ($5R<F]R


M;" R,2D =6YA8FQE('1O(&]P96X )VET97)A=&]R)R -"BXN7"XN7'EA<F1<

M;W!E;B G:71E<F%T;W(G( T*6T]7.U)U8GE=.B N+EPN+EQY87)D7'EA<F0N



M>5TZ("XN7"XN7'EA<F1<>6%R9"YH<' H,C,I.B!%<G)O<B$ 13 S,SH 8V]L


M86UE(&1O97, ;F]T(')E9F5R96YC92!A(&YA;65S<&%C92 -"EM/5SM2=6)Y
M73H +BY<+BY<>6%R9%QY87)D7V-H87)?<V5T+FAP<" Q,BDZ($5R<F]R(2!%
M,3(Q.B!C;VPH,3(I('-Y;G1A>"!E<G)O<B -"BXN7"XN7'EA<F1<>6%R9%]C


M<' H-SDI.B!%<G)O<B$ 13,V,#H


M(&-O;" R-2D ='EP961E9B G8F%S:6-?8VAA<E]S970G(&1E9FEN960 =VET
M:&]U="!A;B!E>'!L:6-I="!T>7!E( T*6T]7.U)U8GE=.B N+EPN+EQY87)D



M(&-O;" R-2D <WEN=&%X(&5R<F]R.R!P<F]B86)L92!C875S93H ;6ES<VEN



M.B!C;VPH-2D <WEN=&%X(&5R<F]R( T*6T]7.U)U8GE=.B N+EPN+EQY87)D

M<WEN=&%X(&5R<F]R( T*+BY<+BY<>6%R9%QY87)D7V-H87)?<V5T+FAP<" Q

M=6)Y73H +BY<+BY<>6%R9%QY87)D7V-H87)?<V5T+FAP<" Q-3(I.B!%<G)O

M9%]C:&%R7W-E="YH<' H,34R*3H 17)R;W(A($4Q,C$Z(&-O;" U*2!S>6YT

M="YH<' H,3$Q*3H 17)R;W(A($4T.3 Z(&-O;" R-RD <WEN=&%X(&5R<F]R
M(&)E9F]R92 G8VAA<E]S970G.R!P<F]B86)L92!C875S93H :6YC;W)R96-T


M<B!B969O<F4 )V-H87)?<V5T)SL <')O8F%B;&4 8V%U<V4Z(&EN8V]R<F5C
M=&QY('-P96QL960 ='EP92!N86UE( T*6T]7.U)U8GE=.B N+EPN+EQY87)D

M=&5M<&QA=&4 8VQA<W, :6YS=&%N=&EA=&EO;B!F;W( )V-H87)?<V5T7W)A
M;F=E/#DW


M:6YS=&%N=&EA=&EO;B!F;W( )V-H87)?<V5T7W)A;F=E/#DW
M<R!I;CH +BY<+BY<>6%R9%QY87)D7V-H87)?<V5T+FAP<" Q-C4I("AC;VP 

M,3<S*3H 17)R;W(A($4S-C Z(&-O;" Q.2D ='EP961E9B G8VAA<E]S971?
M=6YI;VXG(&1E9FEN960 =VET:&]U="!A;B!E>'!L:6-I="!T>7!E( T*+BY<
M+BY<>6%R9%QY87)D7V-H87)?<V5T+FAP<" Q-S,I.B!%<G)O<B$ 13,V,#H 





M.B!C;VPH,3DI('-Y;G1A>"!E<G)O<CL <')O8F%B;&4 8V%U<V4Z(&UI<W-I
M;F< )SLG( T*6T]7.U)U8GE=.B N+EPN+EQY87)D7'EA<F1?8VAA<E]S970N





M*2!S>6YT87  97)R;W([('!R;V)A8FQE(&-A=7-E.B!M:7-S:6YG("<[)R -
M"BXN7"XN7'EA<F1<>6%R9%]C:&%R7W-E="YH<' H,3 V*3H 17)R;W(A($4P

M:6YG("<[)R -"EM/5SM2=6)Y73H +BY<+BY<>6%R9%QY87)D7V-H87)?<V5T



M(&5R<F]R<SH 8V]M<&EL871I;VX 86)O<G1E9" -"EM/5SM2=6)Y73H 17)R
M;W(Z($-O;7!I;&5R(')E='5R;F5D(&$ 8F%D('-T871U<R!C;VUP:6QI;F< 
M)VUA:6XN8W!P)PT*5&]O;#H =F,O, T*5&]O;#H

M,#H 0RLK(&5X8V5P=&EO;B!H86YD;&5R('5S960L(&)U="!U;G=I;F0 <V5M
M86YT:6-S(&%R92!N;W0 96YA8FQE9"X 4W!E8VEF>2 M1U -"E Z7%!R;V=R
M86US7$U31&5V7&EN8VQU9&5<;W-T<F5A;2 X.2DZ('=A<FYI;F< 0S0U,S Z
M($,K*R!E>&-E<'1I;VX :&%N9&QE<B!U<V5D+"!B=70 =6YW:6YD('-E;6%N


M0RLK(&5X8V5P=&EO;B!H86YD;&5R('5S960L(&)U="!U;G=I;F0 <V5M86YT
M:6-S(&%R92!N;W0 96YA8FQE9"X 4W!E8VEF>2 M1U -"E Z7%!R;V=R86US

M*RL 97AC97!T:6]N(&AA;F1L97( =7-E9"P 8G5T('5N=VEN9"!S96UA;G1I
M8W, 87)E(&YO="!E;F%B;&5D+B!3<&5C:69Y("U'6 T*4#I<4')O9W)A;7-<

M*R!E>&-E<'1I;VX :&%N9&QE<B!U<V5D+"!B=70 =6YW:6YD('-E;6%N=&EC


M(&5X8V5P=&EO;B!H86YD;&5R('5S960L(&)U="!U;G=I;F0 <V5M86YT:6-S
M(&%R92!N;W0 96YA8FQE9"X 4W!E8VEF>2 M1U -"E Z7%!R;V=R86US7$U3

M97AC97!T:6]N(&AA;F1L97( =7-E9"P 8G5T('5N=VEN9"!S96UA;G1I8W, 
M87)E(&YO="!E;F%B;&5D+B!3<&5C:69Y("U'6 T*4#I<4')O9W)A;7-<35-$

M>&-E<'1I;VX :&%N9&QE<B!U<V5D+"!B=70 =6YW:6YD('-E;6%N=&EC<R!A


M8V5P=&EO;B!H86YD;&5R('5S960L(&)U="!U;G=I;F0 <V5M86YT:6-S(&%R
M92!N;W0 96YA8FQE9"X 4W!E8VEF>2 M1U -"E Z7%!R;V=R86US7$U31&5V

M97!T:6]N(&AA;F1L97( =7-E9"P 8G5T('5N=VEN9"!S96UA;G1I8W, 87)E
M(&YO="!E;F%B;&5D+B!3<&5C:69Y("U'6 T*4#I<4')O9W)A;7-<35-$979<

M<'1I;VX :&%N9&QE<B!U<V5D+"!B=70 =6YW:6YD('-E;6%N=&EC<R!A<F4 


M=&EO;B!H86YD;&5R('5S960L(&)U="!U;G=I;F0 <V5M86YT:6-S(&%R92!N
M;W0 96YA8FQE9"X 4W!E8VEF>2 M1U -"E Z7%!R;V=R86US7$U31&5V7&EN

M:6]N(&AA;F1L97( =7-E9"P 8G5T('5N=VEN9"!S96UA;G1I8W, 87)E(&YO
M="!E;F%B;&5D+B!3<&5C:69Y("U'6 T*4#I<4')O9W)A;7-<35-$979<:6YC

M;VX :&%N9&QE<B!U<V5D+"!B=70 =6YW:6YD('-E;6%N=&EC<R!A<F4 ;F]T


M;B!H86YD;&5R('5S960L(&)U="!U;G=I;F0 <V5M86YT:6-S(&%R92!N;W0 
M96YA8FQE9"X 4W!E8VEF>2 M1U -"E Z7%!R;V=R86US7$U31&5V7&EN8VQU

M(&AA;F1L97( =7-E9"P 8G5T('5N=VEN9"!S96UA;G1I8W, 87)E(&YO="!E
M;F%B;&5D+B!3<&5C:69Y("U'6 T*4#I<4')O9W)A;7-<35-$979<:6YC;'5D

M86YD;&5R('5S960L(&)U="!U;G=I;F0 <V5M86YT:6-S(&%R92!N;W0 96YA
M8FQE9"X 4W!E8VEF>2 M1U -"E Z7%!R;V=R86US7$U31&5V7&EN8VQU9&5<

M;F1L97( =7-E9"P 8G5T('5N=VEN9"!S96UA;G1I8W, 87)E(&YO="!E;F%B
M;&5D+B!3<&5C:69Y("U'6 T*4#I<4')O9W)A;7-<35-$979<:6YC;'5D95QO

M9&QE<B!U<V5D+"!B=70 =6YW:6YD('-E;6%N=&EC<R!A<F4 ;F]T(&5N86)L


M;&5R('5S960L(&)U="!U;G=I;F0 <V5M86YT:6-S(&%R92!N;W0 96YA8FQE
M9"X 4W!E8VEF>2 M1U -"E Z7%!R;V=R86US7$U31&5V7&EN8VQU9&5<;W-T

M97( =7-E9"P 8G5T('5N=VEN9"!S96UA;G1I8W, 87)E(&YO="!E;F%B;&5D
M+B!3<&5C:69Y("U'6 T*4#I<4')O9W)A;7-<35-$979<:6YC;'5D95QO<W1R

M<B!U<V5D+"!B=70 =6YW:6YD('-E;6%N=&EC<R!A<F4 ;F]T(&5N86)L960N


M('5S960L(&)U="!U;G=I;F0 <V5M86YT:6-S(&%R92!N;W0 96YA8FQE9"X 
M4W!E8VEF>2 M1U -"E Z7%!R;V=R86US7$U31&5V7&EN8VQU9&5<;W-T<F5A

M=7-E9"P 8G5T('5N=VEN9"!S96UA;G1I8W, 87)E(&YO="!E;F%B;&5D+B!3
M<&5C:69Y("U'6 T*4#I<4')O9W)A;7-<35-$979<:6YC;'5D95QO<W1R96%M

M<V5D+"!B=70 =6YW:6YD('-E;6%N=&EC<R!A<F4 ;F]T(&5N86)L960N(%-P


M960L(&)U="!U;G=I;F0 <V5M86YT:6-S(&%R92!N;W0 96YA8FQE9"X 4W!E
M8VEF>2 M1U -"E Z7%!R;V=R86US7$U31&5V7&EN8VQU9&5<;W-T<F5A;2 R

M9"P 8G5T('5N=VEN9"!S96UA;G1I8W, 87)E(&YO="!E;F%B;&5D+B!3<&5C
M:69Y("U'6 T*4#I
M,"DZ('=A<FYI;F< 0S0U,S Z($,K*R!E>&-E<'1I;VX :&%N9&QE<B!U<V5D
M+"!B=70 =6YW:6YD('-E;6%N=&EC<R!A<F4 ;F]T(&5N86)L960N(%-P96-I


M(&)U="!U;G=I;F0 <V5M86YT:6-S(&%R92!N;W0 96YA8FQE9"X 4W!E8VEF
M>2 M1U -"E Z7%!R;V=R86US7$U31&5V7&EN8VQU9&5<;W-T<F5A;2 R.3,I

M8G5T('5N=VEN9"!S96UA;G1I8W, 87)E(&YO="!E;F%B;&5D+B!3<&5C:69Y
M("U'6 T*4#I
M('=A<FYI;F< 0S0U,S Z($,K*R!E>&-E<'1I;VX :&%N9&QE<B!U<V5D+"!B
M=70 =6YW:6YD('-E;6%N=&EC<R!A<F4 ;F]T(&5N86)L960N(%-P96-I9GD 


M="!U;G=I;F0 <V5M86YT:6-S(&%R92!N;W0 96YA8FQE9"X 4W!E8VEF>2 M
M1U -"E Z7%!R;V=R86US7$U31&5V7&EN8VQU9&5<:7-T<F5A;2 U,3(I.B!W

M('5N=VEN9"!S96UA;G1I8W, 87)E(&YO="!E;F%B;&5D+B!3<&5C:69Y("U'
M6 T*4#I

M;G=I;F0 <V5M86YT:6-S(&%R92!N;W0 96YA8FQE9"X 4W!E8VEF>2 M1U -
M"E Z7%!R;V=R86US7$U31&5V7&EN8VQU9&5<:7-T<F5A;2 W-2DZ('=A<FYI
M;F< 0S0U,S Z($,K*R!E>&-E<'1I;VX :&%N9&QE<B!U<V5D+"!B=70 =6YW

M.EQ0<F]G<F%M<UQ-4T1E=EQI;F-L=61E7&ES=')E86TH.38I.B!W87)N:6YG

M9"!S96UA;G1I8W, 87)E(&YO="!E;F%B;&5D+B!3<&5C:69Y("U'6 T*4#I<

M0S0U,S Z($,K*R!E>&-E<'1I;VX :&%N9&QE<B!U<V5D+"!B=70 =6YW:6YD



M<V5M86YT:6-S(&%R92!N;W0 96YA8FQE9"X 4W!E8VEF>2 M1U -"E Z7%!R
M;V=R86US7$U31&5V7&EN8VQU9&5<:7-T<F5A;2 Q,S4I.B!W87)N:6YG($,T

M96UA;G1I8W, 87)E(&YO="!E;F%B;&5D+B!3<&5C:69Y("U'6 T*4#I<4')O

M,S Z($,K*R!E>&-E<'1I;VX :&%N9&QE<B!U<V5D+"!B=70 =6YW:6YD('-E


M,#H 0RLK(&5X8V5P=&EO;B!H86YD;&5R('5S960L(&)U="!U;G=I;F0 <V5M
M86YT:6-S(&%R92!N;W0 96YA8FQE9"X 4W!E8VEF>2 M1U -"E Z7%!R;V=R
M86US7$U31&5V7&EN8VQU9&5<:7-T<F5A;2 Q-S I.B!W87)N:6YG($,T-3,P

M;G1I8W, 87)E(&YO="!E;F%B;&5D+B!3<&5C:69Y("U'6 T*4#I<4')O9W)A

M($,K*R!E>&-E<'1I;VX :&%N9&QE<B!U<V5D+"!B=70 =6YW:6YD('-E;6%N


M0RLK(&5X8V5P=&EO;B!H86YD;&5R('5S960L(&)U="!U;G=I;F0 <V5M86YT
M:6-S(&%R92!N;W0 96YA8FQE9"X 4W!E8VEF>2 M1U -"E Z7%!R;V=R86US

M*RL 97AC97!T:6]N(&AA;F1L97( =7-E9"P 8G5T('5N=VEN9"!S96UA;G1I
M8W, 87)E(&YO="!E;F%B;&5D+B!3<&5C:69Y("U'6 T*4#I<4')O9W)A;7-<

M*R!E>&-E<'1I;VX :&%N9&QE<B!U<V5D+"!B=70 =6YW:6YD('-E;6%N=&EC


M(&5X8V5P=&EO;B!H86YD;&5R('5S960L(&)U="!U;G=I;F0 <V5M86YT:6-S
M(&%R92!N;W0 96YA8FQE9"X 4W!E8VEF>2 M1U -"E Z7%!R;V=R86US7$U3

M97AC97!T:6]N(&AA;F1L97( =7-E9"P 8G5T('5N=VEN9"!S96UA;G1I8W, 
M87)E(&YO="!E;F%B;&5D+B!3<&5C:69Y("U'6 T*4#I<4')O9W)A;7-<35-$

M>&-E<'1I;VX :&%N9&QE<B!U<V5D+"!B=70 =6YW:6YD('-E;6%N=&EC<R!A


M8V5P=&EO;B!H86YD;&5R('5S960L(&)U="!U;G=I;F0 <V5M86YT:6-S(&%R
M92!N;W0 96YA8FQE9"X 4W!E8VEF>2 M1U -"E Z7%!R;V=R86US7$U31&5V

M97!T:6]N(&AA;F1L97( =7-E9"P 8G5T('5N=VEN9"!S96UA;G1I8W, 87)E
M(&YO="!E;F%B;&5D+B!3<&5C:69Y("U'6 T*4#I<4')O9W)A;7-<35-$979<

M<'1I;VX :&%N9&QE<B!U<V5D+"!B=70 =6YW:6YD('-E;6%N=&EC<R!A<F4 


M=&EO;B!H86YD;&5R('5S960L(&)U="!U;G=I;F0 <V5M86YT:6-S(&%R92!N
M;W0 96YA8FQE9"X 4W!E8VEF>2 M1U -"E Z7%!R;V=R86US7$U31&5V7&EN

M:6]N(&AA;F1L97( =7-E9"P 8G5T('5N=VEN9"!S96UA;G1I8W, 87)E(&YO
M="!E;F%B;&5D+B!3<&5C:69Y("U'6 T*4#I<4')O9W)A;7-<35-$979<:6YC

M;VX :&%N9&QE<B!U<V5D+"!B=70 =6YW:6YD('-E;6%N=&EC<R!A<F4 ;F]T


M;B!H86YD;&5R('5S960L(&)U="!U;G=I;F0 <V5M86YT:6-S(&%R92!N;W0 
M96YA8FQE9"X 4W!E8VEF>2 M1U -"E Z7%!R;V=R86US7$U31&5V7&EN8VQU

M(&AA;F1L97( =7-E9"P 8G5T('5N=VEN9"!S96UA;G1I8W, 87)E(&YO="!E
M;F%B;&5D+B!3<&5C:69Y("U'6 T*4#I<4')O9W)A;7-<35-$979<:6YC;'5D

M:&%N9&QE<B!U<V5D+"!B=70 =6YW:6YD('-E;6%N=&EC<R!A<F4 ;F]T(&5N


M86YD;&5R('5S960L(&)U="!U;G=I;F0 <V5M86YT:6-S(&%R92!N;W0 96YA
M8FQE9"X 4W!E8VEF>2 M1U -"E Z7%!R;V=R86US7$U31&5V7&EN8VQU9&5<

M;F1L97( =7-E9"P 8G5T('5N=VEN9"!S96UA;G1I8W, 87)E(&YO="!E;F%B
M;&5D+B!3<&5C:69Y("U'6 T*4#I<4')O9W)A;7-<35-$979<:6YC;'5D95QI

M;&5R('5S960L(&)U="!U;G=I;F0 <V5M86YT:6-S(&%R92!N;W0 96YA8FQE
M9"X 4W!E8VEF>2 M1U -"E Z7%!R;V=R86US7$U31&5V7&EN8VQU9&5<:7-T
M<F5A;2 W-2DZ('=A<FYI;F< 0S0U,S Z($,K*R!E>&-E<'1I;VX :&%N9&QE
M<B!U<V5D+"!B=70 =6YW:6YD('-E;6%N=&EC<R!A<F4 ;F]T(&5N86)L960N


M=7-E9"P 8G5T('5N=VEN9"!S96UA;G1I8W, 87)E(&YO="!E;F%B;&5D+B!3
M<&5C:69Y("U'6 T*4#I<4')O9W)A;7-<35-$979<:6YC;'5D95QI<W1R96%M

M<V5D+"!B=70 =6YW:6YD('-E;6%N=&EC<R!A<F4 ;F]T(&5N86)L960N(%-P


M960L(&)U="!U;G=I;F0 <V5M86YT:6-S(&%R92!N;W0 96YA8FQE9"X 4W!E
M8VEF>2 M1U -"E Z7%!R;V=R86US7$U31&5V7&EN8VQU9&5<:7-T<F5A;2 Q

M9"P 8G5T('5N=VEN9"!S96UA;G1I8W, 87)E(&YO="!E;F%B;&5D+B!3<&5C
M:69Y("U'6 T*4#I
M-BDZ('=A<FYI;F< 0S0U,S Z($,K*R!E>&-E<'1I;VX :&%N9&QE<B!U<V5D
M+"!B=70 =6YW:6YD('-E;6%N=&EC<R!A<F4 ;F]T(&5N86)L960N(%-P96-I


M(&)U="!U;G=I;F0 <V5M86YT:6-S(&%R92!N;W0 96YA8FQE9"X 4W!E8VEF
M>2 M1U -"E Z7%!R;V=R86US7$U31&5V7&EN8VQU9&5<:7-T<F5A;2 Q-S I

M8G5T('5N=VEN9"!S96UA;G1I8W, 87)E(&YO="!E;F%B;&5D+B!3<&5C:69Y
M("U'6 T*4#I
M('=A<FYI;F< 0S0U,S Z($,K*R!E>&-E<'1I;VX :&%N9&QE<B!U<V5D+"!B
M=70 =6YW:6YD('-E;6%N=&EC<R!A<F4 ;F]T(&5N86)L960N(%-P96-I9GD 


M="!U;G=I;F0 <V5M86YT:6-S(&%R92!N;W0 96YA8FQE9"X 4W!E8VEF>2 M


M('5N=VEN9"!S96UA;G1I8W, 87)E(&YO="!E;F%B;&5D+B!3<&5C:69Y("U'
M6 T*4#I
M<FYI;F< 0S0U,S Z($,K*R!E>&-E<'1I;VX :&%N9&QE<B!U<V5D+"!B=70 
M=6YW:6YD('-E;6%N=&EC<R!A<F4 ;F]T(&5N86)L960N(%-P96-I9GD +4=8


M;G=I;F0 <V5M86YT:6-S(&%R92!N;W0 96YA8FQE9"X 4W!E8VEF>2 M1U -
M"E Z7%!R;V=R86US7$U31&5V7&EN8VQU9&5<:7-T<F5A;2 R-3$I.B!W87)N

M=VEN9"!S96UA;G1I8W, 87)E(&YO="!E;F%B;&5D+B!3<&5C:69Y("U'6 T*
M4#I
M;F< 0S0U,S Z($,K*R!E>&-E<'1I;VX :&%N9&QE<B!U<V5D+"!B=70 =6YW

M.EQ0<F]G<F%M<UQ-4T1E=EQI;F-L=61E7&ES=')E86TH,C<W*3H =V%R;FEN

M;F0 <V5M86YT:6-S(&%R92!N;W0 96YA8FQE9"X 4W!E8VEF>2 M1U -"E Z
M7%!R;V=R86US7$U31&5V7&EN8VQU9&5<:7-T<F5A;2 R.3$I.B!W87)N:6YG

M9"!S96UA;G1I8W, 87)E(&YO="!E;F%B;&5D+B!3<&5C:69Y("U'6 T*4#I<

M0S0U,S Z($,K*R!E>&-E<'1I;VX :&%N9&QE<B!U<V5D+"!B=70 =6YW:6YD



M<V5M86YT:6-S(&%R92!N;W0 96YA8FQE9"X 4W!E8VEF>2 M1U -"E Z7%!R


M96UA;G1I8W, 87)E(&YO="!E;F%B;&5D+B!3<&5C:69Y("U'6 T*4#I<4')O

M,S Z($,K*R!E>&-E<'1I;VX :&%N9&QE<B!U<V5D+"!B=70 =6YW:6YD('-E


M,#H 0RLK(&5X8V5P=&EO;B!H86YD;&5R('5S960L(&)U="!U;G=I;F0 <V5M
M86YT:6-S(&%R92!N;W0 96YA8FQE9"X 4W!E8VEF>2 M1U -"E Z7%!R;V=R
M86US7$U31&5V7&EN8VQU9&5<:7-T<F5A;2 T,3<I.B!W87)N:6YG($,T-3,P

M;G1I8W, 87)E(&YO="!E;F%B;&5D+B!3<&5C:69Y("U'6 T*4#I<4')O9W)A

M($,K*R!E>&-E<'1I;VX :&%N9&QE<B!U<V5D+"!B=70 =6YW:6YD('-E;6%N


M0RLK(&5X8V5P=&EO;B!H86YD;&5R('5S960L(&)U="!U;G=I;F0 <V5M86YT
M:6-S(&%R92!N;W0 96YA8FQE9"X 4W!E8VEF>2 M1U -"E Z7%!R;V=R86US

M.B!U;F1E8VQA<F5D(&ED96YT:69I97(-"E Z7%!R;V=R86US7$U31&5V7&EN


M.EQ0<F]G<F%M<UQ-4T1E=EQI;F-L=61E7'9E8W1O<B R,RDZ(&5R<F]R($,R


M>"!E<G)O<B Z(&UI<W-I;F< )SLG(&)E9F]R92!I9&5N=&EF:65R("=A;&QO
M8V%T;W)?='EP92<-"E Z7%!R;V=R86US7$U31&5V7&EN8VQU9&5<=F5C=&]R

M(&1E8VPM<W!E8VEF:65R<PT*4#I<4')O9W)A;7-<35-$979<:6YC;'5D95QV

M9B G.CHG(&ES('5N9&5F:6YE9 T*4#I<4')O9W)A;7-<35-$979<:6YC;'5D


M-"DZ(&5R<F]R($,R,30V.B!S>6YT87  97)R;W( .B!M:7-S:6YG("<[)R!B
M969O<F4 :61E;G1I9FEE<B G<VEZ95]T>7!E)PT*4#I<4')O9W)A;7-<35-$

M92< .B!M:7-S:6YG(&1E8VPM<W!E8VEF:65R<PT*4#I<4')O9W)A;7-<35-$

M8V5?='EP92< .B!R:6=H="!O9B G.CHG(&ES('5N9&5F:6YE9 T*4#I<4')O

M<WEN=&%X(&5R<F]R(#H
M=EQI;F-L=61E7'9E8W1O<B R-2DZ(&5R<F]R($,R,30V.B!S>6YT87  97)R
M;W( .B!M:7-S:6YG("<[)R!B969O<F4 :61E;G1I9FEE<B G9&EF9F5R96YC
M95]T>7!E)PT*4#I<4')O9W)A;7-<35-$979<:6YC;'5D95QV96-T;W(H,C4I

M8VPM<W!E8VEF:65R<PT*4#I<4')O9W)A;7-<35-$979<:6YC;'5D95QV96-T

M)R!I<R!U;F1E9FEN960-"E Z7%!R;V=R86US7$U31&5V7&EN8VQU9&5<=F5C

M:65R)PT*4#I<4')O9W)A;7-<35-$979<:6YC;'5D95QV96-T;W(H,C8I.B!E

M(&ED96YT:69I97( )U]4<'1R)PT*4#I<4')O9W)A;7-<35-$979<:6YC;'5D


M8W1O<B R-RDZ(&5R<F]R($,R-3$W.B G8V]N<W1?<&]I;G1E<B< .B!R:6=H
M="!O9B G.CHG(&ES('5N9&5F:6YE9 T*4#I<4')O9W)A;7-<35-$979<:6YC


M<B R-RDZ(&5R<F]R($,R,30V.B!S>6YT87  97)R;W( .B!M:7-S:6YG("<[
M)R!B969O<F4 :61E;G1I9FEE<B G7T-T<'1R)PT*4#I<4')O9W)A;7-<35-$

M.B!M:7-S:6YG(&1E8VPM<W!E8VEF:65R<PT*4#I<4')O9W)A;7-<35-$979<

M.B!R:6=H="!O9B G.CHG(&ES('5N9&5F:6YE9 T*4#I<4')O9W)A;7-<35-$

M<F]R(#H
M7'9E8W1O<B R."DZ(&5R<F]R($,R,30V.B!S>6YT87  97)R;W( .B!M:7-S
M:6YG("<[)R!B969O<F4 :61E;G1I9FEE<B G<F5F97)E;F-E)PT*4#I<4')O

M)W)E9F5R96YC92< .B!M:7-S:6YG(&1E8VPM<W!E8VEF:65R<PT*4#I<4')O



M+EPN+EQY87)D7'1E<W1S7'EA<F1?=&5S=%]C:&%R7W-E="YH<' H,S(I.B!W

M('5N=VEN9"!S96UA;G1I8W, 87)E(&YO="!E;F%B;&5D+B!3<&5C:69Y("]%

M;W( 0S(Y-S<Z("=Y87)D.CI-871C:%!A='1E<FXG(#H =&]O(&UA;GD =&5M

M<' H,C,T*3H 97)R;W( 0S(V-C<Z("=Y87)D.CI-871C:%!A='1E<FX\>6%R
M9#HZ4V5N=&5N8V5S+'EA<F1?=&5S=#HZ3W5T<'5T5V]R9'-087)S97(^)R Z
M(&YO;F4 ;V8 ,B!O=F5R;&]A9', :&%V92!A(&)E<W0 8V]N=F5R<VEO; T*

M-C8X.B G>6%R9#HZ36%T8VA0871T97)N)R Z(&%M8FEG=6]U<R!C86QL('1O
M(&]V97)L;V%D960 9G5N8W1I;VX-"BXN7"XN7'EA<F1<=&5S='-<>6%R9%]T

M;B< .B!T;V\ ;6%N>2!T96UP;&%T92!A<F=U;65N=',-"BXN7"XN7'EA<F1<

M.DUA=&-H4&%T=&5R;C\D0%5396YT96YC97- >6%R9$! 53\D4W1D3W5T4W1R

M861S(&AA=F4 82!B97-T(&-O;G9E<G-I;VX-"BXN7"XN7'EA<F1<=&5S='-<

M4&%T=&5R;B< .B!A;6)I9W5O=7, 8V%L;"!T;R!O=F5R;&]A9&5D(&9U;F-T

M7V-H87)?<V5T+FAP<" S,BDZ('=A<FYI;F< 0S0U,S Z($,K*R!E>&-E<'1I
M;VX :&%N9&QE<B!U<V5D+"!B=70 =6YW:6YD('-E;6%N=&EC<R!A<F4 ;F]T
M(&5N86)L960N(%-P96-I9GD +T5(<V,-"E1O;VPZ('9C+S -"BXN7"XN7'EA
M<F1<=&5S='-<>6%R9%]T97-T7V-H87)?<V5T+FAP<" S,BDZ('=A<FYI;F< 
M0S0U,S Z($,K*R!E>&-E<'1I;VX :&%N9&QE<B!U<V5D+"!B=70 =6YW:6YD
K('-E;6%N=&EC<R!A<F4 ;F]T(&5N86)L960N(%-P96-I9GD +T5(<V,-" ``
`
end

"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 

"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
 

"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 

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