Sunday, August 14, 2016

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

Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 14 04:32PM +0100

C++ is a complicated language? No shit. Have you only just realized this?
 
C++ was complicated before C++98 so imagine how complicated it is now.
 
However, paradoxically, C++'s complexity can result in simpler C++
PROGRAMS which is a GOOD THING (tm).
 
/Flibble
ram@zedat.fu-berlin.de (Stefan Ram): Aug 14 11:42AM

>Is this sensible?
 
Without proper documentation (Doxygen), it's hard to say
what the semantics are supposed to be and then compare this
with the actual semantics.
 
> Saves defining a null_type empty class?
 
I can't even parse this string as English!
 
>Or is it inappropriate semantics?
 
This also is hard to read. Can code /be semantics/?
 
Without documentation (Doxygen) it's little semantics.
 
>Extended use of nullptr
 
It uses some type »std::nullptr_t«, which is not the same as
»nullptr«, and may not be the same as »::std::nullptr_t«.
»nullptr« is not used as far as I can see.
ram@zedat.fu-berlin.de (Stefan Ram): Aug 14 03:26PM

> lhs += x;
> return std::move(lhs);
>}
 
You have an object as a return value and then move into
this object. lhs is an lvalue, not an xvalue, so RVO might
not move from it without the move as far as I understand it.
 
I have no experience in this field. But the class
Signalsource could get methode to return its resources
and bring the object into a valid but resourceless state
and an implicit constructor to build a SignalSource from
this.
 
return lhs.resources();
 
Then the returned object would be built from those resources.
jacob navia <jacob@jacob.remcomp.fr>: Aug 14 01:36AM +0200

Le 12/08/2016 à 08:57, jacobnavia a écrit :
 
 
Please look at
https://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Clang-Defending-C-from-Murphy-s-Million-Monkeys
 
In that talk, see the slide and discussion. Starts around minute 47 of
the video
jacob navia <jacob@jacob.remcomp.fr>: Aug 14 01:38AM +0200

Le 14/08/2016 à 01:24, Ian Collins a écrit :
 
> clang++ -std=c++03 x.cc; ./a.out; clang++ --version
> X!
> clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)
 
See the discussion of that in
https://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Clang-Defending-C-from-Murphy-s-Million-Monkeys
 
Minute 47 of the video.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 14 01:32AM +0100

On 14/08/2016 00:38, jacob navia wrote:
 
> See the discussion of that in
> https://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Clang-Defending-C-from-Murphy-s-Million-Monkeys
 
> Minute 47 of the video.
 
Easy explanation: the clang guy is simply wrong.
 
/Flibble
jacob navia <jacob@jacob.remcomp.fr>: Aug 14 09:09AM +0200

Le 14/08/2016 à 02:32, Mr Flibble a écrit :
 
 
>> Minute 47 of the video.
 
> Easy explanation: the clang guy is simply wrong.
 
Well, if you know that he is "wrong" can you explain WHY is he wrong?
 
Or he is wrong because some unknown compiler you are using seems to say
otherwise?
Ian Collins <ian-news@hotmail.com>: Aug 14 07:12PM +1200

On 08/14/16 07:09 PM, jacob navia wrote:
 
> Well, if you know that he is "wrong" can you explain WHY is he wrong?
 
> Or he is wrong because some unknown compiler you are using seems to say
> otherwise?
 
We've already been over that.
 
--
Ian
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 14 02:10PM +0200

On 14.08.2016 09:12, Ian Collins wrote:
 
>> Or he is wrong because some unknown compiler you are using seems to say
>> otherwise?
 
> We've already been over that.
 
No, as I see it that's a blind assertion, an incorrect one.
 
Jacob asks for a deduction from the official standard's rules, not
examples of particular compilers' behaviors.
 
And our inability to give him that tends to support his contention that
the language, or at least the standard's way of describing the language,
has become too complex.
 
 
Cheers!,
 
- Alf
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 14 01:29PM +0100

On 14/08/2016 13:10, Alf P. Steinbach wrote:
 
> And our inability to give him that tends to support his contention that
> the language, or at least the standard's way of describing the language,
> has become too complex.
 
It is not an incorrect assertion. An lvalue can never be a null pointer
constant. You, like the clang guy, are simply wrong.
 
/Flibble
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 14 03:26PM +0200

On 14.08.2016 14:29, Mr Flibble wrote:
 
> An lvalue can never be a null pointer constant.
 
Are you sure that `S().x` is an lvalue?
 
Let's check that assertion, using your own proof technique, what
compilers say about it:
 
struct S{ int x; };
 
auto main() -> int
{
S().x = 666;
}
 
<compilation>
[C:\my\temp]
> g++ foo.cpp
foo.cpp: In function 'int main()':
foo.cpp:5:11: error: using temporary as lvalue [-fpermissive]
S().x = 666;
^
 
[C:\my\temp]
> cl foo.cpp
foo.cpp
 
[C:\my\temp]
> _
</compilation>
 
Oh my, they disagree!
 
What do you think the standard says about it?
 
 
Cheers & hth.,
 
- Alf
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 14 02:51PM +0100

On 14/08/2016 14:26, Alf P. Steinbach wrote:
> compilers say about it:
 
> struct S{ int x; };
 
> auto main() -> int
 
Do you realize how demented that looks? Take your meds and write:
 
int main()
 
like any sane person would.
 
>> _
> </compilation>
 
> Oh my, they disagree!
 
Intel's compiler also allows the assignment.
 
 
> What do you think the standard says about it?
 
According to the Standard it is an rvalue however it also has a *name*.
 
/Flibble
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 14 02:57PM +0100

leigh@server:~$ cat test.cpp
struct s
{
int n;
};
 
int main()
{
constexpr int z1 = 0;
const int z2 = 0;
int z3 = 0;
void* p0 = 0;
void* p1 = z1;
void* p2 = z2;
void* p3 = z3;
void* p4 = s().n;
}
leigh@server:~$ g++ -std=c++11 test.cpp
test.cpp: In function 'int main()':
test.cpp:12:13: error: invalid conversion from 'int' to 'void*'
[-fpermissive]
void* p1 = z1;
^
test.cpp:13:13: error: invalid conversion from 'int' to 'void*'
[-fpermissive]
void* p2 = z2;
^
test.cpp:14:13: error: invalid conversion from 'int' to 'void*'
[-fpermissive]
void* p3 = z3;
^
test.cpp:15:17: error: invalid conversion from 'int' to 'void*'
[-fpermissive]
void* p4 = s().n;
^
leigh@server:~$ clang -std=c++11 test.cpp
test.cpp:12:8: error: cannot initialize a variable of type 'void *' with an
lvalue of type 'const int'
void* p1 = z1;
^ ~~
test.cpp:13:8: error: cannot initialize a variable of type 'void *' with an
lvalue of type 'const int'
void* p2 = z2;
^ ~~
test.cpp:14:8: error: cannot initialize a variable of type 'void *' with an
lvalue of type 'int'
void* p3 = z3;
^ ~~
test.cpp:15:8: error: cannot initialize a variable of type 'void *' with an
rvalue of type 'int'
void* p4 = s().n;
^ ~~~~~
4 errors generated.
leigh@server:~$
 
/Flibble
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Aug 14 07:16AM -0700

Examine the generated assembly source code in non-optimized
mode. It will show you exactly what's happening, and what
is what.
 
Best regards,
Rick C. Hodgin
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 14 03:18PM +0100

On 14/08/2016 15:16, Rick C. Hodgin wrote:
> Examine the generated assembly source code in non-optimized
> mode. It will show you exactly what's happening, and what
> is what.
 
There won't be any assembly because the compilation fails (as it
should). Use your brain mate.
 
/Flibble
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 14 04:35PM +0200

On 14.08.2016 15:51, Mr Flibble wrote:
 
>> Are you sure that `S().x` is an lvalue?
 
>> Let's check that assertion, using your own proof technique, what
>> compilers say about it:
[snip]
 
> ... demented ...
 
> According to the Standard it is an rvalue
 
So, your assertion about lvalue turned out to be irrelevant: `S().x` is
an rvalue, not an lvalue.
 
 
> however it also has a *name*.
 
Uhm?
 
 
Cheers & hth.,
 
- Alf
Manfred <mx2927@gmail.com>: Aug 14 05:23PM +0200

On 08/14/2016 01:06 AM, Ian Collins wrote:
> On 08/14/16 10:44 AM, jacob navia wrote:
 
>> Where did I went wrong?
 
> There isn't any ambiguity, the constructor for X is the only fit.
Agreed: the expression S().n has type int indeed.
 
> If you change the constructor to be explicit (which it should be, no
> matter what version of C++ you use), the code won't compile no matter
> what version of C++ you specify.
 
Therefore compilers which end up with Pointer! are wrong, and since they
appear not to be irrelevant (my gcc always outputs X! by the way), this
confirms the complexity of the language, IMHO. Meaning that the original
cleanliness of the language risks to get polluted by newer "improvements"
 
Regards
bitrex <bitrex@de.lete.earthlink.net>: Aug 14 11:11AM -0400

I'm working on rewriting a piece of code that was written to the C++11
standard for a device whose STL seems to only be C++0x compliant. Is
there a standard way to "backport" code using C++11's std::move operation?
 
Here is the context (where SignalSource is a class and I believe
SampleType is some fashion of integer type):
 
SignalSource operator+(SignalSource&& lhs, SampleType x)
{
lhs += x;
return std::move(lhs);
}
 
SignalSource operator+(SampleType x, SignalSource&& rhs)
{
rhs += x;
return std::move(rhs);
}
 
My understanding is that std::move is to avoid making unnecessary copies
of objects on the stack when the source/destination is going to be
destroyed anyway, so I didn't know if there was some "canonical" way to
backport this.
Daniel <danielaparker@gmail.com>: Aug 13 06:49PM -0700

Consider a class which has a number of states, including a "null" state, e.g.
 
class A
{
public:
bool is_null() const;
// Returns true if the object is in a null state
};
 
I notice a number of C++ libraries with such a thing are using nullptr to
initialize a null state, e.g.
 
 
class A
{
public:
enum class states {null_s,other_s};
 
A()
{
state_ = states::other_s;
}
 
A(std::nullptr_t)
{
state_ = states::null_s;
}
 
bool is_null() const
{
return state_ == states::null_s;
}
private:
states state_;
};
 
Is this sensible? Saves defining a null_type empty class? Or is it
inappropriate semantics?
 
Thanks,
Daniel
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 14 03:08AM +0100

On 14/08/2016 02:49, Daniel wrote:
> };
 
> Is this sensible? Saves defining a null_type empty class? Or is it
> inappropriate semantics?
 
std::optional.
 
/Flibble
Daniel <danielaparker@gmail.com>: Aug 13 07:15PM -0700

On Saturday, August 13, 2016 at 10:08:55 PM UTC-4, Mr Flibble wrote:
 
> > Is this sensible? Saves defining a null_type empty class? Or is it
> > inappropriate semantics?
 
> std::optional.
 
Different context, the context here is where "null" is a valid state of an
object.
 
Daniel
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 14 03:18AM +0100

On 14/08/2016 03:15, Daniel wrote:
 
>> std::optional.
 
> Different context, the context here is where "null" is a valid state of an
> object.
 
std::optional.
 
/Flibble
Daniel <danielaparker@gmail.com>: Aug 13 08:25PM -0700

On Saturday, August 13, 2016 at 10:18:22 PM UTC-4, Mr Flibble wrote:
 
> > Different context, the context here is where "null" is a valid state of an
> > object.
 
> std::optional.
 
Just relax, we're just having a nice discussion about whether for a class
that has the notion of "null" as a valid state (imagine for example a class
that encapsulates a json value), whether for such a class it is appropriate
to borrow nullptr to initialize it to that state, as some C++ libraries do.
 
Best regards,
Daniel
Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid>: Aug 14 01:11PM +0200

> };
 
> Is this sensible? Saves defining a null_type empty class? Or is it
> inappropriate semantics?
 
You could also use a null pointer to A to represent the null state, but
that would require the systematic use of pointers instead of instances
of A, i.e., dynamic allocation, which is better avoided when possible.
Instead, what you show above burries the null state inside the class,
which is not a bad idea.
 
Anyway, your example is way too abstract, especially because of the
default constructor, which is very unlikely for a class holding
meaningful "state". It may also be the case that a special pattern of
values adequately represents the null state, in which case you do not
need anything else. If you really need a special constructor, you can
use whatever type lets it be different from the others, and in this case
I would not choose nullptr_t, but rather define a specific, class-local,
enum/struct/class, used only for that particular ctor.
 
But this was all before std::optional. You may not like it, but this is
exactly what std::optional is for. Here is an SO discussion of its use:
 
http://stackoverflow.com/questions/16860960/how-should-one-use-stdoptional
 
I can't see why one should avoid it, except maybe when the storage
requirements are large enough and null values frequent enough to make a
difference. But then std::optional of a pointer is still a good idea.
 
-- Alain.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 14 12:47PM +0100

On 14/08/2016 12:42, Stefan Ram wrote:
 
> It uses some type »std::nullptr_t«, which is not the same as
> »nullptr«, and may not be the same as »::std::nullptr_t«.
> »nullptr« is not used as far as I can see.
 
The type of std::nullptr is std::nullptr_t so his function prototype was
correct.
 
/Flibble
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)