Wednesday, December 3, 2014

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

comp.lang.c++@googlegroups.com Google Groups
Unsure why you received this message? You previously subscribed to digests from this group, but we haven't been sending them for a while. We fixed that, but if you don't want to get these messages, send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Christopher Pisz <nospam@notanaddress.com>: Dec 03 10:54AM -0600

Why is there an escape sequence for single quote and question mark?
I don't recall ever having a problem with std::string text = "How are
you?"; or std::string text = "He likes 'adventure'";
red floyd <no.spam@its.invalid>: Dec 03 09:01AM -0800

On 12/3/2014 8:54 AM, Christopher Pisz wrote:
> Why is there an escape sequence for single quote and question mark?
> I don't recall ever having a problem with std::string text = "How are
> you?"; or std::string text = "He likes 'adventure'";
 
single quote:
 
char c = '\'';
 
As for question mark? I suspect it has to do with trigraphs, but
I don't know for sure.
Victor Bazarov <v.bazarov@comcast.invalid>: Dec 03 12:03PM -0500

On 12/3/2014 11:54 AM, Christopher Pisz wrote:
> Why is there an escape sequence for single quote and question mark?
> I don't recall ever having a problem with std::string text = "How are
> you?"; or std::string text = "He likes 'adventure'";
 
Try declaring a single char and initializing it with a *single quote*
without an escape sequence... The question mark rule may have something
to do with trigraph sequences.
 
V
--
I do not respond to top-posted replies, please don't ask
Melzzzzz <mel@zzzzz.com>: Dec 03 11:19AM +0100

Function in question is this:
 
int testNormal(const vector_t & ghs, const vector_t & lhs) {
int max = 0;
int tempMax;
for (unsigned k = 0; k < ghs.size(); k++) {
tempMax = lhs[k] + ghs[k];
if (max < tempMax) {
max = tempMax;
}
}
return max;
}
 
where: typedef vector<int> vector_t;
(could be also plain array so I post this to clc as well)
 
If k is unsigned both clang and gcc are not able to vectorize, producing
scalar code.
But, if k is int, both clang and gcc vectorize code producing 5x(SSE)
or 10x(AVX2) faster loop!
I am really stumbled as I can't see why type of index variable restricts
this optimization.
James Kuyper <jameskuyper@verizon.net>: Dec 03 08:02AM -0500

On 12/03/2014 05:19 AM, Melzzzzz wrote:
...
> int testNormal(const vector_t & ghs, const vector_t & lhs) {
...
> where: typedef vector<int> vector_t;
 
Cross-posting to comp.lang.c a question about code that can't even be
compiled as C code is pointless.
--
James Kuyper
jacob navia <jacob@spamsink.net>: Dec 03 02:57PM +0100

Le 03/12/2014 14:02, James Kuyper a écrit :
>> where: typedef vector<int> vector_t;
 
> Cross-posting to comp.lang.c a question about code that can't even be
> compiled as C code is pointless.
 
He wrote (and you did not quote that)
 
> (could be also plain array so I post this to clc as well)
 
Read for comprehension next time.
Tim Prince <tprince@computer.org>: Dec 03 09:23AM -0500

On 12/3/2014 8:57 AM, jacob navia wrote:
 
> He wrote (and you did not quote that)
 
>> (could be also plain array so I post this to clc as well)
 
> Read for comprehension next time.
but OP leaves it open to guesswork on what extent he simplifies the
problem for C.
OP also leaves his choice of compiler and target open for guesswork.
However, unsigned indexing is notoriously (perhaps even surprisingly)
difficult to deal with in vectorization, particularly on ia32 target.
Victor Bazarov <v.bazarov@comcast.invalid>: Dec 03 09:24AM -0500

On 12/3/2014 8:57 AM, jacob navia wrote:
 
> He wrote (and you did not quote that)
 
> > (could be also plain array so I post this to clc as well)
 
> Read for comprehension next time.
 
The code uses references and a member function. Do those exist in C?
(it's been some time since I touched C) And if vector_t is a "plain
array", how can it have a member ('size') at all?
 
V
--
I do not respond to top-posted replies, please don't ask
Richard Heathfield <invalid@see.sig.invalid>: Dec 03 02:36PM

Victor Bazarov wrote:
 
 
>> > (could be also plain array so I post this to clc as well)
 
>> Read for comprehension next time.
 
> The code uses references and a member function. Do those exist in C?
 
No, but plain arrays do.
 
> (it's been some time since I touched C)
 
It's good for you. Stops you getting scurvy or rickets or something like
that.
 
> And if vector_t is a "plain
> array", how can it have a member ('size') at all?
 
In a sense, of course, it can't. Nevertheless, a number of trivial solutions
to the problem do exist. You can use an extra parameter to allow the size to
be passed in, or you can make vector_t a structure type which contains not
only the array but also the size. (If it's dynamic, you keep a count. If
it's static, you can just sizeof arr / sizeof arr[0], provided it's safely
tucked up inside the struct.)
 
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
James Kuyper <jameskuyper@verizon.net>: Dec 03 10:03AM -0500

On 12/03/2014 09:23 AM, Tim Prince wrote:
 
>> He wrote (and you did not quote that)
 
>>> (could be also plain array so I post this to clc as well)
 
>> Read for comprehension next time.
 
I'll admit that I didn't bothering reading any further after running
into the template typedef. However, his comment about plain arrays
doesn't change the inappropriateness of his message.
The wording of his comment could be interpreted as indicating that he
was just guessing about whether or not the same problem would occur with
plain arrays. If so, he should not have posted until after he had tested
it - the test is trivial enough to perform and evaluate.
If, on the other hand, he did already test with plain arrays, he should
have posted the plain array version of his code, not the template
version, particularly if he's posting to comp.lang.c. It could very well
be that the failure to vectorize is due to some detail of how he
converted the code to work with a plain array, so we need to see the
actual code.
However, he should have posted the plain array version even if he was
posting only to comp.lang.c++. By demonstrating the problem with plain
arrays he avoids having to worry whether it's due to some interaction
with the std::vector<> implementation.
 
> OP also leaves his choice of compiler and target open for guesswork.
> However, unsigned indexing is notoriously (perhaps even surprisingly)
> difficult to deal with in vectorization, particularly on ia32 target.
 
I suspect that an expanded explanation for that last sentence would
directly address the OP's original question.
--
James Kuyper
Melzzzzz <mel@zzzzz.com>: Dec 03 04:03PM +0100

On 12/3/14 2:02 PM, James Kuyper wrote:
>> where: typedef vector<int> vector_t;
 
> Cross-posting to comp.lang.c a question about code that can't even be
> compiled as C code is pointless.
 
I guess you are right, if I change function to:
 
int testNormal(const int* ghs, const int* lhs,unsigned sz) {
int max = 0;
int tempMax;
for (unsigned k = 0; k < sz; k++) {
tempMax = lhs[k] + ghs[k];
if (max < tempMax) {
max = tempMax;
}
}
return max;
}
 
 
then both clang & gcc are able to vectorize it no problem. So this is
something related to c++ vector.
Victor Bazarov <v.bazarov@comcast.invalid>: Dec 03 10:27AM -0500

On 12/3/2014 10:03 AM, Melzzzzz wrote:
> }
 
> then both clang & gcc are able to vectorize it no problem. So this is
> something related to c++ vector.
 
I lean towards its being the use of .size() in the 'for' condition.
Change the 'for' to read
 
for (unsigned k = 0, sz = ghs.size(); k < sz; ++k)
 
and it's probably going to make the vectorizer happier.
 
V
--
I do not respond to top-posted replies, please don't ask
Melzzzzz <mel@zzzzz.com>: Dec 03 04:43PM +0100

On 12/3/14 4:27 PM, Victor Bazarov wrote:
 
> for (unsigned k = 0, sz = ghs.size(); k < sz; ++k)
 
> and it's probably going to make the vectorizer happier.
 
> V
You are right,I just changed function to:
 
int testNormal(const vector_t& ghs, const vector_t& lhs,unsigned sz) {
int max = 0;
int tempMax;
for (unsigned k = 0; k < sz; k++) {
tempMax = lhs[k] + ghs[k];
if (max < tempMax) {
max = tempMax;
}
}
return max;
}
 
and indeed compilers are able to vectorize it. Heh I thought that this
is related to vectors operator[], but apparently it is not ;)
red floyd <no.spam@its.invalid>: Dec 03 08:59AM -0800

On 12/3/2014 2:19 AM, Melzzzzz wrote:
> or 10x(AVX2) faster loop!
> I am really stumbled as I can't see why type of index variable restricts
> this optimization.
 
It's a quality of implementation issue. Has nothing to do with the
language itself. Please see FAQ 5.9.
"Öö Tiib" <ootiib@hot.ee>: Dec 02 06:21PM -0800

On Tuesday, 2 December 2014 20:34:38 UTC+2, red floyd wrote:
 
> Other than the lack of code context (and Herb explicitly said it was a
> fragment), how is it ill-formed? It's semantically incorrect, but
> where is the ill-formedness to be found?
 
The question was what I would like the third line to be. My answer is
that I would like it to be called badly formed by compiler. How exactly
to form the language rules ... I can't tell.
 
The reason is that there are no prevailing preference among developers
about evaluation order in that line. Regardless if standard did specify
{0,0}, {0,1} or {1,0} as its outcome the 60-70% of developers would find
it unintuitive. On the other hand lot of them do not even realize what
unreadable gibberish it is. So the only clean way out of the situation
is to call it officially illegal.
red floyd <no.spam@its.invalid>: Dec 03 08:58AM -0800

On 12/2/2014 6:21 PM, Öö Tiib wrote:
 
> The question was what I would like the third line to be. My answer is
> that I would like it to be called badly formed by compiler. How exactly
> to form the language rules ... I can't tell.
 
 
Ah. Got ya.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 02 11:58PM

On 02/12/2014 23:27, Mr Flibble wrote:
 
>> I guess I don't see why either alternative is superior to i += 2
 
> If 'i' is a bi-directional (not random access) iterator the += 2 won't
> work.
 
However for such an iterator operator++ is a function call so there
won't be the possibility of UB.
 
/Flibble
Martijn Lievaart <m@rtij.nl.invlalid>: Dec 03 09:05AM +0100

On Tue, 02 Dec 2014 23:58:41 +0000, Mr Flibble wrote:
 
>> work.
 
> However for such an iterator operator++ is a function call so there
> won't be the possibility of UB.
 
Does this also hold if the iterator is implemented as a pointer?
 
M4
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 03 11:28AM

On Tue, 2 Dec 2014 19:43:22 +0000
 
> > /Flibble
 
> As am I. But whatever, just use the comma operator (++i, ++i), which
> is always right.
 
Interesting, on looking further at this, I think that although illegal
in C++98, the expression ++++i is valid in C++11/14.
 
The complete normative reading of §1.9/15 of C++11, with examples and
parenthetical comments removed, is:
 
"Except where noted, evaluations of operands of individual operators
and of subexpressions of individual expressions are unsequenced. The
value computations of the operands of an operator are sequenced
before the value computation of the result of the operator. If a side
effect on a scalar object is unsequenced relative to either
another side effect on the same scalar object or a value computation
using the value of the same scalar object, the behavior is undefined."
 
It is the second sentence which is important. ++++i is in effect
identical in C++11 to ++i,++i. Likewise although the behaviour of this
is unspecified in C++98, I think it is required to increment by 2 in
C++11:
 
i = ++i + 1
 
However, this is still undefined in C++98 and C++11:
 
i = i++ + 1
 
Turning to the examples given in the standard, the reason why in C++11
this:
 
i = v[i++];
 
is undefined is that although the assignment to i is sequenced before
the evaluation of v[i] on the right hand side, the subsequent side
effect comprising the increment of i carried out on the right hand side
is not. So the increment of i on the right hand side and the assignment
to i are unsequenced. On the other hand this:
 
v[++i] = ++i;
 
is invalid in C++11 (I think) because, although the assignment is
sequenced before the evaluation of the right hand side, the
prior evaluation of the subexpression ++i on the left hand side is
unsequenced with respect to the evaluation of ++i on the right hand
side.
 
Err, I think.
 
Chris
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 03 11:38AM

On Wed, 3 Dec 2014 11:28:40 +0000
 
> v[++i] = ++i;
 
> is invalid in C++11 (I think) because, although the assignment is
> sequenced before the evaluation of the right hand side, the
^^^^^^
after
Martijn Lievaart <m@rtij.nl.invlalid>: Dec 03 12:47PM +0100

On Wed, 03 Dec 2014 11:28:40 +0000, Chris Vine wrote:
 
> identical in C++11 to ++i,++i. Likewise although the behaviour of this
> is unspecified in C++98, I think it is required to increment by 2 in
> C++11:
 
All this says to me is that the value of ++i must be known, not that the
side effects have taken place. AFAICS the value of ++i must be of
reference type, not value type, so can be known without the side effect
taking effect.
 
But that is also just my interpretation. Bottomline, don't do this. ++i; +
+i; has the same effect and is clearer.
 
M4
 
M4
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 03 12:35PM

On Wed, 3 Dec 2014 12:47:01 +0100
> the side effects have taken place. AFAICS the value of ++i must be of
> reference type, not value type, so can be known without the side
> effect taking effect.
 
Pre-increment on a scalar is required by the standard to have completed
its side effects by the time its value is known. That is the reason
why the construction appears to be valid. Its value with respect to a
scalar is stated to be a lvalue (§5.3.2/1). Its side effect is, by
rule, to increment the scalar and its value is its value after the
increment. On a user defined type the effect is whatever the user
provides it to be, and because pre- and post-increment are function
calls on user and library types, different sequencing considerations
apply - the return of a function call is always sequenced after
evaluation of the arguments and the evaluation of any side effects
within the body of the function.
 
On a sub-note, it is interesting to compare the examples given in §5/4
of C++98 and §1.9/15 of C++11. In C++98 pre-increment 'i = ++i + 1' is
given as an example of unspecified behaviour (which by virtue of the
last sentence of §5/4 is also undefined behaviour). In C++11 it is not:
instead the examples substitute the post-increment 'i = i++ + 1' as an
example of undefined behaviour.
 
> But that is also just my interpretation. Bottomline, don't do this.
> ++i; ++i; has the same effect and is clearer.
 
I agree. This is for pedagogical purposes only. I hope it would never
be in live code.
 
Chris
Vincenzo Mercuri <invalid@world.net>: Dec 03 01:09PM +0100

Il 01/12/2014 10:56, Öö Tiib ha scritto:
> On Friday, 28 November 2014 04:24:09 UTC+2, Vincenzo Mercuri wrote:
..
> Why it matters if 'const' or not 'const' member 'operator()' of 'std::less<>' is called? 'std::less<>' is anyway stateless unless
> you have yourself specialized it as stateful.
 
..
 
I'm not sure why I pointed out the 'constness' of member operator().
That is actually irrelevant. I apologize, you are right.
 
 
--
Vincenzo Mercuri
Vincenzo Mercuri <invalid@world.net>: Dec 03 01:27PM +0100

Il 28/11/2014 14:53, Mr Flibble ha scritto:
 
> The double would be a different object to the int when using
> static_cast<> whilst the result of the const_cast<> returns the *same*
> object.
 
I didn't say it doesn't. I said that 'const T& obj' and 'T& obj' are not
the same thing. Forcing something to be something else is another story.
 
--
Vincenzo Mercuri
JiiPee <no@notvalid.com>: Dec 03 11:11AM

How is it possible this array compiles? Last time I studied C++ the
array size must be a constant value (double checked: "NOTE: The
|elements| field within square brackets |[]|, representing the number of
elements in the array, must be a /constant expression/"). How is it
possible howMany can be a variable below? Obviously there is something I
do not see... But I do see a normal array int arr[howMany]; .... so...
 
#include <iostream>
 
using namespace std;
 
int main()
{
int howMany;
cout << "How big array?: ";
cin >> howMany;
 
int arr[howMany];
if(howMany > 5)
{
arr[howMany-2] = 67;
cout<<arr[howMany-2];
}
 
return 0;
}
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)