Tuesday, December 8, 2020

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

spuddy@isnotyourbuddy.co.uk: Dec 08 08:32AM

On Mon, 7 Dec 2020 22:34:08 +0000
>My biggest gripe is that you don't use "std::vector" but instead use "vector";
>namespaces where invented to make code easier to grok so please stop trying to
>defeat their purpose.
 
I disagree. I find <namespace>:: peppered all over the code annoying and messy.
There's a reason the "using" command was included as part of the standard.
"Öö Tiib" <ootiib@hot.ee>: Dec 08 04:09AM -0800

> >defeat their purpose.
> I disagree. I find <namespace>:: peppered all over the code annoying and messy.
> There's a reason the "using" command was included as part of the standard.
 
Whoosh.
Christian Gollwitzer <auriocus@gmx.de>: Dec 08 09:32PM +0100

Am 06.12.20 um 13:29 schrieb Jorgen Grahn:
 
> I find C++ a good choice for solving these. You'd think a language
> like Python would be better fit, but I've found no use for it yet.
> Perhaps that's just a sign my Python is rusty.
 
Well, Python shines for lot of these tasks, albeit it may suffer from
low performance.
 
For example, the very first thing (find the product of two numbers in
the list that sums to 2020), can be expressed in a list comprehension:
 
 
# input data list
# for the real program we need to read it from stdin somehow
report=[1721,979,366,299,675,1456]
 
# compute product
prod = [x*y for x in report for y in report if x+y==2020]
 
The result is then the first entry of the list prod[0].
 
As you can see, this single line expresses almost verbatim the problem
and solves it in Python. List comprehension is a powerful feature that
was borrowed from Haskell. Python is a very complex language today, just
like C++ it got features after features, but because it started from a
more recent base it is less crufty than C++.
 
OTOH it was never meant to be compiled to machine code, that's why
Python is often 100 times slowere than the equivalent C++ program, but
for tasks where the programmer time takes longer than the computation,
it is really handy.
 
Christian
Jorgen Grahn <grahn+nntp@snipabacken.se>: Dec 08 11:17PM

On Tue, 2020-12-08, Christian Gollwitzer wrote:
 
> The result is then the first entry of the list prod[0].
 
> As you can see, this single line expresses almost verbatim the problem
> and solves it in Python.
 
Sure, but my point was that C++ is suitable, not that some other
language is unsuitable. I haven't written anything so far (days 1--7)
that has felt painful or tedious (except the input parsing, but then I
wished for Perl).
 
I only brought up Python as an example of a well-known language,
general and popular for small tasks.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Tim Woodall <news001@woodall.me.uk>: Dec 08 07:40AM

> };
 
> Within the struct XML an A should be written in XML format; within JSON
> it should be written in JSON format.
 
How can this possibly work? Consider:
 
template<typename T> void do_stuff(const T& X)
{
const A& a = T.a;
print(a); //Which does '<< a' in a different translation unit
}
 
Can you do something like?
 
struct XML {
struct T : public A {};
T a;
std::ostream& operator<<(std::ostream& os, T const& datum) { os << "<A>" << a.to_string() << "</A>" ; }
};
struct JSON {
struct T : public A {};
T a;
std::ostream& operator<<(std::ostream& os, T const& datum) { os << "{\"A\":\"" << a.to_string() << "\"}" }
};
 
Now you have JSON::T and XML::T that are different types but you can
keep all the code in struct A {}
Bonita Montero <Bonita.Montero@gmail.com>: Dec 08 03:11PM +0100

>         std::ostream& operator<<(std::ostream& os, A const& datum) { os
> << "{\"A\":\"" << a.to_string() << "\"}"  }
> };
 
You can't define operators with two parameters inside a class.
They have to be global and for your purpose they might be friend
of a class.
Tim Woodall <news001@woodall.me.uk>: Dec 08 07:45AM

> };
 
> Now you have JSON::T and XML::T that are different types but you can
> keep all the code in struct A {}
 
(Obviously the operator<< need to be moved outside the class and XML::
type qualifiers added but I think the idea is clear...)
Vir Campestris <vir.campestris@invalid.invalid>: Dec 08 10:22PM

On 08/12/2020 07:45, Tim Woodall wrote:
>> keep all the code in struct A {}
 
> (Obviously the operator<< need to be moved outside the class and XML::
> type qualifiers added but I think the idea is clear...)
 
Seems to me you hit exactly the same problem I did: you can't define an
operator<< within a class to serialise an arbitrary type, only to
serialise the containing class (and on further experimentation I can't
see what use it is, you have to write object << std::cout)
 
But you've given me an idea...
 
struct A {
std::string to_string() const { std::ostringstream s; s <<
"this A is at " << this; return s.str();}
};
 
struct XML {
struct XML_A: public A {
} a;
};
std::ostream& operator<<(std::ostream& os, XML::XML_A const & a) { os <<
"<A>" << a.to_string() << "</A>" ; return os;}
std::ostream& operator<<(std::ostream& os, XML const & x){ os << x.a;
return os;}
 
struct JSON {
struct JSON_A: public A {
} a,b;
};
std::ostream& operator<<(std::ostream& os, JSON::JSON_A const & a) { os
<< "{\"A\":\"" << a.to_string() << "\"}"; return os;}
std::ostream& operator<<(std::ostream& os, JSON const & j){ os << j.a <<
j.b; return os;}
 
Darnn it's ugly.
 
Andy
Vir Campestris <vir.campestris@invalid.invalid>: Dec 08 10:22PM

On 08/12/2020 14:11, Bonita Montero wrote:
> You can't define operators with two parameters inside a class.
> They have to be global and for your purpose they might be friend
> of a class.
 
Read the thread again. Including the title.
 
Andy
"daniel...@gmail.com" <danielaparker@gmail.com>: Dec 08 08:24AM -0800

How do we implement a robust exception class that has accessors to several string data members, and a what function that returns a concatenation of those strings?
 
A naive implementation to illustrate the intent is:
 
class my_error : public std::exception
{
std::string what1_;
std::string what2_;
mutable std::string what_;
 
my_error(const std::string& what1, const std::string& what2)
: what1_(what1), what2_(what2)
{
}
 
const std::string& what1() const
{
return what1_;
}
 
const std::string& what2() const
{
return what2_;
}
 
const char* what() const noexcept
{
try
{
what_ = what1_ + what2_;
return what_.c_str();
}
catch (...)
{
return what1_.c_str();
}
}
};
 
Thanks,
Daniel
"Öö Tiib" <ootiib@hot.ee>: Dec 08 10:26AM -0800

> How do we implement a robust exception class that has accessors to several string data members, and a what function that returns a concatenation of those strings?
 
The issue with that request is that we avoid exceptions that carry lot of
information and make lot of text processing. Exception is information for
developer about failure not for text processing or data transporting.
Ideally it is cheap and chance of exception from exception is none.
"daniel...@gmail.com" <danielaparker@gmail.com>: Dec 08 11:00AM -0800

On Tuesday, December 8, 2020 at 1:26:43 PM UTC-5, Öö Tiib wrote:
> information and make lot of text processing. Exception is information for
> developer about failure not for text processing or data transporting.
> Ideally it is cheap and chance of exception from exception is none.
 
I don't think that's entirely correct. Software that relies on exceptions for
handling errors may have no other channel for communicating
information that must end up in messages to users, for example,
the line and column number where a parsing error occurred, in
addition to a description of the parsing violation.
 
Even boost sometimes does text processing when constructing
exception messages, for example (snipping the irrelevant bits),
 
class bad_virtual_result_cast :
public std::bad_cast, public boost::contract::exception {
public:
explicit bad_virtual_result_cast(char const* from_type_name,
char const* to_type_name)
{
std::ostringstream text;
text << "incompatible contracted virtual function result type "
<< "conversion from '" << from_type_name << "' to '"
<< to_type_name << "'" ;
what_ = text.str();
}
 
virtual char const* what() const BOOST_NOEXCEPT_OR_NOTHROW
{
return what_.c_str();
}
 
private:
std::string what_;
};
 
Daniel
Paavo Helde <myfirstname@osa.pri.ee>: Dec 08 10:13PM +0200

> How do we implement a robust exception class that has accessors to several string data members, and a what function that returns a concatenation of those strings?
 
I understand you worry about memory exhaustion while constructing an
error message. This question is mostly theoretical. If the machine is so
out of memory that it cannot construct a single error message even after
stack unwinding, then you have got much more serious troubles than
trying to preserve your error message text. Most likely your error
handler would not be able to process the long error message properly anyway.
 
So it does not really matter what you return. Considering the memory is
fully exhausted, it makes some sense to return a very short string,
increasing the chances the error handler is able to cope with it. E.g.:
 
try {
// ...
} catch(...) {
return "No memory";
}
 
With some kind of software, it might be even preferable to kill the
program on spot if memory appears to be fully exhausted. But this is
probably better done in the out-of-memory handler.
"Öö Tiib" <ootiib@hot.ee>: Dec 08 01:17PM -0800

> information that must end up in messages to users, for example,
> the line and column number where a parsing error occurred, in
> addition to a description of the parsing violation.
 
It is unlikely that I want to show exception texts to user ever
as error handling, error reporting, user interface and debugging
are different concerns. Conflating those together results with all
being weak as exceptions are not silver bullets.
Exceptions should be used for handling exceptional
situations. Exceptional means that those happen rarely.
Rarely happening situations are less tested. More
complexity will add more chances of defects into
those places. Adding more debugging need is counter-
intuitive. User interface must be clear and might be
needed to be translated.
 
 
> Even boost sometimes does text processing when constructing
> exception messages, for example (snipping the irrelevant bits),
 
Boost is not always good example of best practices. Some things
are well made. Some are over-complicated and then either not
competitive or compile slowly because of too lot of
meta-programming. Your example was exception about misuse
of some boost library feature by programmer. Only
programmer can fix that problem, and so it is of no much value
to catch site nor to user.
olcott <NoOne@NoWhere.com>: Dec 08 02:08PM -0600

On 12/6/2020 12:06 PM, Mostowski Collapse wrote:
 
> book. What do you expect. That every book
> is error free? Then there is the problem
> that a moron like you interprets the script.
 
Both the Sipser proof and the Kozen proof succumb to my refutation of
Linz. Sipser's D is equivalent to the Peter Linz Ĥ.
 
u32 D(u32 P)
{
u32 Input_Halts = H(P, P);
if (Input_Halts)
return 0; // Indicating not halting
else
return 1; // Indicating halting
}
 
http://www.liarparadox.org/sipser_165.pdf
 
Sipser, Michael 1997. Introduction to the Theory of Computation. Boston:
PWS Publishing Company (165-167)
 
 
The Kozen computation is identical to the Peter Linz computation merely
swapping function names Linz.H is swapped for Kozen.K and Linz.Ĥ is
swapped for Kozen.N
 
http://www.liarparadox.org/kozen_233.pdf
 
Kozen, Dexter 1997. Automata and Computability. New York:
Springer-Verlag. (231-234).
 
 
--
Copyright 2020 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
olcott <NoOne@NoWhere.com>: Dec 08 12:10PM -0600

I spent about 3000 hours creating the x86utm operating system that
executes x86 based virtual machines using a very excellent x86 emulator.
It simulates the execution of the COFF object file output of the
Microsoft C compiler using x86 emulation.
 
x86 language ≡ von Neumann architecture ≡ UTM ≡ RASP Machine
It is common knowledge that all x86 based programs are computationally
equivalent to UTMs for every computation that does not require more
memory than they have.
 
Here is D (computational equivalent to the Sipser D) being correctly
decided by H() (computational equivalent to the Sipser H).
 
http://www.liarparadox.org/sipser_165.pdf
 
Sipser, Michael 1997. Introduction to the Theory of Computation. Boston:
PWS Publishing Company (165-167)
 
u32 D(u32 P)
{
u32 Input_Halts = H(P, P);
if (Input_Halts)
return 0; // Indicating not halting
else
return 1; // Indicating halting
}
 
 
#define HALT __asm hlt
 
int main()
{
H((u32)D, (u32)D);
HALT;
}
 
 
_D()
[0000066c](01) 55 push ebp
[0000066d](02) 8bec mov ebp,esp
[0000066f](01) 51 push ecx
[00000670](03) 8b4508 mov eax,[ebp+08]
[00000673](01) 50 push eax
[00000674](03) 8b4d08 mov ecx,[ebp+08]
[00000677](01) 51 push ecx
[00000678](05) e8cffdffff call 0000044c
[0000067d](03) 83c408 add esp,+08
[00000680](03) 8945fc mov [ebp-04],eax
[00000683](04) 837dfc00 cmp dword [ebp-04],+00
[00000687](02) 7406 jz 0000068f
[00000689](02) 33c0 xor eax,eax
[0000068b](02) eb07 jmp 00000694
[0000068d](02) eb05 jmp 00000694
[0000068f](05) b801000000 mov eax,00000001
[00000694](02) 8be5 mov esp,ebp
[00000696](01) 5d pop ebp
[00000697](01) c3 ret
 
_main()
[0000069c](01) 55 push ebp
[0000069d](02) 8bec mov ebp,esp
[0000069f](05) 686c060000 push 0000066c
[000006a4](05) 686c060000 push 0000066c
[000006a9](05) e89efdffff call 0000044c
[000006ae](03) 83c408 add esp,+08
[000006b1](01) f4 hlt
[000006b2](01) 5d pop ebp
[000006b3](01) c3 ret
 
Output_Debug_Trace() Trace_List.size(20)
[0000069c](01) 55 push ebp
[0000069d](02) 8bec mov ebp,esp
[0000069f](05) 686c060000 push 0000066c
[000006a4](05) 686c060000 push 0000066c
[000006a9](05) e89efdffff call 0000044c // CALL H() from main()
[0000066c](01) 55 push ebp
[0000066d](02) 8bec mov ebp,esp
[0000066f](01) 51 push ecx
[00000670](03) 8b4508 mov eax,[ebp+08]
[00000673](01) 50 push eax
[00000674](03) 8b4d08 mov ecx,[ebp+08]
[00000677](01) 51 push ecx
[00000678](05) e8cffdffff call 0000044c // CALL H() from D()
[0000066c](01) 55 push ebp
[0000066d](02) 8bec mov ebp,esp
[0000066f](01) 51 push ecx
[00000670](03) 8b4508 mov eax,[ebp+08]
[00000673](01) 50 push eax
[00000674](03) 8b4d08 mov ecx,[ebp+08]
[00000677](01) 51 push ecx
[00000678](05) e8cffdffff call 0000044c // CALL H() from D()
The PRIOR Instruction Specifies Infinite Recursion: Simulation Stopped:
 
A second call to the same function from the same machine address without
any control flow instructions in-between** is always a case of infinite
recursion: recursion with no escape from recursion.
 
** A simplification of the original criteria to make the proof easier to
understand.
 
The halt decider uses this criteria to decide that an input expresses
non-halting behavior:
 
On 11/27/2020 9:02 PM, Ben Bacarisse wrote:
> A computation that would not halt if its simulation were not
> halted is indeed a non-halting computation.
 
On Saturday, November 28, 2020 at 2:00:28 PM UTC-8, olcott wrote:
 
--
Copyright 2020 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: Dec 08 06:16PM

On 08/12/2020 18:10, olcott wrote:
 
> x86 language ≡ von Neumann architecture ≡ UTM ≡ RASP Machine
> It is common knowledge that all x86 based programs are computationally equivalent to UTMs for every computation that does not require more memory than they have.
 
> Here is D (computational equivalent to the Sipser D) being correctly decided by H() (computational equivalent to the Sipser H).
 
[snip]
 
In troll theory, the olcott problem is the problem of determining, from a number of arbitrary Usenet posts, whether an olcott will stop trolling, or continue to troll forever. Alan Turing proved in 1936 that a general algorithm to solve the olcott problem for all possible olcott instances cannot exist.
 
For any troll decider, d, that might determine if olcotts stop trolling, a "pathological" olcott, o, stimulated by a reply to one of its Usenet posts, will respond with a delusional reply indistinguishable from genuine troll. A key part of the proof is a variation on Poe's law, an adage of Internet culture stating that, without a clear indicator of the author's intent, it is impossible to differentiate trolling with the output of the mentally ill and can be mistaken by some readers for a sincere expression of the argument being presented. It is one of the first cases of decision problems proven to be unsolvable. This proof is significant to practical computing efforts, as it warns that much time can be wasted engaging with an olcott.
 
/Flibble
 
--
😎
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 07 07:46PM -0800

On 12/6/2020 5:13 PM, Bonita Montero wrote:
>> not needed then it is pointless waste of resources into
>> unneeded complexity.
 
> No, shared_ptr isn't expensive.
 
Ummm.... atomic RMW's and memory barriers are expensive.
 
 
Bonita Montero <Bonita.Montero@gmail.com>: Dec 08 07:36AM +0100

>> No, shared_ptr isn't expensive.
 
> Ummm.... atomic RMW's and memory barriers are expensive.
 
20 cycles on my computer - that's nothing.
olcott <NoOne@NoWhere.com>: Dec 07 06:18PM -0600

On 12/7/2020 5:54 PM, Ben Bacarisse wrote:
 
> and
 
> "The input to Halts is only finite because..."
> Message-ID: <6eSdnYuLBrIuVFzCnZ2dnUU7-cPNnZ2d@giganews.com>
 
Message ID's are useless to me when I click on them my newsreader thinks
that I want to send an email. I need date-time-stamps.
 
 
int main()
{
Confound_Halts((u32)Confound_Halts);
HALT;
}
 
int main()
{
Halts((u32)Confound_Halts, (u32)Confound_Halts);
HALT;
}
 
Both of the above executions are decided as infinitely recursive by the
following criteria:
 
On 11/27/2020 9:02 PM, Ben Bacarisse wrote:
> A computation that would not halt if its simulation were not
> halted is indeed a non-halting computation.
 
On Saturday, November 28, 2020 at 2:00:28 PM UTC-8, olcott wrote:
> Every computation that would not halt if its simulation
> were not halted is by logical necessity a non-halting computation.
 
I posted the full execution trace proving this.
 
--
Copyright 2020 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
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)