Thursday, September 10, 2020

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

olcott <NoOne@NoWhere.com>: Sep 10 10:05AM -0500

On 9/10/2020 2:38 AM, Juha Nieminen wrote:
> useful in everyday coding, which allow you to do with one-liners things that
> in C would require hundreds or even thousands of lines of code (especially
> if you want the same efficiency).
 
Also this library is so well written and designed that you can learn one
thing like std::vector in a few minutes and at the same time learn that
common interface to other library functions. You can learn this one
thing like std::vector without have to know anything else about the rest
of the library.
 
> In most cases you don't have to worry about it at all, nor write *any*
> code to take care of freeing all these hundreds or thousands of allocated
> memory blocks.
 
Hence my encouragement to use those two featuress.
 
> sub-objects, *all* of the other dynamic data containers within, all
> the way down, are automatically destroyed. In most cases you don't need
> to write a single line of code for this to happen.
 
I love this aspect. And no garbage collection cycles.
 
 
> In other words, not only are you not giving up any features by moving
> to C++ (other than VLAs), you also are not giving up any efficiency
> by doing so.
 
The reason that I loved C in the first place is that it was a much
easier way to write assembly language code. When you add just the three
things that I mentioned: classes, std::vector, std::string your C
programs become 500% more maintainable. The object oriented paradigm
reduces complexity by a whole other level. Now you have code and its
data packaged together.
--
Copyright 2020 Pete Olcott
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Sep 10 09:03PM +0100

On Thu, 10 Sep 2020 07:38:05 +0000 (UTC)
> efficient and/or simple to do in C, you can also do it in the exact same
> way in C++. Also note that you don't need to compromise anything by
> moving from C to C++.
[snip]
> (Perhaps the only thing that you would be giving up are VLAs, but good
> arguments can be made, even in C, why they shouldn't be used. This is one
> of the few things where Linus Torvalds is actually right.)
 
Really? The first two examples below for constructing objects in
dynamically allocated memory or iterating pointers are wholly idiomatic
C, which most C programmers would regard as nice, useful and handy, but
give undefined behaviour in C++, and so probably ought to cause the
person you have encouraged to use C++ to lose their annual bonus (in
C++ the first requires placement new, and the second is only resolvable
in C++ by allocating the memory as an array of char using the new[]
expression and then incrementing by char* not int* (which leads to the
third point below, requiring std::launder):
 
int* i = (int*) malloc(sizeof(int));
*i = 0;
 
int* i = (int*) malloc(2 * (sizeof int));
i++;
 
Or a C programmer who knows that at some address held in a pointer
to char named 'ptr' there resides an int can safely write this in full
compliance with the strict aliasing rules:
 
int* i = (int*) ptr;
i* = 2;
 
In C++ this is undefined behaviour in any case where 'ptr' and 'i' are
not pointer-interconvertible unless you use std::launder.
 
Another example recently mentioned in this newsgroup which comes to mind
is type punning, where the C programmer will instinctively reach for a
union (which is permitted in C++ as an extension by gcc and clang but
not I believe by MSVC and is claimed by Stroustrup and others to have
undefined behaviour in standard C++).
 
I think your approach would be quite misleading. The languages are
now different at the most basic levels.
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Sep 10 01:08PM -0700

> is more like an instruction to the compiler that tells it "give me
> an error message at compile time if I ever try to assign something
> to this", but otherwise it's pretty much a "normal" variable.
 
In C, "const" doesn't mean "constant". It means read-only.
 
`sz` is not a constant expression. `char vs[sz];` is a valid
declaration if and only if VLAs are supported (not supported in C90,
supported in C99, optional in C11).
 
If VLAs are supported a compiler can generate exactly the same code for
this that it would generate for `char vs[100];`. (I might be able to
create a highly contrived case where the behavior *might* be different
based on the poorly worded rule about evaluating the operand of sizeof.)
 
> So I'm wondering what the C standard says about the above construct.
> Is the compiler allowed to assume that 'sz' is a compile-time constant
> and, thus, make 'vs' into a "regular" array (rather than a VLA)?
 
`sz` is a VLA. For (almost) all purposes, this doesn't make any visible
difference for a compiler that supports VLAs. For a compiler that
doesn't support VLAs (e.g., a conforming C11 compiler that predefines
__STDC_NO_VLA__), the declaration is a constraint violation and a
diagnostic is required.
 
> something along the lines of "modifying a variable declared as const
> is UB", which essentially tells the compiler "you can assume its
> value is what you see, it won't ever change".)
 
Yes.
 
(In C++, the rules for constant expressions cause `sz` to be
a constant expression, so `char vs[sz];` defines an ordinary
non-VLAs array. As I understand it, this is something of a special
case; `const` still means read-only in most cases. For example,
`const int r = rand();` is valid in both C and C++ and does not make
`r` a constant expression. I personally would have preferred if C++
had not introduced this special case, and instead used `constexpr`
for this purpose -- but `constexpr` wasn't introduced until after
the rule was added. I would have advocated spelling "const" as
"readonly" if not for the fact that it would have broken existing
code.)
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
olcott <NoOne@NoWhere.com>: Sep 10 03:35PM -0500

On 9/10/2020 3:03 PM, Chris Vine wrote:
>> of the few things where Linus Torvalds is actually right.)
 
> Really? The first two examples below for constructing objects in
> dynamically allocated memory or iterating pointers are wholly idiomatic
 
Can be bypassed by constructing the object directly within a
std::vector.push_back(INVOKE CONSTRUCTOR HERE) and using std::vector
array subscript interface to iterate over the objects in the vector.
 
 
--
Copyright 2020 Pete Olcott
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Sep 10 09:50PM +0100

On Thu, 10 Sep 2020 15:35:59 -0500
 
> Can be bypassed by constructing the object directly within a
> std::vector.push_back(INVOKE CONSTRUCTOR HERE) and using std::vector
> array subscript interface to iterate over the objects in the vector.
 
C++'s facilties for using and managing dynamically allocated memory are
indeed superior to C's, but I wasn't commenting on that. I was
commenting on the fact that the appeal to C programmers in these terms
is false:
 
"For starters, note that by using C++ you aren't giving up on anything
that you find nice, useful and handy in C. If something is, for
example, very efficient and/or simple to do in C, you can also do it
in the exact same way in C++".
 
You can do the things I mentioned in a different way in C++, but not in
"the exact same way", nor even in inexactly the same way. More
strickingly, allocating objects in dynamically allocated memory is
ubiquitous in both C and C++, but the only way to do so in C gives rise
to undefined behaviour in C++, even if the objects are C-like
(so-called trivial objects).
boltar@nuttyella.co.uk: Sep 10 02:36PM

On Thu, 10 Sep 2020 14:08:02 +0200
>implicitly copyrighted by you, unless there is some prior claim or
>explicit transfer of copyrights. It is certainly not "public domain"
>unless you say so explicitly.
 
If all usenet posts were copyright to their author then including those posts
in further posts would be technically illegal withoug getting permission
from the author first. Though it probably varies by country. It would be same
as claiming a telephone conversation was copyright.
olcott <NoOne@NoWhere.com>: Sep 10 09:50AM -0500

On 9/10/2020 1:54 AM, David Brown wrote:
> doubt that the C++ language is big, and few if any programmers have need
> for all the features. But the subset that gives the most benefits
> varies enormously from programmer to programmer and task to task.
 
C with classes is very much better than C without classes (if done
properly) and because it provides such a great benefit at such a low
learning curve cost could get many C programmers to start C++.
 
--
Copyright 2020 Pete Olcott
Bonita Montero <Bonita.Montero@gmail.com>: Sep 10 04:50PM +0200

> A "c" by itself looks like it may be a typo.
 
From here I thought this threads ends in pure idiocracy.
As I read the first follow-ups I got the confirmation.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Sep 10 04:01PM +0100


> So the real question is, why bother putting a copyright message on the
> post when it is already covered automatically?
 
It's just one of the things such people do. What they write is so Very
Important that it needs to be marked as special in some way. It's been
that way since before the Internet boom. I refer you to "What To Do
When the Trisector Comes" by Underwood Dudley.
 
--
Ben.
Lew Pitcher <lew.pitcher@digitalfreehold.ca>: Sep 10 03:31PM

On Thu, 10 Sep 2020 16:01:08 +0100, Ben Bacarisse wrote:
 
> "What To Do When the Trisector Comes" by Underwood Dudley
 
What a wonderful essay; I loved it.
 
 
Thanks, Ben.
--
Lew Pitcher
"In Skills, We Trust"
olcott <NoOne@NoWhere.com>: Sep 10 10:42AM -0500

>> contains it.
 
> Wrong. All usenet providers will have a public domain clause in their terms
> and conditions because thats how usenet has worked since its inception.
 
Because much of what I say is brand new material that no one has ever
said before my copyright notice establishes first use.
 
--
Copyright 2020 Pete Olcott
olcott <NoOne@NoWhere.com>: Sep 10 10:53AM -0500

>> contains it.
 
> Wrong. All usenet providers will have a public domain clause in their terms
> and conditions because thats how usenet has worked since its inception.
 
This doesn't seem to be true and if it was true it doesn't seem to be
legal. It would seem that for it to be legal I would had to have been
notified and agree.
 
 
--
Copyright 2020 Pete Olcott
Bonita Montero <Bonita.Montero@gmail.com>: Sep 10 06:11PM +0200

Am 10.09.2020 um 11:59 schrieb Anton Shepelev:
 
> () ascii ribbon campaign - against html e-mail
> /\http://preview.tinyurl.com/qcy6mjc [archived]
 
www.asciiribbon.org is an example of how ugly even rudimentary HTML
could look like. Now imagine this would be ASCII. This is why I prefer
HTML in certain E-Mail-types like newsletters; it's just magnitutes
more convenient to read.
Anton Shepelev <anton.txt@g{oogle}mail.com>: Sep 10 08:23PM +0300

boltar:
 
> including those posts in further posts would be
> technically illegal withoug getting permission from the
> author first.
 
Since anything posted to Usenet becomes available to
everybody to free, copying a post with a proper attribution
cannot violate the author's copyright. You cannot make the
content any more available than it already is, contrary to
books, movies, music, or any digital content that is not
made universally available by its author.
 
--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
olcott <NoOne@NoWhere.com>: Sep 10 12:27PM -0500

On 9/10/2020 12:23 PM, Anton Shepelev wrote:
 
> Since anything posted to Usenet becomes available to
> everybody to free, copying a post with a proper attribution
> cannot violate the author's copyright.
 
I do this so that my original work will have proper attribution.
 
 
--
Copyright 2020 Pete Olcott
David Brown <david.brown@hesbynett.no>: Sep 10 07:32PM +0200

> in further posts would be technically illegal withoug getting permission
> from the author first. Though it probably varies by country. It would be same
> as claiming a telephone conversation was copyright.
 
As has been noted by others, by posting on Usenet you can be assumed
implicitly to be granting certain rights of usage of the post. (This is
in addition to standard "fair use" of copyrighted material, which
includes allowing quotations for various purposes.) That includes
copying the post between newsservers, making it available publicly,
including in archives, and allowing other posters the right to quote the
post when replying according to common Usenet conventions. I don't know
of any place that these might be found written down, except perhaps if
they are discussed in an RFC on Usenet.
 
This is all getting way off-topic in these groups. I suggest you look
it up if you are interested - it should not be hard to find references.
Juha Nieminen <nospam@thanks.invalid>: Sep 10 06:59PM

> It is certainly not "public domain" unless you say so explicitly.
 
It's not "public domain" even if you say so. Most jurisdictions
do not recognize it as a valid form of publication. You have
copyright to your work whether you want it or not.
Juha Nieminen <nospam@thanks.invalid>: Sep 10 07:01PM

> If all usenet posts were copyright to their author then including those posts
> in further posts would be technically illegal withoug getting permission
> from the author first.
 
No, because fair use statutes step in.
Kaz Kylheku <793-849-0957@kylheku.com>: Sep 10 07:02PM

>>Copyright 2020 Pete Olcott
 
> Why do you put a copyright in your posts? Firstly they're not
> copyrightable as usenet is in the public domain and secondly who do
 
That is simply not true. The exact laws vary from country to country,
but there is no general principle by which an expressive work passes
automatically into the public domain, even if it is broadcast by the
author.
 
Even a statement like "this work is assigned into the public domain" is
not necessarily valid, and if the work carries no other statement, then
it might not be considered properly licensed for anyone to redistribute.
 
Peter Olcott's copyright header is in fact valid.
 
> you think is going to rip off your tedious waffle anyway?
 
Agreed.
David Brown <david.brown@hesbynett.no>: Sep 10 10:49PM +0200

On 10/09/2020 20:59, Juha Nieminen wrote:
 
> It's not "public domain" even if you say so. Most jurisdictions
> do not recognize it as a valid form of publication. You have
> copyright to your work whether you want it or not.
 
That varies from place to place. In some countries, stating that the
post is in public domain is enough (assuming you owned the copyright to
start with) - in others, "public domain" is only possible when the
copyright time has run out. I don't know which viewpoint is held by
"most" countries. In any country following the Berne Convention - which
is most of them - any creative work is automatically copyrighted by the
author or by whoever paid the author to make the work. So my point was
primarily that things you write are not public domain if you have not
said so explicitly - but you are absolutely right that sometimes they
won't be public domain even if you /do/ say they are.
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Sep 10 12:57PM -0700

>> //---------------------------------------------------
 
> It is not clear if you want a compile-time error with a too large
> value or a too large type.
 
Yes, it is clear from the example quoted above:
 
std::uint64_t value = 5;
func(value); // static_assert triggers
 
[...]
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
olcott <NoOne@NoWhere.com>: Sep 10 02:13PM -0500

On 9/10/2020 2:03 PM, David Kleinecke wrote:
 
> We should update the paradox. Almost nobody is shaved by a barber
> these days. I suggest changing to cutting hair.
 
> The barber cuts the hair of every one who does not cut their own hair.
 
The barber paradox and its Russell's paradox equivalent are simply
incoherent and nothing more. The only reason that they are interesting
is that they point to an inherent flaw in the understanding of these
things.
 
All paradoxes including all undecidable decision problems (such as
Tarski and Gödel) really only point out that human understanding of
these things is flawed.
 
--
Copyright 2020 Pete Olcott
Tim Rentsch <tr.17687@z991.linuxsc.com>: Sep 10 07:29AM -0700

> actually allocated for each bitfield, or the order in which consecutive
> bitfields are stored in the struct. It probably doesn't even mandate that
> the bits in one bitfield must be in consecutive bytes.
 
Your understanding would be better informed if you would
read what the C and C++ standards actually say before
making assertions about what they do or do not require.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Sep 10 07:30AM -0700


> [citation from C++ standard]
 
> That's not enough specification to be of much use, but it's (barely)
> enough to refute the claim that the standard impose no requirements.
 
In mathematics being barely right is the same as being right.
James Kuyper <jameskuyper@alumni.caltech.edu>: Sep 10 07:52AM -0700

On Thursday, September 10, 2020 at 10:31:10 AM UTC-4, Tim Rentsch wrote:
 
> > That's not enough specification to be of much use, but it's (barely)
> > enough to refute the claim that the standard impose no requirements.
 
> In mathematics being barely right is the same as being right.
 
That's why I parenthesized "barely". As a practical matter, the fact
that the specification is almost useless renders the fact that it does
actually exist relatively unimportant.
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)