Friday, January 12, 2018

Digest for comp.lang.c++@googlegroups.com - 25 updates in 8 topics

Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 12 07:42PM

Some classic (GoF) design patterns are no longer needed in C++.
 
Lambdas wrapped by std::function, for example, can be used instead of
the "command" pattern.
 
It can be argued that these new techniques are still implementing the
idea of the old patterns just not their substance, so knowledge of the
old patterns is still useful information to have.
 
In the case of std::function beware of possible performance penalties
that may arise as the cost of gaining type erasure, penalties that may
be more significant than those present in the classic pattern
implementations.
 
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That's what I would say."
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 12 12:26AM +0100

On 1/11/2018 11:01 PM, James R. Kuyper wrote:
> facilities have their behavior defined in terms of fseek().
 
> C 2011, 7.21.9.2p3: "A binary stream need not meaningfully support fseek
> calls with a whence value of SEEK_END".
 
Shouldn't that be "needs"?
 
 
> Note that this is NOT 'implementation-defined" behavior, so an
> implementation is under no obligation to document whether it
> meaningfully supports SEEK_END.
 
It would be interesting to know the (OS or storage) systems where
`SEEK_END` can't be relied on in practice.
 
I can't quite grok what it's about. For a pipe or tape drive or
non-seekable stream, or generally where the request can't be satisfied,
`fseek` will just return non-zero. So what's that "meaningfully" about?
 
 
Cheers!,
 
- Alf (baffled)
legalize+jeeves@mail.xmission.com (Richard): Jan 11 11:52PM

[Please do not mail me a copy of your followup]
 
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> spake the secret code
 
>I can't quite grok what it's about. For a pipe or tape drive or
>non-seekable stream, or generally where the request can't be satisfied,
>`fseek` will just return non-zero. So what's that "meaningfully" about?
 
I interpret the language to imply that fseek would succeed by
returning 0, but that the consequences of doing so wouldn't be
meaningful. In other words it says "yeah, I did it" but there was no
observable change in reality.
 
For instance, the following program:
 
#include <stdio.h>
 
int main()
{
FILE *f = fopen("/dev/random", "rb");
printf("%ld pos on open\n", ftell(f));
fseek(f, 0, SEEK_END);
printf("%ld pos on seek\n", ftell(f));
fclose(f);
}
 
gives the following output:
 
0 pos on open
0 pos on seek
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jan 12 12:42AM

On Fri, 12 Jan 2018 00:26:47 +0100
> > C 2011, 7.21.9.2p3: "A binary stream need not meaningfully support
> > fseek calls with a whence value of SEEK_END".
 
> Shouldn't that be "needs"?
 
It's a subjunctive.
Geoff <geoff@invalid.invalid>: Jan 11 09:22PM -0800

On Thu, 11 Jan 2018 21:28:22 +0000, Vir Campestris
>> into the allocated buffer.
 
>Seek to end. ftell. Seek to start. Allocate buffer. Read.
 
>You don't need to read the file twice.
 
As stated elsewhere in this topic, the file being sized is a text
file.
 
The fseek/ftell method doesn't yield identical results with text files
on Windows compared to Linux or OSX due to the brain-dead decision to
use <CR><LF> in Windows disk files and this code is intended to be
portable. Windows correctly translates the line endings to <LF> in
memory.
 
The text file is small, currently 125 bytes in memory and 129 bytes on
a Windows platform and will never exceed 1000 bytes. Over-allocation
would not be harmful in this case but I didn't see much benefit in
re-writing something that has been working for decades. The surprise
was the sudden appearance of warnings about the comma usage in this
particular source file. This turned out to be due to an Xcode update
that turns on that warning by default. As I stated, I didn't write
this code, I only maintain it.
 
What's interesting is this is either copy-pasted cargo-cult or the
original author knew about this behavior and wanted identical counts
across platforms. Someone "sophisticated" enough to use the comma
operator syntax would presumably know about fseek/ftell and I have
used it elsewhere in my other projects.
Manfred <noname@invalid.add>: Jan 12 02:11PM +0100

On 1/12/2018 1:42 AM, Chris Vine wrote:
>>> fseek calls with a whence value of SEEK_END".
 
>> Shouldn't that be "needs"?
 
> It's a subjunctive.
 
Are you sure?
"James R. Kuyper" <jameskuyper@verizon.net>: Jan 12 09:54AM -0500

On 01/11/2018 04:28 PM, Vir Campestris wrote:
>> into the allocated buffer.
 
> Seek to end. ftell. Seek to start. Allocate buffer. Read.
 
> You don't need to read the file twice.
 
Correction: I should have noticed that Geoff was referring to a text
file. The situation for text streams is worse than that for binary
streams. The following clause "the new position, measured in characters
from the beginning of the file, is obtained by adding offset to the
position specified by whence." (7.21.9.2p3), applies applies only "For a
binary stream". There is NO corresponding definition for the behavior of
fseek() on a text stream in the section describing fseek(), so it might
seem that the behavior is undefined "by the omission of any explicit
definition of behavior" (4p6).
However, the description of ftell() does say "For a text stream, its
file position indicator contains unspecified information, usable by the
fseek function for returning the file position indicator for the
stream to its position at the time of the ftell call;". Using values not
returned by ftell() does have undefined behavior.
"James R. Kuyper" <jameskuyper@verizon.net>: Jan 12 10:11AM -0500

On 01/11/2018 06:26 PM, Alf P. Steinbach wrote:
 
> I can't quite grok what it's about. For a pipe or tape drive or
> non-seekable stream, or generally where the request can't be satisfied,
> `fseek` will just return non-zero. So what's that "meaningfully" about?
 
There are operating systems that don't keep track of the end of the file
at the byte level, but only at the block level, padding the file with
null characters to the end of the block. This is permitted by 7.21.2p3:
"A binary stream is an ordered sequence of characters that can
transparently record internal data. Data read in from a binary stream
shall compare equal to the data that were earlier written out to that
stream, under the same implementation. Such a stream may, however, have
an implementation-defined number of null characters appended to the end
of the stream."
 
The result of using SEEK_END might take you to the end of the last block
of the file, rather than to the end of what was written to the file.
 
Another example would be certain special readable files under unix, such
as /dev/zero. You can read as many bytes as you want from that file, but
seeking to the end of that file will still leave you at position 0 in
the file.
 
 
On Friday, June 25, 2004 at 5:31:10 PM UTC-4, P.J. Plauger wrote:
> Unix, that paragon of simplicity and elegance, has block-special devices
> that violate this rule. It is a mark of the influence of Unix that you
> can make a statement like this today.
 
See <https://groups.google.com/d/msg/comp.std.c/WGxu-woWcMc/pt5_1j8uIC0J>:
Manfred <noname@invalid.add>: Jan 12 04:42PM +0100

On 1/11/2018 10:28 PM, Vir Campestris wrote:
 
> Seek to end. ftell. Seek to start. Allocate buffer. Read.
 
> You don't need to read the file twice.
 
> Andy
 
An alternative and more robust solution is to read the file sequentially
and dynamically (re)allocate the buffer on the fly, until an end of file
condition is encountered.
This works whenever the file can be just read (not fseek'd/ftell'd), at
the potential cost of higher memory fragmentation.
This may be of some relevance in some scenarios, but IME the
cost/benefit evaluation often favors this second alternative.
 
Another alternative could be stat(), on platforms where it is available
(it's part of POSIX, but not of ISO C).
"James R. Kuyper" <jameskuyper@verizon.net>: Jan 12 11:44AM -0500

For some reason, this is all I see when I view your message:
 
On 01/12/2018 11:23 AM, Stefan Ram wrote:
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jan 12 06:32PM

On Fri, 12 Jan 2018 14:11:30 +0100
 
> >> Shouldn't that be "needs"?
 
> > It's a subjunctive.
 
> Are you sure?
 
God forbid that I be not sure.
Dan Purgert <dan@djph.net>: Jan 12 01:22AM

Richard wrote:
><a8a78ba6-5be7-4c9d-84d9-022af05aa57b@googlegroups.com> thusly:
 
>>Please can you post the details of this setup in comp Lang c?
 
> Is there a moderated newsgroup for C?
 
isn't it comp.lang.c.moderated ?
 
 
--
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281
Thiago Adams <thiago.adams@gmail.com>: Jan 12 03:55AM -0800

On Thursday, January 11, 2018 at 8:57:06 PM UTC-2, Richard wrote:
> <a8a78ba6-5be7-4c9d-84d9-022af05aa57b@googlegroups.com> thusly:
 
> >Please can you post the details of this setup in comp Lang c?
 
> Is there a moderated newsgroup for C?
 
Yes. comp.lang.c.moderated is inactive since 2014.
I think the moderator (Seebs) lost some passwords.
 
Message:
----
 
"
On 2018-01-05, Keith Thompson <ks...@mib.org> wrote:
 
> I've just contacted Seebs by email and gotten a response. There are
> possibilities. I've suggested that he post on this thread, so I'll let
> him speak for himself.
 
Long story short: I had technical issues and/or spoon shortage and was
not keeping up, and basically I forgot that this had been a thing. I do
have working usenet now, but I don't know that the moderation address
is set up. It probably could be, but Everything Is Happening At Once.
 
I'd be fine with handing the moderation off to other people, and if I
get some free time I could set up a thing, or more reasonably, someone
could set up any of the much-more-usable moderation software that
presumably exists these days (I think Jay from rastb5m did a very nice
package for this) somewhere else, and I'd give approval for transferring
control.
 
Sorry about falling down on the thing, Stuff Happened.
 
-s
"
-------
 
More here:
https://groups.google.com/forum/#!topic/comp.lang.c/YyWnAt8Mb1c
"K. Frank" <kfrank29.c@gmail.com>: Jan 12 07:44AM -0800

Hello Richard!
 
On Thursday, January 11, 2018 at 3:56:20 PM UTC-5, Richard wrote:
 
> Just a quick post to update everyone on the status of
> comp.lang.c++.moderated.
> ...
 
Please let me reiterate my willingness to assist with the
moderation if that would help support a vibrant group.
 
 
Best.
 
 
K Frank
legalize+jeeves@mail.xmission.com (Richard): Jan 12 06:07PM

[Please do not mail me a copy of your followup]
 
"K. Frank" <kfrank29.c@gmail.com> spake the secret code
 
>Please let me reiterate my willingness to assist with the
>moderation if that would help support a vibrant group.
 
Great! I've recorded this message. We have some of the old
moderators that will be participating again, but also some of them
have dropped off. The load is lighter as well, so we shouldn't suffer
from lack of moderators, but every little bit helps.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
legalize+jeeves@mail.xmission.com (Richard): Jan 12 06:13PM

[Please do not mail me a copy of your followup]
 
Thiago Adams <thiago.adams@gmail.com> spake the secret code
 
>> Is there a moderated newsgroup for C?
 
>Yes. comp.lang.c.moderated is inactive since 2014.
>I think the moderator (Seebs) lost some passwords.
 
Ah, I see. Well let's get comp.lang.c++.moderated working again and I
can ask Daveed Vandevoorde if he's willing to host the same software
for comp.lang.c.moderated. He was already hosting comp.std.c++ and
comp.lang.c++.moderated when the email<->news gateway was still
working, so the scripts can already handle multiple newsgroups with
distinct moderator sets.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
legalize+jeeves@mail.xmission.com (Richard): Jan 12 06:05PM

[Please do not mail me a copy of your followup]
 
I just added koans for character and string literals, std::string and
std::string_view. Check the README at the link below for details.
 
<https://github.com/LegalizeAdulthood/cpp-koans>
 
Note: the following fail in MSVC:
 
static_assert(std::is_same_v(decltype(u'x'), char16_t>);
static_assert(std::is_same_v(decltype(U'x'), char32_t>);
constexpr std::string_view s{"foo"};
 
Bugs have been filed.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Real Troll <real.troll@trolls.com>: Jan 12 12:50AM -0400

Just wondered if anybody is using Boost Libraries here?
 
<http://www.boost.org/doc/libs/1_66_0/>
 
It is free and open source. the zip file will give you all the source
code and header files. they have NNTP newsgroup on gmain:
 
<news://news.gmane.org/gmane.comp.lib.boost.user>
 
They have other newsgroups as well for development, documentation, etc
etc. so just search for them on GMAIN.
 
GMAIN newsgroups are all moderated so religious posts are not allowed on
it!!
 
The download links for boost libraries is here:
 
<http://www.boost.org/users/history/version_1_66_0.html>
 
One of the contributors was a speaker at CPPCon2017 in this video:
 
<https://www.youtube.com/watch?v=YxmdCxX9dMk&feature=youtu.be>
 
He is Robert Ramey
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 12 10:18AM +0100

On 1/12/2018 5:50 AM, Real Troll wrote:
> Just wondered if anybody is using Boost Libraries here?
 
> <http://www.boost.org/doc/libs/1_66_0/>
 
I don't use Boost, but if I should happen to work for a company again I
would recommend using Boost, in spite of the problem of new versions
obsoleting and sometimes invalidating old code. Because it's the same
problem as with other libraries. One can't not use libraries.
 
One reason that Boost isn't as critical now as with C++03, is that the
core language has acquired smart pointers and threading support. With
C++17 we even got the filesystem library as a standard library sub-library.
 
Still, there are the two calendar libraries (date handling, can be
critical), and bignums, and matrices, and parser generation, and image
handling, and and... Oh yes, interface to Python. That's cool and very
practically useful, and I sort of regret not having tried it out.
 
 
> It is free and open source.  the zip file will give you all the source
> code and header files.  they have NNTP newsgroup on gmain:
 
> <news://news.gmane.org/gmane.comp.lib.boost.user>
 
I thought I remembered from yesteryear or perhaps 2015 that the guys in
Bergen (Norway) who supplied the gmane service, shut it down for good.
 
Checking... Oh!
 
"At the end of July 2016, Gmane briefly closed and was acquired by
Yomura in mid August."
 
 
 
> One of the contributors  was a speaker at CPPCon2017 in this video:
 
> <https://www.youtube.com/watch?v=YxmdCxX9dMk&feature=youtu.be>
 
> He is Robert Ramey
 
There are lots of Boost contributors.
 
 
Cheers!,
 
- Alf
legalize+jeeves@mail.xmission.com (Richard): Jan 12 06:03PM

[Please do not mail me a copy of your followup]
 
I like boost in general and there are some great libraries in there, but
there are also some downsides. It is very intimidating and difficult
for beginners to get going with libraries that require compilation.
The build system is archaic, homebrew, and poorly documented. The size
of the distribution is unwieldy. There needs to be a way to get targeted
subsets of boost so that you don't need to download a huge thing and
figure out how to build/use just what you need.
 
On the plus side, these issues are not unknown to the boost community and
they are (slowly) making progress towards resolving them. They switched
to modular git on github from subversion a while back and they recently
announced that they are officially adopting CMake for the build, although
the distribution hasn't been offficially converted yet. Some of the
slow progress is due to the fact that each library within boost has its
own maintainer and so global changes move at a varied rate.
 
I just switched my C++ Koans repo to use Catch2 as the unit test
library and it was a piece of cake to switch. Catch2 is much easier
for beginners to use than Boost.Test. Catch2 also feels lighter than
Boost.Test even though it appears to have the same, if not more,
features. The same can be said for Catch2 compared to Google Test,
which is the other dominant unit testing framework out there. It
feels like Catch2 is gaining more adherents over time.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
ram@zedat.fu-berlin.de (Stefan Ram): Jan 12 04:23PM

>The result of using SEEK_END might take you to the end of the last block
>of the file, rather than to the end of what was written to the file.
 
Sometimes, a function to count the number of possible calls
to getc might help. I have written - but not tested - such
a function. I have not even checked whether the latest
version compiles at all. But so as to fit under the subject,
the implementation contains a comma operator!
 
/** \brief counts number of possible getc calls
\param result address of a writeable size_t object.
The number of possible getc calls will
be written to this object.
\param input an address of a FILE object for a
readable stream.
\param stop_on_zero whether to interpret a read of a NUL
character (byte with value 0) as EOF.
\return zero to indicate success,
nonzero otherwise ("&2" for read error,
"&4" for overflow).
*/
int getc_count_file
( size_t * const result,
FILE * const input,
int const stop_on_zero )
{ = fopen( path, mode );
size_t size = 0;
int failed = 1;
int error = 0;
int overflow = 0;
if( input )
{ int ch = getc( input );
while( ch != EOF )
{ if( !++size )overflow = 1, ch = EOF;
else ch = getc( input );
if( stop_on_zero && !ch )ch = EOF; }
if( ferror( input ))failed |= 2;
if( overflow )failed |= 4;
failed &= ~1; }
if( !failed )*result = size;
return failed; }
 
I have also written a wrapper that will open the file,
also uncompiled and untested:
 
/** \brief counts number of possible getc calls
\param result address of a writeable size_t object.
The number of possible getc calls will
be written to this object.
\param path address of the file to be opened, like
the first argument to fopen.
\param mode mode of the file to be opened, like
the second argument to fopen, e.g.,
"rb" or "r".
\param stop_on_zero whether to interpret a read of a NUL
character (byte with value 0) as EOF.
\return zero to indicate success,
nonzero otherwise ("&2" for read error,
"&4" for overflow, "&8" for open failure,
"&16" for close failure).
*/
int getc_count_path_mode
( size_t * const result,
char const * const path,
char const * const mode,
int const stop_on_zero )
{ FILE * const f = fopen( path, mode );
if( f )
{ int status = getc_count_file( result, f, stop_on_zero );
if( fclose( input ))status |= 16; }
return status; }
else return 8; }
ram@zedat.fu-berlin.de (Stefan Ram): Jan 12 04:44PM

>bool askSample();
 
#include <iostream>
#include <istream>
#include <limits>
#include <ostream>
 
static bool askSample()
{ while( true )
{ ::std::cout << "Do you want to proceed (y/n) ?\n";
char answer = 0;
std::cin >> answer;
if( 'y' == answer || 'Y' == answer )return true;
if( 'n' == answer || 'N' == answer )return false;
std::cout << "Only 'y' or 'n' please!" << std::endl;
::std::cin.clear();
::std::cin.ignore
( ::std::numeric_limits< ::std::streamsize >::max(), '\n' ); }}
 
int main(){ while( askSample() ); }
ram@zedat.fu-berlin.de (Stefan Ram): Jan 12 04:49PM

>For some reason, this is all I see when I view your message:
 
It seems that you are replying to some message,
but your post does not have a reference header.
 
Sometimes, newsreaders display only parts of a
message when the message contains special
characters such as ^L. But as far as I am aware
of, my post does not contain such special characters.
arnuld <sunrise@invalid.address>: Jan 12 04:14AM

I have been out of coding for few years and out of C++ for more than few.
I hope few of you remembered me :) . Wanted to get back to the
fundamentals of good C++ practices. Here is a bit modified program from
section 2.3.2 of Stroustrup's 3/e of book The C++ Programming Language.
It works fine, any advice will be appreciated:
 
 
 
#include <iostream>
 
bool askSample();
 
 
int main()
{
while(askSample())
;

return 0;
}
 
 
bool askSample()
{
std::cout << "Do you want to prceed (y/n) ? " << std::endl;
char answer = 0;
std::cin >> answer;
 
if('y' == answer)
return true;
else if('n' == answer)
return false;
else
{
std::cout << "Only 'y' or 'n' please" << std::endl;
return true;
}
}
======================= OUTPUT ==============================
[arnuld@arch64 programs]$ g++ -std=c++17 -pedantic -Wall -Wextra 232.cpp
[arnuld@arch64 programs]$ ./a.out
Do you want to prceed (y/n) ?
y
Do you want to prceed (y/n) ?
p
Only 'y' or 'n' please
Do you want to prceed (y/n) ?
n
[arnuld@arch64 programs]$
 
 
 
--
-- arnuld
http://lispmachine.wordpress.com/
Alexander Huszagh <ahuszagh@gmail.com>: Jan 11 03:45PM -0800

> This post showing much we want Rick C hodgin to leave this group. If you want him to leave. Leave you name in reply. thanks
 
+1.
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)