Sunday, May 16, 2021

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

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 16 03:08PM -0700

On 5/5/2021 6:27 PM, Chris M. Thomasson wrote:
>> executes COFF object files that have not been linked to libraries.
 
> Iirc, you mentioned that you did not create the simulator/emulator?
> Right? What one are you using?
 
What simulator are you using?
Bonita Montero <Bonita.Montero@gmail.com>: May 16 06:10PM +0200

https://www.fluentcpp.com/2017/06/09/search-set-another-type-key/
I'm asking myself whether is_transparent is actually necessary.
The additional lookup-overloads could be generally activated and
there would be an error if ther wouldn't be a proper calling-ope-
rator for a certain key-type.
"Öö Tiib" <ootiib@hot.ee>: May 16 10:54AM -0700

On Sunday, 16 May 2021 at 19:10:56 UTC+3, Bonita Montero wrote:
> The additional lookup-overloads could be generally activated and
> there would be an error if ther wouldn't be a proper calling-ope-
> rator for a certain key-type.
 
Note that extremely dynamic containers like std::[multi]set,
std::[multi]map and std::list are used in real applications only in
less performance-critical places that tend to be less tested
places and more easily breaking places.So is_transparent was
most likely for not to add silently changed behavior to those
places.
 
Pre-C++14 code most often has implicit conversion from
value to key object to achieve perceived transparency. So value we
want to search does convert into one "probe object" of Key type
and that is used for searching using
operator()(Key const&, Key const&) of Compare.
Now user has to indicate that he wants other operator()
overloads in Compare to be used instead, otherwise the change
can surprise break our code silently.
Bonita Montero <Bonita.Montero@gmail.com>: May 16 08:01PM +0200

> Now user has to indicate that he wants other operator()
> overloads in Compare to be used instead, otherwise the
> change can surprise break our code silently.
 
How could is_transparent prevent that ? If there's a conversion
-operator for the key-type different from the native key of the
map to the native-key, that conversion is done before any lookup
functions are called.
"Öö Tiib" <ootiib@hot.ee>: May 16 11:29AM -0700

On Sunday, 16 May 2021 at 21:01:58 UTC+3, Bonita Montero wrote:
> -operator for the key-type different from the native key of the
> map to the native-key, that conversion is done before any lookup
> functions are called.
 
Compare is injected to std::set compile time, if it has
is_transparent member is also evaluated compile time and
based to that is decided what members the set has. So
when there are template overloads that match better then
conversion is not done but instead the template is
called that calls the other operator() of Compare. But if the
is_transparent was missing then the template members of
set are also missing so it behaves like it did before.
Bonita Montero <Bonita.Montero@gmail.com>: May 16 05:57AM +0200

STOP POSTING in comp.lang.c/c++ !!!
olcott <NoOne@NoWhere.com>: May 15 11:29PM -0500

On 5/15/2021 10:57 PM, Bonita Montero wrote:
> STOP POSTING in comp.lang.c/c++ !!!
No
 
--
Copyright 2021 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
Bonita Montero <Bonita.Montero@gmail.com>: May 16 10:11AM +0200

>> STOP POSTING in comp.lang.c/c++ !!!
 
> No
 
You don't post anything related specifically to C or C++,
so stop postingg here.
olcott <NoOne@NoWhere.com>: May 16 08:43AM -0500

On 5/16/2021 3:11 AM, Bonita Montero wrote:
 
>> No
 
> You don't post anything related specifically to C or C++,
> so stop postingg here.
 
Everything that I post to is directly related to the correctness of
the following C code: (executed in the x86utm OS written in C and C++)
 
void H_Hat(u32 P)
{
u32 Input_Halts = Halts(P, P);
if (Input_Halts)
HERE: goto HERE;
}
 
int main()
u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);
Output("Input_Would_Halt = ", Input_Would_Halt);
}
 
When the behavior of the input Ĥ to simulating halt decider H
(a) correctly matches
(b) a correct non-halting behavior pattern
then H decides non-halting on Ĥ correctly.
 
Halts returns 0 on the basis that the behavior of H_Hat matches
the [infinitely_nested_simulation] not halting behavior pattern.
 
If the above C code is correct then this proves that all
the conventional halting problem instances can be decided
as not halting. The following is from Peter Linz:
 
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
 
H.qx wM wM ⊢* H.qy
H.qx wM wM ⊢* H.qn
 
H applied to input (Ĥ, Ĥ) transitions to H.qn on the basis that
the behavior of Ĥ matches the [infinitely_nested_simulation]
not halting behavior pattern.
 
http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
 
 
 
http://www.liarparadox.org/Halting_problem_undecidability_and_infinitely_nested_simulation.pdf
 
--
Copyright 2021 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
Bonita Montero <Bonita.Montero@gmail.com>: May 16 06:02PM +0200

> Everything that I post to is directly related to the correctness of
> the following C code: (executed in the x86utm OS written in C and C++)
 
You're problems are generic for most languages.
You don't write about specific C- or C++-problems.
So please stop posting 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)