Tuesday, January 30, 2018

Digest for comp.lang.c++@googlegroups.com - 24 updates in 7 topics

"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 30 03:41PM +0100

On 1/30/2018 3:16 PM, Stefan Ram wrote:
 
> It /does/ give an error message when »//« is removed, however.
> I also have a version of clang, giving an error message for the
> code above.
 
Ordinary function overloads can't differ in return type only, so that
lack of diagnostic is clearly a compiler bug.
 
That said, I /think/ this code is valid:
 
struct S
{
template< class Result >
operator Result() const { return {}; }
};
 
auto main() -> int
{
S s;
int i = s;
double d = s;
}
 
Disclaimer: off the cuff code.
 
Assuming the code is valid the open question is then, where does the
standard allow function template instantiations to differ in return type
only?
 
And (I don't think so) is there any way to refer to that function with
explicit template parameter?
 
Cheers!,
 
- Alf
"James R. Kuyper" <jameskuyper@verizon.net>: Jan 30 10:01AM -0500

On 01/30/2018 09:16 AM, Stefan Ram wrote:
> I have a version of GCC here that is not too old and does not
> give an error message for the code below.
 
> void f(){}
 
This declaration has file scope.
 
> //int f();
 
"Function declarations that differ only in the return type, the
exception specification (18.4), or both cannot be overloaded." (16.1p2).
"A program is ill-formed if it contains two such non-overloadable
declarations in the same scope." (16.1p1).
 
> int main() { int f(); }
 
This declaration has block scope, therefore 16.1p1 doesn't apply. Inside
the scope of this declaration, it hides the file scope declaration.
However, 16.1p2 should still apply - it isn't permitted for a function
matching this declaration to be defined in the same program as the first
definition of f() above. It seems to me that this should qualify as a
diagnosable rule, and therefore one that must result in a diagnostic
(4.1p2), but gcc apparently disagrees with me about that.
 
I modified f() to print some output, and modified main() to print the
value returned by f() - both printouts worked. The returned value was
6295680.
 
"James R. Kuyper" <jameskuyper@verizon.net>: Jan 30 11:51AM -0500

On 01/30/2018 10:01 AM, James R. Kuyper wrote:
 
> I modified f() to print some output, and modified main() to print the
> value returned by f() - both printouts worked. The returned value was
> 6295680.
 
I've been asked to post that code:
 
#include <iostream>
void f(){
std::cout << "Hello, World!" << std::endl;
}
// int f();
int main() { int f();
std::cout << "f() returns:" << f() << std::endl;
}
legalize+jeeves@mail.xmission.com (Richard): Jan 30 05:49PM

[Please do not mail me a copy of your followup]
 
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> spake the secret code
 
>That said, I /think/ this code is valid:
 
> auto main() -> int
 
Valid, but ugly. :-)
--
"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>
"Öö Tiib" <ootiib@hot.ee>: Jan 30 09:50AM -0800

On Tuesday, 30 January 2018 16:41:24 UTC+2, Alf P. Steinbach wrote:
> double d = s;
> }
 
> Disclaimer: off the cuff code.
 
It seems valid by [temp.mem].
 
> Assuming the code is valid the open question is then, where does the
> standard allow function template instantiations to differ in return type
> only?
 
The conversion function is member function. Return value type and
template arguments are all part of member function template's
signature. By [defns.signature.member.templ]
 
> And (I don't think so) is there any way to refer to that function with
> explicit template parameter?
 
You must be able to by also [temp.mem]. Use:
 
int i = s.operator int();
 
... in your above example.
It is illegal to use your favorite syntax for conversion functions
like "operator auto() -> short;". ;)
Manfred <noname@invalid.add>: Jan 30 09:02PM +0100

On 1/30/2018 3:41 PM, Alf P. Steinbach wrote:
>>    code above.
 
> Ordinary function overloads can't differ in return type only, so that
> lack of diagnostic is clearly a compiler bug.
 
I don't think it is a compiler bug - in fact this is not about function
overloading, it is an example of name hiding instead [*].
 
(on the other hand, when the '//' is removed, it would be function
overloading, hence the compiler error)
 
[*] See also n4618 3.4.2, sub (3.2)
Manfred <noname@invalid.add>: Jan 30 09:42PM +0100

On 1/30/2018 5:51 PM, James R. Kuyper wrote:
>> definition of f() above. It seems to me that this should qualify as a
>> diagnosable rule, and therefore one that must result in a diagnostic
>> (4.1p2), but gcc apparently disagrees with me about that.
 
(you are probably referring to a different version of the standard than
n4618)
n4618 3.4p1 says: "Overload resolution(13.3) takes place after name
lookup has succeeded" so there appears to be a precedence of name hiding
(3.3.10) over overload resolution, or at least this is how I understand it.
 
 
>> I modified f() to print some output, and modified main() to print the
>> value returned by f() - both printouts worked. The returned value was
>> 6295680.
 
Interesting experiment; the way I understand this is that this happens
because of 2 step program generation: /compilation/ succeeds (because of
the above), and then /linking/ succeeds too by finding 'void f()' as a
match for 'int f()', which is weird [*].
In fact the same result of yours happens if 'void f()' is moved to a
separate compilation unit (where there would be no question of overload
resolution).
 
[*] weird but still looks consistent with 1.3.19 - definition of
function signature:
1.3.19 [defns.signature]
signature
<function> name, parameter type list (8.3.5), and enclosing namespace
(if any)
[ Note: Signatures are used as a basis for name mangling and
linking.—end note ]
 
"James R. Kuyper" <jameskuyper@verizon.net>: Jan 30 04:42PM -0500

On 01/30/2018 03:42 PM, Manfred wrote:
>>> (4.1p2), but gcc apparently disagrees with me about that.
 
> (you are probably referring to a different version of the standard than
> n4618)
 
I'm using n4659.pdf, dated 2-17-03-21.
 
> n4618 3.4p1 says: "Overload resolution(13.3) takes place after name
> lookup has succeeded"
 
That's 6.4p1 in n4659.pdf, and the cross-reference is to 16.3 rather
than 13.3. The words are the same, however.
 
 
> ... so there appears to be a precedence of name hiding
> (3.3.10) over overload resolution, or at least this is how I understand it.
 
Overload resolution doesn't come into play in this version of the code,
since it contains no calls to any function. My version down below does
call f(), and name hiding does determine that it should use the
declaration of f() with a return type of 'int', so overload resolution
still ends up with no role to play in this code. However, this code
contains no definition for any function that matches that declaration.
 
The very existence of overloads that differ only by their return type is
prohibited by 16.1p2, regardless of hiding or overload resolution.
Therefore, it is not permitted for there to be any actual function named
f() which is compatible with the block-scope declaration of f().
 
> In fact the same result of yours happens if 'void f()' is moved to a
> separate compilation unit (where there would be no question of overload
> resolution).
 
The key point is
"Two names that are the same (Clause 6) and that are declared in
different scopes shall denote the same variable, function, type,
template or namespace if
— both names have external linkage or ..." (6.5p9)
 
The definition of f() and the block scope declaration of f() are both
declarations of the same name, which has external linkage.
 
and "... the types specified by all declarations referring to a given
variable or function shall be identical... A violation of this rule on
type identity does not require a diagnostic." (6.5p10)
 
...
legalize+jeeves@mail.xmission.com (Richard): Jan 30 10:33PM

[Please do not mail me a copy of your followup]
 
Manfred <noname@invalid.add> spake the secret code
 
>(you are probably referring to a different version of the standard than
>n4618)
 
I thought n4659 was the last published draft before C++17 was accepted.
 
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf>
--
"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>
Borneq <borneq@antyspam.hidden.pl>: Jan 30 10:30PM +0100

If GnuC have macro that put to code info about current git commit hash?
scott@slp53.sl.home (Scott Lurndal): Jan 30 09:49PM

>If GnuC have macro that put to code info about current git commit hash?
 
gcc -DGIT_HASH=$(git rev-parse HEAD) source-file.c
Vir Campestris <vir.campestris@invalid.invalid>: Jan 30 09:52PM

On 30/01/2018 21:30, Borneq wrote:
> If GnuC have macro that put to code info about current git commit hash?
 
Completely off-topic here. But you may be able to do it with a "git
commit hook".
 
Andy
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 30 06:36AM

On Mon, 2018-01-29, Chris M. Thomasson wrote:
>> programs. AFAIK node.js supports those.
 
> Using memory mapped files for "fast" inter-process communication can be fun.
 
> ;^)
 
I don't know what the smiley implies, but IME memory-mapped files for
IPC is easy to get wrong. It's not my first choice.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Jan 29 10:55PM -0800

On 1/29/2018 10:36 PM, Jorgen Grahn wrote:
 
>> Using memory mapped files for "fast" inter-process communication can be fun.
 
>> ;^)
 
> I don't know what the smiley implies
 
It implies hand crafted atomic data-structures to get some things correct.
 
 
> but IME memory-mapped files for
> IPC is easy to get wrong. It's not my first choice.
 
Hard to disagree with that!
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Jan 29 11:18PM -0800

On 1/29/2018 10:55 PM, Chris M. Thomasson wrote:
 
>> but IME memory-mapped files for
>> IPC is easy to get wrong.  It's not my first choice.
 
> Hard to disagree with that!
 
Fwiw, gotta love WAIT_ABANDONED for windows:
 
https://msdn.microsoft.com/en-us/library/windows/desktop/ms687032(v=vs.85).aspx
 
or EOWNERDEAD wrt POSIX.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 30 07:37PM

On Tue, 2018-01-30, Chris M. Thomasson wrote:
...
> or EOWNERDEAD wrt POSIX.
 
Sounds like the excuse for putting a dog to sleep. I still prefer EIEIO.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
red floyd <dont.bother@its.invalid>: Jan 30 12:29PM -0800

On 1/30/2018 11:37 AM, Jorgen Grahn wrote:
> ...
>> or EOWNERDEAD wrt POSIX.
 
> Sounds like the excuse for putting a dog to sleep. I still prefer EIEIO.
 
Isn't that a PIC-32 instruction?
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Jan 30 01:24PM -0800

On 1/30/2018 12:29 PM, red floyd wrote:
 
>> Sounds like the excuse for putting a dog to sleep.  I still prefer EIEIO.
 
> Isn't that a PIC-32 instruction?
 
A PowerPC instruction eieio?
 
https://en.wikipedia.org/wiki/Enforce_In-order_Execution_of_I/O
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jan 30 06:31AM -0800

Christianity divides people into two groups:
 
Saved
Unsaved
 
All who are of the truth are led internally by God to come to His Son,
repent, ask forgiveness for their sin, and they receive salvation.
The rest remain firmly where they are, in sin, believing whatever lie
they are willing to believe, and they are already condemned to Hell:
 
https://www.biblegateway.com/passage/?search=John+3%3A18&version=KJV
 
18 He that believeth on him is not condemned: but he that believeth
not is condemned already, because he hath not believed in the
name of the only begotten Son of God.
 
God is dividing people based on their own revelation of who they are.
He is putting those who will be saved on one side, and those who will
be cast into the fire on the other:
 
https://www.biblegateway.com/passage/?search=Matthew+13%3A24-30&version=KJV
 
Jesus created all men properly:
 
24 Another parable put he forth unto them, saying, The kingdom
of heaven is likened unto a man which sowed good seed in his
field:
 
Men loved sin more than keeping God's word and obeying His guidance,
so they let in all manner of false doctrine into their societies,
all given them as alternate ways to go by the enemy (Satan):
 
25 But while men slept, his enemy came and sowed tares among
the wheat, and went his way.
26 But when the blade was sprung up, and brought forth fruit,
then appeared the tares also.
 
This was known to God, and there were inquiries about what should
be done?
 
27 So the servants of the householder came and said unto him,
Sir, didst not thou sow good seed in thy field? from whence
then hath it tares?
28 He said unto them, An enemy hath done this. The servants
said unto him, Wilt thou then that we go and gather them up?
 
God knew that to take the evil (tares) up now would potentially
also take up some of the good, so they are all allowed to grow up
together, so that when they are fully mature (when they have fully
revealed their own character by their own choices, beliefs, and
actions), then they can be easily identified:
 
29 But he said, Nay; lest while ye gather up the tares, ye root
up also the wheat with them.
 
The wheat (those who believe the truth and are of God) will remain,
and be pulled into the barn (Heaven), but those who are not of God
will be gathered together separately so they can be burned (in Hell):
 
30 Let both grow together until the harvest: and in the time of
harvest I will say to the reapers, Gather ye together first
the tares, and bind them in bundles to burn them: but gather
the wheat into my barn.
 
-----
People think Christianity is a joke because there are so many false
Christians running around, doing as the world does, believing as the
world does, not living the way God calls us to live. It's so per-
vasive that those like me who stand up and teach the way we're sup-
posed to be are ridiculed to scorn, mocked by the very sin the Lord
warned us would harm us here in this world through those who follow
after that sin, being unwilling to seek the truth.
 
-----
You are on one of two roads today: The road to Heaven, or the road
to Hell. Which road you are on depends ENTIRELY upon what you do
with Jesus Christ.
 
--
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jan 30 05:34PM

Christianity is a gas; a bit like methane. God is also a gas but more
like hydrogen.
 
--
 
Thank you,
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jan 30 09:47AM -0800

On Tuesday, January 30, 2018 at 9:32:07 AM UTC-5, Rick C. Hodgin wrote:
> with Jesus Christ.
 
> --
> Rick C. Hodgin
 
You will know the posts of the real Rick C. Hodgin and those employing
identity theft to make it seem like they are me by the headers. In
Google Groups, click on the down-arrow on each message, then choose
the "Show original" option. Do this on my posts, and on other people's
posts, and you will see who is impersonating me, and who is really me.
 
I also put the "[Jesus Loves You]" tag on each post. It would be great
if the impersonators did that as well, but the purpose of their message
is to be harmful and hateful, so I doubt the "[Jesus Loves You]" tag
will be there.
 
--
Rick C. Hodgin
ram@zedat.fu-berlin.de (Stefan Ram): Jan 30 02:16PM

I have a version of GCC here that is not too old and does not
give an error message for the code below.
 
void f(){}
//int f();
int main() { int f(); }
 
It /does/ give an error message when »//« is removed, however.
I also have a version of clang, giving an error message for the
code above.
Cholo Lennon <chololennon@hotmail.com>: Jan 30 09:52AM -0300

On 30/11/17 05:05, Öö Tiib wrote:
> other namespace named "std".
 
> I would buy if you said that "::std" is beautiful for your eyes
> but as "defense" it is clearly pointless erosion of colon key.
 
+1
 
Totally agree.
 
 
--
Cholo Lennon
Bs.As.
ARG
Robert Wessel <robertwessel2@yahoo.com>: Jan 29 08:48PM -0600

On Mon, 29 Jan 2018 17:35:49 +0000, Mr Flibble
 
>> Thanks for reminding me that the earliest UIs where flat! I'd forgotten.
 
>The earliest UIs had a major design constraint: they had to look good on
>monochrome displays.
 
 
Low resolution and 16-color displays pretty much also required a
flat-ish approach.
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)