Thursday, February 11, 2021

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

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 11 01:45PM -0800

On 2/11/2021 5:32 AM, Melzzzzz wrote:
> struct xxxx;
> us fucking dns api in stdafx
> and my Data, 1 obj file, and ms Data other dll.
 
Wow. Imvho, the compiler should feel like puking it guts out. Yet it
hides this from you. Just, wow.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 11 01:46PM -0800

On 2/11/2021 5:34 AM, Melzzzzz wrote:
 
> Fucking morons. They forward declare struct Data; in header which
> every GUI file includes, that is precompiled header.
 
> Bunch of amateurs.
 
Damn. Shit happens? ;^o
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 11 01:48PM -0800

On 2/11/2021 4:36 AM, Sam wrote:
 
> A one definition rule violation is undefined behavior, no diagnostic
> required. If a compiler/linker manages to detect it, consider it just as
> an extra bonus. However the standard does not require a diagnostic.
 
This is an odd one to me. This seems like a place where a warning should
be highly advised. Heck, even a warning shall be emitted to properly
inform the user seems okay with me.
Vir Campestris <vir.campestris@invalid.invalid>: Feb 11 09:58PM

On 11/02/2021 21:48, Chris M. Thomasson wrote:
> This is an odd one to me. This seems like a place where a warning should
> be highly advised. Heck, even a warning shall be emitted to properly
> inform the user seems okay with me.
 
I got bitten by one of those recently. Two files instantiated a template
with a template parameter of the same name. We're trying to reduce the
amount of conditional compilation across platforms, so I changed it to
compile them both. It picked one of the two instantiations. Silently :(.
 
Andy
Ben Bacarisse <ben.usenet@bsb.me.uk>: Feb 11 11:19PM


> On 2/11/2021 4:36 AM, Sam wrote:
<cut>
>> diagnostic.
 
> This is an odd one to me. This seems like a place where a warning
> should be highly advised.
 
I don't think anyone disputes that. The trouble is that it is hard in
general, so it is left up to implementations to do the best they can.
 
For example, in one file:
 
#include <iostream>

struct data { int i; };

void inc(data &d);

int main()
{
data d = { 42 };
inc(d);
std::cout << d.i << "\n";
}
 
and in another:
 
struct data { float i; };
 
void inc(data &d) { d.i += 1; }
 
C and C++ have always shied away from requireing disgnostics for
conditions that can only be detected at link time.
 
> Heck, even a warning shall be emitted to properly inform the user
> seems okay with me.
 
The problem is that many implementations would struggle to get that to
work in every case. In fact, with templates, it might even be
uncomputable. (I'd have to think on that some more.)
 
--
Ben.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 11 03:16PM -0800

On 2/11/2021 11:55 AM, Alf P. Steinbach wrote:
 
>> He is hyper smart... Big time.
 
> And a free book! Great! Except... I'm not so much into shared memory
> parallel programming, but others here may be.
 
Indeed Alf! Thanks for taking a look.
Brian Wood <woodbrian77@gmail.com>: Feb 11 02:34PM -0800

On Monday, February 8, 2021 at 6:40:07 AM UTC-6, Manfred wrote:
> Since the entire header, including functions and types, constitutes the
> interface to the module, I'd say that it's probably a good idea to
> handle both as part of one entity and 'extern "C"' all of it.
 
I decided to go that route and enlarged what's covered by the
extern "C". Also changed this:
 
#if QLZ_COMPRESSION_LEVEL == 1 || QLZ_COMPRESSION_LEVEL == 2
struct qlz_state_decompress
{
#if QLZ_STREAMING_BUFFER > 0
unsigned char stream_buffer[QLZ_STREAMING_BUFFER];
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)