Friday, August 9, 2019

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

Bonita Montero <Bonita.Montero@gmail.com>: Aug 09 07:18PM +0200

>> is to be MSVC-compatible here.
 
> Being able to define such a layout doesn't necessarily mean that
> unaligned accesses are supported by hardware.
 
Ok, you're soooo right.
#pragma pack is supported without making sense.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 09 09:35PM +0200

And the gcc-documentation says to its #pragma pack directive:
"For compatibility with Microsoft Windows compilers, GCC supports a
set of #pragma directives that change the maximum alignment of members
of structures (other than zero-width bit-fields), unions, and classes
subsequently defined. The n value below always is required to be a
small power of two and specifies the new alignment in bytes."
I think the guarantees gcc makes here are only for the gererated code
and not, that the code might really run on all platforms because some
of the target-platforms might not emulate unaligned operations through
trapping. But on target-platforms where the CPU allows unaligned oper-
ations this a clear guarantee that it will work.
Bart <bc@freeuk.com>: Aug 09 11:28PM +0100

On 09/08/2019 18:18, Bonita Montero wrote:
>> unaligned accesses are supported by hardware.
 
> Ok, you're soooo right.
> #pragma pack is supported without making sense.
 
I'm saying one needn't have anything to do with the other.
 
For example, take this struct:
 
struct {char a,b,c,d;}
 
where char is 8 bits. What happens when you run this on a machine which
only has 32-bit word-addressable memory?
 
Structs may need to have layouts matching external files or streams or
hardware or languages. That could include:
 
#pragma pack(1)
struct {char a; int b;}
 
on a machine that doesn't support unaligned accesses in hardware.
 
And after all, C also allows this:
 
int *p = f();
 
f (in code not visible from the call-site) returns this:
 
(void*)0x12345; // ie. non-aligned pointer
 
The compiler might assume that p points to an aligned address. If the
hardware doesn't support unaligned, what would happen when *p is evaluated?
Ian Collins <ian-news@hotmail.com>: Aug 10 09:43AM +1200

On 10/08/2019 02:36, Scott Lurndal wrote:
 
> That paper has never been convincing to me, nor anyone that I've
> ever worked with, nor any unix or linux os or other large sourcebase
> that I've worked on professionally.
 
It convinced me long ago... Recursive Make makes distributed building
much harder. My current project code base is modest (about 3,000 source
files in multiple libraries) but we only have one "makefile". It isn't
actually a makefile, we use premake to to generate a ninja build file.
 
--
Ian.
silidrone@gmail.com: Aug 09 09:56AM -0700

> I saw a post with a code exactly the same as this (http://coliru.stacked-crooked.com/a/ac8e130d355d8f1e) one, and it said the output is "12 11" in the post. Now, that is the output I get when I run the code, but I don't see how there can be a specified output when C has no evaluation order of function parameters, am I missing something?
 
The code posted directly here:
#include <stdio.h>
 
int x = 11;
 
int increment(){
x += 1;
return x;
}
 
int main(){
printf("%d %d", increment(), x);
return 0;
}
silidrone@gmail.com: Aug 09 09:59AM -0700

On Friday, August 9, 2019 at 7:54:26 PM UTC+3, Kenny McCormack wrote:
> flag burning laws, more abortion laws, more drug laws, more obscenity
> laws, and more police authority to make warrantless arrests to remind
> us that we need to "get the government off our backs".
 
Im not sure how to edit the post, I replied to it with the code, but it seems only to be viewable for me, not for other users. So, how do I edit the post?
 
I'll just put the code here as well:
#include <stdio.h>
 
int x = 11;
 
int increment(){
x += 1;
return x;
}
 
int main(){
printf("%d %d", increment(), x);
return 0;
}
James Kuyper <jameskuyper@alumni.caltech.edu>: Aug 09 10:24AM -0700

It's an odd choice to post a question about C to a newsgroup devoted to
C++; comp.lang.c would have been more appropriate. However, except for
one minor detail, this code is valid and has the same behavior in both
languages, and the issue you're talking about applies the same in both.
 
The detail is that the output from this program does not end in a new
line character. It's implementation-defined whether such a character is
required. Add a \n at the end of the format string and that issue
disappears.
 
You are correct - the relevant standard for either language explicitly
says that the order of evaluation of the arguments of a function call
is unspecified, so the output of that program is not guaranteed to be
12 11.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 09 07:27PM +0200

Yes, x might be read before or after the call of increment.
But that's not a real problem because no one writes such
brain-damaged code.
James Kuyper <jameskuyper@alumni.caltech.edu>: Aug 09 11:22AM -0700

You'd be surprised - many people learn C after getting preconceptions they acquired when learning other languages. Many people like you pay more attention to the way a particular C compiler works than they do to the actual standard.
For both those reasons, and many others, people often acquire the misconception that the order in which arguments to a function call are evaluated is guaranteed. Once they've done so, it's only natural that sooner or later they will write code that depends upon the expected order.
I've seen people complain in this very newsgroup about a compiler supposedly mishandling code like printf("%d %d\n", x+×, x++), which really isn't possible, because the behavior of such code is undefined (not merely unspecified).
gazelle@shell.xmission.com (Kenny McCormack): Aug 09 07:35PM

In article <1b2121ee-8668-4901-b4fd-eddf6a6c9252@googlegroups.com>,
<silidrone@gmail.com> wrote:
...
> printf("%d %d", increment(), x);
> return 0;
>}
 
Thank you. That helps a lot.
 
Anyway, the answer to your question is that, yes, the C language, as
defined by the standards documents (that which, leader Keith will tell you,
is the only thing we can discuss in this group), does not specify the order
of evaluation of function args. In fact, I think the above program
qualifies as the dreaded "undefined behavior", and we all know what that
means (*).
 
That said, the fact is that most Unix implementations of C (and, in fact,
most implementations of C period) use what is called the "cdecl" calling
convention, which means that things are pushed onto the "stack" (oooh!!! I
said the naughty word!!!) in right-to-left order, so that you get the
output you see. The original value of x is pushed first, then the
incremented value. The incremented value is printed first, followed by the
original value.
 
But, as noted, since it is "undefined behavior", anything could happen,
including spaghetti flying out of your nose. If, however, your
implementation specifies "cdecl", as many/most/all do, then you're safe.
 
Windows, incidentally, is "cdecl" for non-API functions, but "Pascal" for
WinAPI calls.
 
(*) In fact, a true pedant would point out that the fact that there is no
trailing newline in the printf() statement also generates "undefined behavior".
 
--
The last time a Republican cared about you, you were a fetus.
Keith Thompson <kst-u@mib.org>: Aug 09 02:02PM -0700

silidrone@gmail.com writes:
[...]
> Im not sure how to edit the post, I replied to it with the code, but
> it seems only to be viewable for me, not for other users. So, how do I
> edit the post?
 
You can't edit a post. Once you post something on Usenet, it's out
there. (There are mechanisms to cancel posts, but for historical
reasons they usually don't work.)
 
If you want to correct something, post a followup -- which you already
did, and I was able to see it. It can take a little while for a post to
propagate.
 
[...]
 
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 09 09:29PM +0200

> Hi,
 
> Could you please explain me why capturing variables by value in a lambda is immutable by default ?
 
> [=] () { ++ outsideVar; } (); // compilation error
 
It's the only place that C++ got `const` practically correct, as the
default.
 
It couldn't very well do that for the machinery inherited from C, and
Bjarne started designing classes around 1980, before the benefits and
desirability of `const` was realized (at the time his preferred keyword
was `readonly`, as I recall: the concept hadn't even crystallized).
 
But lambda did not enter the language until C++11, that is, in 2011.
 
`const` is useful because it /constrains/ what can possibly happen.
 
That facilities understanding of code, writing correct code in the first
place, and when the compiler knows that `outsideVar` won't be changing
over the lifetime of the lambda it can outfit the lambda with just a
reference instead of doing a possibly costly copying of full value.
 
 
> I'm aware of "mutable" keyword in this scenario.
 
Yep.
 
I don't wish it was like that for ordinary variables because `mutable`
is too long a keyword for the not uncommon case where one wants a
variable to be actually variable...
 
But something like `var`, that would have been nice.
 
Happily we can now write efficient loops with `const` loop variable:
 
for( const int i: up_to( n ) ) ...
 
... with a suitable simple definition of an `up_to` function, which with
the C++20 ranges library might be a simple alias (I'm not sure though).
 
Alas, re the ordinary variables, C legacy.
 
 
Cheers!,
 
- Alf
Tim Rentsch <tr.17687@z991.linuxsc.com>: Aug 09 10:44AM -0700

>> etc.
 
> Those words sound like "capabilities" to me, which seems appropriate
> to the suffix "...able" on those names.
 
Despite how the words might sound, "capability" is not a good fit for
a C++ concept, which supplies nothing in the way of implementation.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Aug 09 10:36AM -0700

>>> any language.
 
>> This summary sentence is utter nonsense.
 
> What does the phrase "This summary sentence" refer to?
 
The sentence that starts "Therefore some kind of ...".
woodbrian77@gmail.com: Aug 09 10:32AM -0700

Shalom
 
Are there any compilers that have preliminary support
for static exceptions? I'm particularly interested
in when Gcc will have that. I have a mix of closed
and open source code. My primary compiler for the
closed source stuff is Gcc.
 
So far the only thing in 2020 C++ that I've found
helpful is std::span. I thought about coroutines
here:
https://www.reddit.com/r/cpp_questions/comments/c6mbls/coroutines/
 
but they didn't seem very promising.
 
 
Brian
Ebenezer Enterprises - Enjoying programming again.
https://github.com/Ebenezer-group/onwards
ram@zedat.fu-berlin.de (Stefan Ram): Aug 09 05:29PM

It has been written:
>Subject: C has no evaluation order of function parameters
 
main.c
 
#include <math.h>
#include <stdio.h>
 
double f( int const n )
{ printf( "%d\n", n );
return 0; }
 
int main( void )
{ pow( f( 0 ), f( 1 )); }
 
For one example, the above might have undefined behavior,
because
 
|side effects and value computations of subexpressions are
|unsequenced
 
and we cannot know whether »printf« has any (internal)
side-effects on a scalar object.
 
|If a side effect on a scalar object is unsequenced relative
|to either a different side effect on the same scalar object
|or a value computation using the value of the same scalar
|object, the behavior is undefined.
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)