Friday, February 16, 2018

Digest for comp.lang.c++@googlegroups.com - 18 updates in 4 topics

Daniel <danielaparker@gmail.com>: Feb 16 09:12AM -0800

On Thursday, February 15, 2018 at 1:46:10 AM UTC-5, Alf P. Steinbach wrote:
> hey, conversion to string can throw, and therefore conversion from char
> const* would have been explicit if designed today.
 
> I think it's all bollocks.
 
Thanks Alf, I thought there must have been a technical safety reason, but
from that thread it appears not. I share your sentiments.
 
Daniel
Robert Wessel <robertwessel2@yahoo.com>: Feb 15 05:35PM -0600

On Thu, 15 Feb 2018 21:24:22 +0000, Vir Campestris
>> any attention to binary mode, so that's not an option.
 
>It's the 1980s since I last used a system with files that are sequences
>of records - and I didn't run 'C' on them.
 
 
I did it a couple of hours ago - I had a C program read a stream
attached to a record oriented file (it happened to be a member in a
PDS, but it could have been an ordinary sequential file) containing
text (under zOS).
 
 
>I suspect that writing a newline in text, then reading back in binary,
>would give you nothing at all. But I'm not sure.
 
 
Typically that's correct on zOS. "Straight" binary mode on a record
oriented file just treats the records as a stream of bytes without
delimiters. Text files, especially on files with variable length
records, usually don't store the \n in the record. There are, of
course, extensions for seeing the higher level structures.
 
 
 
>And it's implicit in the design of record-based filesystems that you
>don't read a byte, or a char, or any such thing - you read a record.
 
>Then process that.
 
 
Yes, but it's often useful to have a mapping, even if it doesn't cover
all cases. For example, being able to read a text file with some
configuration data that was prepared by the "normal" text editor on
the system. But you can't get too carried away in expecting that
it'll behave exactly like a *nix stream-of-bytes.
Robert Wessel <robertwessel2@yahoo.com>: Feb 15 05:47PM -0600

> perror("something wrong");
> return 1;
>}
 
 
Doing this with a *nix style pipe has even more portability issues
than the other solutions. The above, for example, won't work for a
normal Windows application (it should in the Posix subsystem). There
is a _pipe() which is similar, but not identical, though.
red floyd <dont.bother@its.invalid>: Feb 15 04:34PM -0800

On 2/15/2018 1:24 PM, Vir Campestris wrote:
 
> It's the 1980s since I last used a system with files that are sequences
> of records - and I didn't run 'C' on them.
 
Today. HPE NonStop (the old Tandem computers)
James Kuyper <jameskuyper@verizon.net>: Feb 15 09:47PM -0500

On 02/15/2018 04:24 PM, Vir Campestris wrote:
...
> would give you nothing at all. But I'm not sure.
 
> It's kind of implicit in the design of C I/O that files are _not_
> sequences of records (let alone clever things like ISAM and HRAM files!).
 
Actually, it's not. There's several clauses in the C standard that exist
for the sole purpose of allowing such things. For instance, binary
streams are allowed to have an implementation-defined number of null
characters appended to the end of the stream, which can be used to pad
the file to a multiple of the relevant record length.
James Kuyper <jameskuyper@verizon.net>: Feb 15 10:37PM -0500

On 02/15/2018 06:19 PM, Robert Wessel wrote:
> effect, namely writing in text mode to a stringstream, and then
> reading from the resulting buffer with a stringstream in binary mode,
> was not something that is (I think) specified to work.
 
The meaning for std::binary is defined by table 132 in 27.9.1.4p2 for
basic_filebuf::open(). std::stringstream uses basis_stringbuf(), which
has no such member function, and correspondingly, nothing comparable to
table 132. I don't think it's correct to say that std::binary won't work
for std::stringstream - but rather that it has no effect. Since
std::stringstream never converts between the in-memory and external
representations, it doesn't matter whether or not it's in binary mode.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 16 09:45AM +0100

On 15.02.2018 19:53, Richard wrote:
 
> // ...
 
> constexpr auto newline = is_windows ? "\r\n"sv : "\n"sv;
> }
 
That worked with both g++ and MSVC.
 
Strange.
 
 
Cheers!, & thanks
 
- Alf
jak <please@nospam.ty>: Feb 16 11:05AM +0100

Il 16/02/2018 00:47, Robert Wessel ha scritto:
> than the other solutions. The above, for example, won't work for a
> normal Windows application (it should in the Posix subsystem). There
> is a _pipe() which is similar, but not identical, though.
 
HI,
I tried the program in both systems just adding this line of code under win:
 
#define pipe(fdp) _pipe(fdp, 4096, O_BINARY)
jak <please@nospam.ty>: Feb 16 11:30AM +0100

Il 15/02/2018 21:07, James Kuyper ha scritto:
> On 02/15/2018 01:55 PM, jak wrote:
>> Il 15/02/2018 18:34, James Kuyper ha scritto:
> ...
...
> printing at least one uninitialized value. For character types, that's
> safe, but in general that's something to be avoided. I'll ignore the
> uninitialized values in my discussion below.
 
This does not matter to me when I do tests. I do not think it's bad to
see all 3 bytes I'm not confused by these little things :)
 
 
> 2. End of line is indicated by "\n\r".
> In text mode, fgets() would read both the '\n' and the '\r', but would
...> 3. End of line is indicated by "\r\n".
...
 
You look a little confused. Is the end of line "\r\n" or "\n\r"? On my
systems it is "\r\n", for that the program works. You insist but I also
said I should not use the fgets.
 
> in a new-line character from a text file. It would, however, reach the
> limit of 3 characters that you gave fgets(), so it would insert a
> terminating '\0' in str[2], without having read in the entire line.
 
A file like this can not be called a TEXT file.
 
Paavo Helde <myfirstname@osa.pri.ee>: Feb 16 01:43PM +0200

On 16.02.2018 12:05, jak wrote:
> I tried the program in both systems just adding this line of code under
> win:
 
> #define pipe(fdp) _pipe(fdp, 4096, O_BINARY)
 
You say you tried, but what was the result? In my test it worked
incorrectly in Windows and produced "1: 0x0A" regardless of whether I
used _O_BINARY or _O_TEXT in the #define (note that O_BINARY is a
"non-standard" alias, the official name is _O_BINARY).
jak <please@nospam.ty>: Feb 16 03:19PM +0100

Il 16/02/2018 12:43, Paavo Helde ha scritto:
> incorrectly in Windows and produced "1: 0x0A" regardless of whether I
> used _O_BINARY or _O_TEXT in the #define (note that O_BINARY is a
> "non-standard" alias, the official name is _O_BINARY).
 
Sorry, you're right. I did not copy the line of code from the source but
I wrote it on the fly and forgot the initial underscore. What you tell
me is interesting. Can I ask you in which environment did you try?
(operating system, compiler, msys / msys2, other ...)
"James R. Kuyper" <jameskuyper@verizon.net>: Feb 16 09:24AM -0500

On 02/16/2018 05:30 AM, jak wrote:
>> uninitialized values in my discussion below.
 
> This does not matter to me when I do tests. I do not think it's bad to
> see all 3 bytes I'm not confused by these little things :)
 
In the general case, using an uninitialized value can have undefined
behavior (as a practical matter, this is mainly an issue with pointers
and floating point values).
 
> ...> 3. End of line is indicated by "\r\n".
> ...
 
> You look a little confused. Is the end of line "\r\n" or "\n\r"?
 
I thought I was quite clear that each case describes a system with a
different method for marking the end of a line. Each of these methods is
in use by actual systems.
 
It's "\n" in case 1, "\r\n" in case 2, and "\n\r" in case 3, "\r" in
case 4, and is represented in a more complicated fashion in case 5.
These are among the most common ways of marking the end of a line, but
they are far from being the only ones.
 
>> limit of 3 characters that you gave fgets(), so it would insert a
>> terminating '\0' in str[2], without having read in the entire line.
 
> A file like this can not be called a TEXT file.
 
Perhaps you would not call it a text file, but the users of such systems
have that format as a permitted format for text files (and on some of
them, it's the only permitted format). They do refer to files in that
format as "text files". Code written for such systems to work with text
data will allow (and may require) such data to be in that format.
 
More to the point, the C standard's wording about how end of line is
represented is deliberately vague enough to permit an implementation of
C to use that format when a file is opened in text mode. C++ inherits
that feature, since it incorporates the relevant wording from the C
standard by reference.
Paavo Helde <myfirstname@osa.pri.ee>: Feb 16 05:58PM +0200

On 16.02.2018 16:19, jak wrote:
> I wrote it on the fly and forgot the initial underscore. What you tell
> me is interesting. Can I ask you in which environment did you try?
> (operating system, compiler, msys / msys2, other ...)
 
Windows 7 Enterprise, SP1, Visual C++ 2017, x64.
jak <please@nospam.ty>: Feb 16 05:06PM +0100

Il 16/02/2018 15:24, James R. Kuyper ha scritto:
> C to use that format when a file is opened in text mode. C++ inherits
> that feature, since it incorporates the relevant wording from the C
> standard by reference.
 
this in my area is called "climbing on the mirrors"
"James R. Kuyper" <jameskuyper@verizon.net>: Feb 16 11:57AM -0500

On 02/16/2018 11:06 AM, jak wrote:
> Il 16/02/2018 15:24, James R. Kuyper ha scritto:
>> On 02/16/2018 05:30 AM, jak wrote:
>>> Il 15/02/2018 21:07, James Kuyper ha scritto:
...
>>> ... On my
>>> systems it is "\r\n", for that the program works. You insist but I also
>>> said I should not use the fgets.
 
Sorry - I should have responded to that paragraph in my previous message.
 
wij@totalbb.net.tw asked for a way to determine the method by which a
line ending is indicated. That goal implies a desire to have code that
works on systems with a wide variety of ways of indicating a line
ending. If you only care about whether it gives the right result on
systems where the line ending is "\r\n", you have no need to write such
complicated code. The following minor modification to his original
(unworkable) code would be sufficient:
 
const char newline[] = "\r\n";
 
>> that feature, since it incorporates the relevant wording from the C
>> standard by reference.
 
> this in my area is called "climbing on the mirrors"
 
I've never heard that phrase before. A google search located a
discussion of how to translate the Italian idiom "arrampicarsi sugli
specchi", which literally means "climbing on mirrors", but whose actual
meaning was quite different. Several of the other hits I got were
English text, poorly written by people with Italian names, supporting
the idea that it's an Italian idiom poorly translated into English.
 
The discussion I located involved one person who normally translated
that phrase as "clutching at straws", and another who said that "Since
the Italian has a double meaning here which is lost in English I think
you need more than just climbing on mirrors. The other meaning of
arrampicarsi sugli specchi is, trying to justify your existence, save
your skin."
 
I don't see any particular connection between that idiom and this issue.
It's a very real fact that there have been (and may still be) systems
which used such methods to indicate the end of a line, and that there
were C implementations for such systems which recognized those methods
as such, and that there is wording in the C standard which was
deliberately inserted there to allow such implementations to qualify as
fully conforming. If you want to dismiss such facts as "climbing on the
mirrors", feel free to do so. It's unfortunately not the weirdest reason
I've seen people give for ignoring facts ("no reason at all" is one of
the most popular).
"James R. Kuyper" <jameskuyper@verizon.net>: Feb 16 09:25AM -0500

On 02/13/2018 11:49 AM, Paavo Helde wrote:
...
> And should we not prefer anonymous namespace to static in C++?
 
I knew that term didn't sound right, and I couldn't find it when I
searched the standard. That's because the standard uses the term
"unnamed namespace".
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 16 03:48PM +0100

On 16.02.2018 15:25, James R. Kuyper wrote:
 
> I knew that term didn't sound right, and I couldn't find it when I
> searched the standard. That's because the standard uses the term
> "unnamed namespace".
 
Let's compromise and call it "nameless".
 
Cheers!,
 
- Alf
Egor <egor@ruby.local>: Feb 16 02:57AM +0200

didn't we already have precompiled headers
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)