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

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

"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