Saturday, February 3, 2018

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

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 ]
 
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)
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>
"James R. Kuyper" <jameskuyper@verizon.net>: Jan 31 02:09PM -0500

On 01/31/2018 09:09 AM, Manfred 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.
...
> definition of a function that matches the function /signature/ of f() -
> the key issue being that the function signature does not contain the
> function return type.
 
6.5p9 requires that the signatures match, only for determining whether
the two declarations identify the same function. 6.5p10 requires
declarations identifying the same function must have the same type, and
that's the "matching" that I was referring to that can't happen in this
case.
 
>> f() which is compatible with the block-scope declaration of f().
> This is not how I would understand it, since hidden names would not
> participate in overload resolution (because of 6.4 p1).
 
16.1p2 does not require that the issue ever come up as to which of the
two overloads should be used - it simply says that they should not both
exist.
 
...
> p9 states that both declarations of f() "shall denote the same function"
> and p9.1, 9.2 and 9.3 define this identity based on linkage, namespace
> and parameter list identity (i.e. function /signature/)
 
I noticed the "or" in 6.5p9.1, but didn't notice that p9.1, p9.2, p9.3
and p9.4 are all connected to each other by "and" - but that doesn't
change the results. Both declarations are in the same namespace, and
denote functions with the same parameter type lists, so 6.5p10
definitely applies, and definitely prohibits them from having different
types.
 
...
> To my understanding, this sums up to the following:
> - The program is ill-formed (because it violates 6.5 p10)
> - But the compiler is still compliant since "a diagnostic is not required".
 
Agreed.
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>
"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;
}
Ben Bacarisse <ben.usenet@bsb.me.uk>: Jan 29 03:59PM

>> different types of UI elements. Not only are user interfaces (and other
>> visual elements) becoming as ugly as possible, they are also becoming
>> less user-friendly.
 
Personally I much prefer flat UIs. I've favoured them (on web pages for
example) for a very long time. I don't have any data on usability, but
I suspect that if they are well-designed they are not too bad.
 
I don't like fake 3D at all, and I dislike fake wood, fake steel, fake
plastic and fake controls that look like my stereo even more! At least
all those seem to be a thing of the past.
 
>> be following that trend.
 
> Any screenshots? I'm afraid I use so few modern GUIs that I'm not
> quite sure what you mean.
 
For example:
 
http://www.bsb.me.uk/tmp/eg.png
 
I'm sure you've come across flat designs on web pages maybe without
realising.
 
--
Ben.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 29 02:59PM

On Mon, 2018-01-29, Juha Nieminen wrote:
> less user-friendly.
 
> And the strange thing is that every major software developer seems to
> be following that trend.
 
Any screenshots? I'm afraid I use so few modern GUIs that I'm not
quite sure what you mean.
 
Also annoying: modern web pages with lots of empty space and some
huge text. Possibly made for smartphones?
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Ben Bacarisse <ben.usenet@bsb.me.uk>: Jan 29 05:33PM

scott@slp53.sl.home (Scott Lurndal) writes:
<snip text on "flat" UIs>
 
> Personally, I've always been happy with X Athena Widgets myself. Simple
> and efficient.
 
Thanks for reminding me that the earliest UIs where flat! I'd forgotten.
 
--
Ben.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 31 07:56PM +0100

On 1/31/2018 5:52 PM, Richard wrote:
> high DPI displays). I find when I want to resize something I have to
> really carefully position the cursor in order to get a grip on the
> sizer.
 
Nothing to do with C++ but, just press Alt+Space and use the "move"
choice in the window menu.
 
That also works nicely for minimizing a fullscreen window.
 
 
Cheers & hth.,
 
- Alf (missing the old IBM keyboard guidelines (I don't even remember
the name))
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.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jan 31 02:18PM -0500

On 1/27/2018 1:38 PM, Mr Flibble wrote:
>> things where possible based on the indented parts?
 
> If you want me to engage with you with on topic discussion then you must
> first stop your off topic religious spam.
 
 
If you ever change your mind on this, I would be very keen on learning
about your kerning algorithm. I gather from your UI that it's custom.
I'd be interested in hearing your thinking on how/why you did it as
you have.
 
--
Thank you! | Indianapolis, Indiana | God is love -- 1 John 4:7-9
Rick C. Hodgin | http://www.libsf.org/ | http://tinyurl.com/yaogvqhj
-------------------------------------------------------------------------
Software: LSA, LSC, Debi, RDC/CAlive, ES/1, ES/2, VJr, VFrP, Logician
Hardware: Arxoda Desktop CPU, Arxita Embedded CPU, Arlina Compute FPGA
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 31 12:28PM

On Wed, 2018-01-31, Juha Nieminen wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>> Any screenshots?
 
I should explain that that didn't mean "I don't believe you" --
I was just wondering if it was the same kind of thing annoying me.
 
And it seems it was:
 
> an almost inexistent problem because window edges were much better
> visually defined and visible, and header bars actually looked like
> header bars, quite clearly distinct from the other window elements.
 
Ah, all that. Yes, the borders between things -- even between windows
-- seem to become more and more vague in Windows. I don't understand
why anyone would want that.
 
OTOH, I don't use Windows much, and I tend to force it to use a
"Classic" theme.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
red floyd <dont.bother@its.invalid>: Jan 31 09:42AM -0800

On 1/31/2018 4:28 AM, Jorgen Grahn wrote:
> why anyone would want that.
 
> OTOH, I don't use Windows much, and I tend to force it to use a
> "Classic" theme.
 
Because... "I'd better do something to justify my job... and...
"OOOH!! SHINY!!!!"
Juha Nieminen <nospam@thanks.invalid>: Jan 29 01:49PM

> My mistake. I completely missed that it and thought he was speaking
> about Leigh's implementation.
 
> I apologize, Juha.
 
I was indeed talking about the modern trend of making user interfaces to
be as simplistic, flat and mono-shaded and evenly-colored as possible,
sometimes even at the cost of usability. Sometimes that simplification
goes so far that it actually becomes hard to visually distinguish between
different types of UI elements. Not only are user interfaces (and other
visual elements) becoming as ugly as possible, they are also becoming
less user-friendly.
 
And the strange thing is that every major software developer seems to
be following that trend.
scott@slp53.sl.home (Scott Lurndal): Jan 29 04:35PM


> http://www.bsb.me.uk/tmp/eg.png
 
>I'm sure you've come across flat designs on web pages maybe without
>realising.
 
Personally, I've always been happy with X Athena Widgets myself. Simple
and efficient.
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 29 01:50PM -0800

On 1/29/2018 6:25 AM, Öö Tiib wrote:
> between processes feels inefficient hack.
 
> Make named pipes on Windows for communication between
> programs. AFAIK node.js supports those.
 
Using memory mapped files for "fast" inter-process communication can be fun.
 
;^)
"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!
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 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.
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
Christian Gollwitzer <auriocus@gmx.de>: Feb 04 12:33AM +0100

Am 03.02.18 um 22:11 schrieb Manfred:
 
> Any causes for malloc() to fail are simply out of the control of the
> programmer, hence the requirement for serious code to be prepared for
> its failure.
 
IOW, if you use malloc() you are a masochist, because you have to guard
every single little allocation with if() { printf("OOM"); exit(-1);} or
similar.
 
> unlikelihood, and ease handling of this situation, is to adopt a simple
> solution, so that "being prepared" often just means "abort with no
> further action".
 
The IMHO best solution is to stay away from C and use C++ new, which
handles this properly by throwing an exception. You only need to deal
with the out-of-memory case if you can really handle it, i.e. if you
catch it or ask for the nothrowing version; in most cases you simply
want the program to abort cleanly, which the exception handles for you.
 
Christian
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)