Sunday, April 28, 2019

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

Juha Nieminen <nospam@thanks.invalid>: Apr 28 05:28PM

The control block used by std::shared_ptr is thread-safe. This means
that if two different std::shared_ptr objects in two thread share
the same control block and both try to modify it (eg. its reference
count), no problems will happen.
 
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?
 
Suppose we have a std::shared_ptr<Type> object named commonPtr somewhere,
visible to all threads. Am I correct to assume that doing this in
two different threads is safe?
 
std::shared_ptr<Type> localPtr = commonPtr;
 
while doing this is not:
 
commonPtr = localPtr;
"Öö Tiib" <ootiib@hot.ee>: Apr 28 10:51AM -0700

On Sunday, 28 April 2019 20:28:24 UTC+3, 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?
 
Same as with everything. If you want to write it from at least one
thread while accessing (does not matter if reading or writing) from
any other thread then you have race condition. So you have
to put locks around it.
 
> visible to all threads. Am I correct to assume that doing this in
> two different threads is safe?
 
> std::shared_ptr<Type> localPtr = commonPtr;
 
Yes, assuming that no other thread is writing commonPtr.
 
> while doing this is not:
 
> commonPtr = localPtr;
 
Here thread is writing commonPtr so any other thread accessing it
is UB.
Melzzzzz <Melzzzzz@zzzzz.com>: Apr 27 11:34PM


> How about just 'byte'? That's a little more snappy. Can't be many people
> who don't know what a byte is (they will know it's 8 bits, and I believe
> more regard it as unsigned than signed).
 
u8 is shorter.
 
 
--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Marko Marin
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
Bart <bc@freeuk.com>: Apr 28 01:09AM +0100

On 28/04/2019 00:34, Melzzzzz wrote:
>> who don't know what a byte is (they will know it's 8 bits, and I believe
>> more regard it as unsigned than signed).
 
> u8 is shorter.
 
That too. But 'byte' matches how you might write or talk about such a
type in English: 'byte array' rather than 'u8 array' or 'uint_fast8_t
array'. And this type is also how storage is measured: it's the 'B' in 'GB'.
"Öö Tiib" <ootiib@hot.ee>: Apr 28 08:51AM -0700

On Friday, 26 April 2019 23:30:55 UTC+3, Vir Campestris wrote:
> to be the normal ones.
 
> I also suspect that the DSP people with ridiculously large numbers make
> up more than 0.01%. If you'd said 99% I'd let you have it.
 
In my experience the code on 16 bit platforms is pure C now. C++ is used
only on 32 or 64 bit platforms. We did use C++ more on 16 bit platforms
before standardization of C++ but those have been gradually upgraded
to 32 bits or gone out of sale. That is why I proposed 99.99% but there
sure can be massive (and slower evolving) target domains about what I
know nothing.
 
> was talking to Java) so long as the interface says int, and both ends
> are on the same compiler and CPU int won't cause a problem. It's the
> change that hit you.
 
What has just single processor and single compiler? Some stand-alone
"smart" sensor? These are trivial. If there is something to program then
it consists of 3 - 10 controllers/processors, half of whose are optional.
Then it is lucky case when only 2 tool-chains are used for compiling
whole product. The devops push that unit tests should run on MinGW
too so they can auto-check all the pull-requests without flashing farms
of real devices. Other projects have to interact with pieces written in
other languages like Java, C#, Python and/or PHP. Each of int, long,
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.
"Öö Tiib" <ootiib@hot.ee>: Apr 28 09:07AM -0700

On Sunday, 28 April 2019 02:05:10 UTC+3, Bart wrote:
 
> How about just 'byte'? That's a little more snappy. Can't be many people
> who don't know what a byte is (they will know it's 8 bits, and I believe
> more regard it as unsigned than signed).
 
Unfortunately byte is taken since C++17.
https://en.cppreference.com/w/cpp/types/byte
It is enum with size of byte on current platform.
Someone naming something as "byte" locally would cause again
that confusion if it is shortcut for "std::byte" or some local
typedef of something else and why it is there.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Apr 28 09:11AM -0700

> characters saved when first entering the code, and both IDEs and
> editors tend to have pretty good auto-complete when entering code
> these days anyway.
 
I see this kind of comment from time to time. It's a straw man
argument. If I choose a shorter or more concise name, I don't
do that to save time typing the program. Rather, what motivates
me is a desire to make it easier to read the program. No
sensible person chooses names (or any other program phrases)
just because they are easier to type.
Bonita Montero <Bonita.Montero@gmail.com>: Apr 28 06:24PM +0200

In Java _every_ developer uses import of certain symbols or even
wildcarded imports of whole packages. No one would lead such brain
-damaged discussions in the Java-world.
"Öö Tiib" <ootiib@hot.ee>: Apr 28 09:54AM -0700

On Sunday, 28 April 2019 19:25:01 UTC+3, Bonita Montero wrote:
> In Java _every_ developer uses import of certain symbols or even
> wildcarded imports of whole packages. No one would lead such brain
> -damaged discussions in the Java-world.
 
It is because in Java they import the names locally for usage within
one code file. In C++ however everything else gets damaged by
that include file from yet another noob coming from Java.
Especially because they want to write all their typical inefficient
crap header-only. Java is not bad language. In good hands it is
only about 4 times less efficient. Why they want to write C++?
Their C++ programs are at least twice inferior to what their Java
was.
Daniel <danielaparker@gmail.com>: Apr 28 10:23AM -0700

On Sunday, April 28, 2019 at 12:25:01 PM UTC-4, Bonita Montero wrote:
> In Java _every_ developer uses import of certain symbols or even
> wildcarded imports of whole packages. No one would lead such brain
> -damaged discussions in the Java-world.
 
There isn't a discussion, Bonita, comp.lang.c++ doesn't have discussions,
rather, people make statements.
 
Regarding use of symbols, it's the same in .NET. And it works, occasionally
there is an assembly with a duplicate name, but it's easily disambiguated.
But there are some difference. In Java and .NET, there is an additional
level of scoping for almost everything in the class name, while that's not
the case in C and C++. Also, import is not the same as include. So there is
a lot more opportunity for name leakage in C and C++ than in Java and .NET.
 
As an aside, programming styles in Java or .NET tend to follow models set in
the language documentation, tutorials and examples, so there is much
uniformity, while in C++, that's almost never the case. So for instance,
Boost tutorials use
 
using namespace boost::filesystem;
 
while that would make many people here cross.
 
Daniel
Bonita Montero <Bonita.Montero@gmail.com>: Apr 28 07:27PM +0200

> It is because in Java they import the names locally for usage
> 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.
Bonita Montero <Bonita.Montero@gmail.com>: Apr 28 07:29PM +0200

> But there are some difference. In Java and .NET, there is an additional
> level of scoping for almost everything in the class name, while that's not
> 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.
Bonita Montero <Bonita.Montero@gmail.com>: Apr 28 07:34PM +0200

>> 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.
 
(except in tamplated / inlined functions)
Juha Nieminen <nospam@thanks.invalid>: Apr 28 05:23PM

> How to write program to find bonus?
> I'm beginner to learn c++. I have working hours and bonus but i can't write code? How i do?
 
Are you seriously and honestly expecting us to understand *at all*
what you are asking?
Tim Rentsch <tr.17687@z991.linuxsc.com>: Apr 28 08:41AM -0700

>> ss( unsigned n, unsigned r ){
>> return n ? ss( n-1, r + n*n ) : r;
>> }
 
[skip tangential remark]
 
>> which part(s) do you not agree with?
 
> I agree. It's UB with most (all?) implementations because it
> exceeds implementation limit on stack space.
 
This statement is not consistent with how undefined behavior is
defined. For undefined behavior to be present, one of three
things must be true:
 
(1) "Undefined behavior" must be explicitly identified in the
semantic description of an encounted construct; or
 
(2) A rule must be violated (in C these are called "shall" or
"shall not" requirements; in C++ these are the rules explicitly
labelled "no diagnostic is required") in an encountered
construct; or
 
(3) A requested operation must lack any explicit definition of
behavior.
 
(C++ expresses these differently but is meant to express the
same idea AFAICT.)
 
None of the above circumstances holds in this case: there is no
explicit indication of undefined behavior; no shall or shall not
requirements (or "no diagnostic is required" rules) are violated;
and every operation encounted has an explicit definition for its
behavior. So there cannot be undefined behavior in the above
program.
 
 
> Now I don't recall exactly what the discussion was about, or what
> positions were held by whom, but there are some points I think are
> relevant.
 
[two points following in reverse order relative to the original]
 
> blinking the NumLock light for a millisecond as a "diagnostic", then
> a compiler can do that non-blink and then accept any language
> extensions whatsoever.
 
Certainly there are cases where the C or C++ standards are vague
in their meanings, and also places where the meaning is pretty
clear but the wording needs improving. Here I think the C
standard is pretty good and the C++ wording is not as good as
that in the C standard, but in both cases the intended meaning is
crisp enough so no guessing is needed. Do you think the C
standard defines "undefined behavior" clearly enough? If not, in
what way? If so, does the C++ notion of "undefined behavior"
match the C notion of "undefined behavior"? If not, how are they
different?
 
To be clear, I think the C standard does define "undefined
behavior" clearly enough for present purposes, and I am using the
term "undefined behavior" to mean the same thing in C++ as in C
(which I assume is also true for other participants in the
discussion, so I really would like to hear an explicit statement
to the contrary for anyone for whom that is not the case).
 
 
> exceeds the resource limits, the implementation isn't obliged to
> execute it correctly. Since the standard places no requirements on
> what happens then, for incorrect execution, that's formally UB.
 
I think you are confusing two related but distinct conditions.
If a program doesn't violate any C++ rules but does exceed the
resource limits of the execution environment (such as stack
overflow), then there are no guarantees about what happens for
(subsequent) program execution. But there is a requirement on
the implementation, namely section 4.1p2.1 itself. In contrast,
the condition of undefined behavior corresponds to 4.1p2.3:
 
(2.3) If a program contains a violation of a rule for which
no diagnostic is required, this International Standard
places no requirement on implementations with respect
to that program.
 
The "no requirement" dictum also includes p2.1 (which explicitly
disqualifies itself anyway, because a rule has been violated),
as p2.1 places a requirement on implementations.
 
After talking this over with a few people, I have an idea about
what is causing the problem here. A consequence of undefined
behavior is that program execution may arbitrarily misbehave.
People familiar with the C standard or C++ standard have
internalized this result to the point where sometimes they think
of the two as synonymous. But the implication doesn't go the
other way. If I'm running a strictly conforming program on a
computer that catches fire, for sure the program execution can
arbitrarily misbehave. But that doesn't mean the program has
undefined behavior. Similarly, a program that runs out of stack
can arbitrarily misbehave, but that doesn't change whether the
standard defines the behavior. In C++, _any_ program execution
can arbitrarily misbehave, because 'resource limits' can be
anything at all. Definedness of behavior is about what /should/
happen, not about what actually /will/ happen. Yes, running out
of stack can result in arbitrary misbehavior. But that doesn't
mean the standard didn't say what should have happened. If the
standard says what should happen, then there is no undefined
behavior, no matter what actually happens when the program is
run.
 
 
>> differences between the two please say what those are and why.)
 
> Well, at this late point it could help if you would state what the
> conclusion you arrived at, is.
 
I have tried to spell them out in more detail in my comments
above.
 
> but that had only marginal effect. Happily it gave up after just
> half an hour or so, but possibly deviously, with the intent and
> 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.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Apr 28 08:45AM -0700


> FWIW, this program appears to compile and run properly in MSVC 2017
> Release x64 build, and produces output:
 
> result is 2147483648
 
Not surprising; probably the compiler is optimizing the tail
call to a jump, giving a "stackless recursion".
 
Thank you for running the trial.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Apr 28 08:55AM -0700

>> If so then which constructs and which passages define
>> those constructs?
 
> no
 
Excellent, answers are all quite understandable.
 
>> then which questions?
 
> Not to my knowledge. May be there are some tiny issue
> somewhere that I did not notice but it does not matter.
 
Okay, good.
 
>> didn't answer my questions. [skip language suggestions]
 
> Yes, I learned some English only after having some skill in
> three other languages. I do not think the issue is in language.
 
I'm not always sure if you understand what I'm saying partly
because I don't always understand what you are saying. In other
words even if it isn't a problem for you sometimes it is a
problem for me. But I think we have gotten around that for this
posting.
 
> So conforming implementations of C and C++ should accept
> and execute those programs within their resource limits.
> On case of exceeding these limits the behavior is undefined.
 
Your last statement is in conflict with your previous answers.
I think you are confusing two different ideas in the same way
that I explained in the response to Alf's posting. If you
could, please read that response and see if it makes sense to
you.
"Öö Tiib" <ootiib@hot.ee>: Apr 28 09:41AM -0700

On Sunday, 28 April 2019 18:56:06 UTC+3, Tim Rentsch wrote:
> that I explained in the response to Alf's posting. If you
> could, please read that response and see if it makes sense to
> you.
 
I do not think your answer to Alf addresses my chain of logic.
On the contrary it seems to avoid that logic and so it can not
be my language comprehension issue. My chain of logic
is simple:
 
1) An undefined behavior is behavior for which this
International Standard imposes no requirements.
 
2) Conforming implementations are required to accept
and execute correct programs within their resource limits.
 
We can not find any place where the standard imposes
any requirements to implementation when the resource
limits are exceeded. And substituting from 1) it is therefore
undefined behavior when the resource limits are exceeded.
 
Also we have plenty of examples of programming
languages where exceeding of resource limits is not
undefined behavior because these have behavior that
is defined on those cases unlike C++.
 
So what is wrong with that explanation?
Tim Rentsch <tr.17687@z991.linuxsc.com>: Apr 28 09:19AM -0700

> constexpr allows. If its a constant expression then by
> definition you know the value when you write the code so why
> not just have "static const int one = 1"?
 
There are several reasons one might choose to define a constexpr
value symbolically rather than putting in the constant value
directly:
 
(1) The value may be calculable in principle but non-trivial
to calculate in practice.
 
(2) The value may depend in some way on the value of some
other constexpr value that we anticipate changing in
the future.
 
(3) The value may depend on some implementation-defined
value so it isn't really constant but varies from
implementation to implementation.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Apr 28 09:24AM -0700

> constexprs. I can't help thinking that the compiler executing
> code at compile time could be an interesting avenue for obscure
> bugs and compile time crashes.
 
Keep in mind that the same result can be computed using C++11
constexpr. Changes in C++14 make constexpr functions more
convenient than in C++11, but in most cases what can be done
using constexpr functions in C++14 (or C++17) can also be done
in C++11.
peteolcott <Here@Home>: Apr 27 06:59PM -0500

On 4/27/2019 6:41 PM, peteolcott wrote:
>> and deep logic systems.
 
> I never said that dingle berry.
> I said that the Prolog inference model corresponds to the sound deductive inference model.
 
 
****************************************************************
QUIT BEING A JACKASS AND TAKE FIVE MINUTES TO STUDY IT !!!
****************************************************************
 
Axiom(0) Stipulates** this definition of Axiom:
Expressions of language defined to have the semantic value of Boolean True.
 
Stipulating** this specification of True and False:
Axiom(1) ∀F ∈ Formal_System ∀x ∈ Closed_WFF(F) (True(F, x) ↔ (F ⊢ x))
Axiom(2) ∀F ∈ Formal_System ∀x ∈ Closed_WFF(F) (False(F, x) ↔ (F ⊢ ¬x))
 
Stipulating** that formal systems are Boolean:
Axiom(3) ∀F ∈ Formal_System ∀x ∈ Closed_WFF(F) (True(F,x) ∨ False(F,x))
 
The following logic sentence is refuted on the basis of Axiom(3)
∃F ∈ Formal_System ∃G ∈ Closed_WFF(F) (G ↔ ((F ⊬ G) ∧ (F ⊬ ¬G)))
There is no sentence G of Formal System F that is neither True nor False in F.
 
Making the following paragraph false:
The first incompleteness theorem states that in any consistent formal
system F within which a certain amount of arithmetic can be carried out,
there are statements of the language of F which can neither be proved
nor disproved in F. (Raatikainen 2018)
 
 
 
Eliminating Undecidability and Incompleteness in Formal Systems
https://www.researchgate.net/publication/332427635_Eliminating_Undecidability_and_Incompleteness_in_Formal_Systems
 
--
Copyright 2019 Pete Olcott All rights reserved
 
"Great spirits have always encountered violent
opposition from mediocre minds." Albert Einstein
peteolcott <Here@Home>: Apr 27 07:44PM -0500

On 4/27/2019 7:10 PM, Paul Rubin wrote:
 
> OTOH, the OP says propositions are true (provable), false (the negation
> is provable), or unsound. If "unsound" just means "unprovable in the
> given theory", then fine, that's what I'm used to.
 
Within the sound deductive inference model unsound simply means not
provable and the negation is also not provable.
In other words if its not True or False then its Unsound.
 
> philosophical claim that the statement then doesn't have a truth value,
> so there is no such thing as an intended model. I can live with that,
> but the terminology is so weird and vague as to not have much meaning.
 
It is exactly the same thing as unsound in the deductive logical inference
model show below.
 
It excludes all of the expressions of language that would otherwise
show undecidability or inconsistency as simply deductively unsound.
The 1931 Incompleteness Theorem and the Tarski Undefinability Theorem
simply become false.
 
∃F ∈ Formal_System ∃G ∈ Closed_WFF(F) (G ↔ ((F ⊬ G) ∧ (F ⊬ ¬G)))
There is no sentence G of Formal System F that is neither True nor False in F.
 
> anyone to understand you. I liked Enderton's "A Mathematical
> Introduction to Logic" though it might be considered old-fashioned by
> onw.
 
I only mean this very simple idea, no textbook needed:
Validity and Soundness https://www.iep.utm.edu/val-snd/
A deductive argument is said to be valid if and only if it takes a form that makes it
impossible for the premises to be true and the conclusion nevertheless to be false.
Otherwise, a deductive argument is said to be invalid.
 
A deductive argument is sound if and only if it is both valid, and all of its premises
are actually true. Otherwise, a deductive argument is unsound.
 
--
Copyright 2019 Pete Olcott All rights reserved
 
"Great spirits have always encountered violent
opposition from mediocre minds." Albert Einstein
peteolcott <Here@Home>: Apr 27 07:48PM -0500

On 4/27/2019 7:16 PM, Spiros Bousbouras wrote:
>> today than when he wrote it in 1983; we have lots of computer systems to
>> shield cranks and save then postage.
 
> Dudley has written a whole book on the subject , "A budget of trisections".
 
The huge difference in this case is that deriving a complete and consistent
formulation of the notion of True finally anchors Truth Conditional Semantics.
https://en.wikipedia.org/wiki/Truth-conditional_semantics
 
 
 
--
Copyright 2019 Pete Olcott All rights reserved
 
"Great spirits have always encountered violent
opposition from mediocre minds." Albert Einstein
peteolcott <Here@Home>: Apr 27 09:38PM -0500

On 4/27/2019 8:52 PM, Paul Rubin wrote:
 
> I read Hofstadter's "Gödel, Escher, Bach: An Eternal Golden Braid" in HS
> and liked it a lot. It develops a version of the incompleteness theorem
> in a fun and quirky way. OP might like that one too.
 
Only this one single idea of logic is prerequisite:
 
Validity and Soundness https://www.iep.utm.edu/val-snd/
A deductive argument is said to be valid if and only if it takes a form that makes it
impossible for the premises to be true and the conclusion nevertheless to be false.
Otherwise, a deductive argument is said to be invalid.
 
A deductive argument is sound if and only if it is both valid, and all of its premises
are actually true. Otherwise, a deductive argument is unsound.
 
All dogs are mammals
All mammals breath
Therefore all dogs breath
 
Only because symbolic logic diverges for this simple model
is it possible to prove Gödel's Incompleteness or Tarski's Undefinability.
 
--
Copyright 2019 Pete Olcott All rights reserved
 
"Great spirits have always encountered violent
opposition from mediocre minds." Albert Einstein
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 28 01:47AM +0200

On 27.04.2019 20:09, jacobnavia wrote:
 
> The constructor of a view could add the view to a list of views in the
> string. The destructor of the string would fail if there are still views
> to it. For instance, maybe other methods wpould be preferable
 
Better to disallow /implicit/ construction of `string_view` from temporary.
 
With syntax like
 
const auto sv = string_view::temporary( s + "World\n" );
 
which is trivial to implement enforcement of, the problem would have
been very apparent.
 
However, requiring this explicitness for function call arguments would
IMO be impractical.
 
So for that it would be nice to have a `std::temp_string_view` type that
accepts both rvalue and lvalue constructor arguments.
 
An ordinary `std::string_view` would convert implicitly to
`std::temp_string_view`, but not vice versa.
 
---
 
Disclaimer: late in the day for me so there might be some problem with
my ideas here that I didn't think of.
 
 
Cheers!,
 
- Alf
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)