Sunday, April 28, 2019

Digest for comp.lang.c++@googlegroups.com - 9 updates in 3 topics

"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 28 11:51PM +0200

On 28.04.2019 17:41, Tim Rentsch wrote:
> [snippety] In C++, _any_ program execution
> can arbitrarily misbehave, because 'resource limits' can be
> anything at all.
 
Yes.
 
As an absurd case an implementation might define type `bool` with a size
exceeding available memory. A main function with a local `bool` variable
and nothing else, could then incur Undefined Behavior.
 
 
> Definedness of behavior is about what /should/
> happen, not about what actually /will/ happen.
 
UB is about the formal hands-off area, where no requirements are imposed.
 
And vice versa.
 
When you have no rules you have UB, and when you have UB you have no rules.
 
It's actually worse. UB can be retroactive. Because, since UB is so bad,
a compiler is free to assume that UB will not occur, e.g. assuming that
a variable will never have some particular value, because that would
give UB -- then it can "optimize" away much that the programmer ordered,
and it can even produce very noticeable effects that were not ordered
and clearly not desired.
 
And that is often far too strong to appear /meaningful/ at first glance,
like getting the death penalty for jaywalking. Wtf., I'm to be executed
in the common American half-hour death struggle way for jaywalking with
no cars in sight? UB is just so much too strong that the examples in
$5/4 in C++98 and its bugfix (a.k.a. technical corrigendum) C++03 had
comments that these expressions had just unspecified effect, as if the
author, presumably Andrew Koenig, just couldn't believe the UB penalty.
 
Happily the examples and comments were non-normative text.
 
 
> Yes, running out
> of stack can result in arbitrary misbehavior. But that doesn't
> mean the standard didn't say what should have happened.
 
It doesn't.
 
It /explicitly/ doesn't say what should have happened.
 
It states that if the resource limits are not exceeded, then and only
then must the code be executed correctly; otherwise it's no
requirements, which is also known as UB-land.
 
 
>> actual effect that when I arrived at the doctor's I was all fine.
 
> I hope you have now gotten through that and are feeling much
> better.
 
Thanks, currently better, but it turned out that that little bastard was
merely hiding, redoubled it's torture efforts later, and the scans
showed that it had a brother that may become problematic (or for all I
know may already be out of my system, though Murphy's law says no).
 
 
Cheers!,
 
- Alf
Daniel <danielaparker@gmail.com>: Apr 28 11:08AM -0700

On Sunday, April 28, 2019 at 1:29:35 PM UTC-4, Bonita Montero wrote:
> > the case in C and C++. Also, import is not the same as include.
 
> We shoud drop discussing doing "using" in an include-file since no one
> with a clear mind would do that.
 
Agreed, in my posts I have always assumed the context is .cpp files.
 
Daniel
"Öö Tiib" <ootiib@hot.ee>: Apr 28 11:13AM -0700

On Sunday, 28 April 2019 20:27:32 UTC+3, Bonita Montero wrote:
> > within one code file. In C++ however everything else gets
> > damaged by that include file from yet another noob coming from Java.
 
> No serious C++-developer would use using in a C++-header.
 
How so? Most C++ library classes in header are full of that.
Lets take a random container:
 
namespace project {
namespace module {
 
class container {
using value_type = blah;
using allocator_type = bla_blah;
using reference = bleh;
// etc. const_reference, iterator, const_iterator, size_type
// difference_type, pointer, const_pointer TL;DR;
 
// code starts only page later
};
}
}
 
Just peek into boost or something. For me that is fine when
container::value_type happens to be std::string. What feels like
nonsense is when container::string happens to be std::string.
WTF is container's string? That is brain damage squared and
does not make any sense.
Bonita Montero <Bonita.Montero@gmail.com>: Apr 28 08:20PM +0200

> How so? Most C++ library classes in header are full of that.
 
I think you understood which type of using I meant.
Daniel <danielaparker@gmail.com>: Apr 28 11:30AM -0700

On Sunday, April 28, 2019 at 2:13:20 PM UTC-4, Öö Tiib wrote:
 
> How so?
 
I was assuming Bonita meant "using namespace"
 
Daniel
Paavo Helde <myfirstname@osa.pri.ee>: Apr 28 09:33PM +0300

On 27.04.2019 19:23, Bonita Montero wrote:
>> And where exactly are you going to search for its documentation, if you
>> don't even know if it's a custom function or a standard library function?
 
> I right-click at the symbol in my IDE and then click "go to definition".
 
In my IDE this works ... over half of the time. That's actually much
better than 10 years ago, when it almost never worked.
 
When it does not work, then the last version of the IDE has developed a
nasty habit to bring me to a wrong definition of the same symbol in a
totally unrelated project. Earlier versions at least did fail honestly.
 
Even if it worked reliably, it's more hassle for the reader than needed.
Why should I click, wait and verify that a symbol comes from std::?
Write it down, plain and simple!
"Öö Tiib" <ootiib@hot.ee>: Apr 28 11:41AM -0700

On Sunday, 28 April 2019 21:30:14 UTC+3, Daniel wrote:
> On Sunday, April 28, 2019 at 2:13:20 PM UTC-4, Öö Tiib wrote:
 
> > How so?
 
> I was assuming Bonita meant "using namespace"
 
Oh, using namespace I have learned to dislike everywhere.
"using x = y;" or "namespace bs = cattle::excrements;" are
fine but "using namespace std;" is just bad feature regardless
where.
Vir Campestris <vir.campestris@invalid.invalid>: Apr 28 09:44PM +0100

On 28/04/2019 16:51, Öö Tiib wrote:
> size_t or wchar_t has been source of some unexpected work over the
> years and so those are better to be used specially for performance
> optimization.
 
I boobed again. I should have said "same ABI".
 
Andy
Paavo Helde <myfirstname@osa.pri.ee>: Apr 28 09:44PM +0300

On 28.04.2019 20:28, Juha Nieminen wrote:
 
> std::shared_ptr *itself*, however, is not thread-safe.
 
> This confuses me a bit. Exactly which member functions are safe to be
> called from threads and in which situations?
 
The potentially unsafe methods are the ones which change the pointer
value, i.e. assignment, swap, etc.
 
> visible to all threads. Am I correct to assume that doing this in
> two different threads is safe?
 
> std::shared_ptr<Type> localPtr = commonPtr;
 
This line is safe as localPtr is either an automatic variable which is
not visible to other threads, or a namespace-level static whose
initialization is single-threaded.
 
> while doing this is not:
 
> commonPtr = localPtr;
 
Correct, if commonPtr is visible to multiple threads you will need some
kind of locking here.
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)