Friday, March 10, 2023

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

Christian Gollwitzer <auriocus@gmx.de>: Mar 10 08:12AM +0100

> thrown - and it must or it couldn't be caught at all - then why can't it
> do a match to see if an auto matches? Yes it'll be more complex than the
> current system but I don't see why it would be impossible.
 
I think you don't understand the problem. The problem is not matching
the pair with the auto in your catch phrase. The problem is how to
compile the code within the catch phrase. So, say, you do:
 
 
catch(auto &[str,val])
{
std::cout<<str.size();
}
 
What is the compiler supposed to do with the line that calls size() on
the object str? In regular code, the compiler knows, e.g. that str is of
type std::string. It then looks up the address of the function
std::string::size() and inserts a call to that address. But "str" could
be, despite its name, as well a std::vector. Then the call would need to
go to std::vector::size(), otherwise you get illegal memory thrashing.
 
The only way to implement something like that would be an OO system
where all the objects derive from a common base, like it is in Java,
and, at runtime, lookup the name of the member function in a jump table.
That means, OTOH, that the code in the catch would be compiled in a
completely different way than it is elswehere in C++, and run much
slower as well. Even a simple integer addition would need to go through
this kind of thing, because "a+b" could as well be string concatenation
(call to std::string::operator +) as well as a simple integer addition,
which compiles to a single machine instruction. This is the reason why
it can be implemented in, say, Python, where all code goes through an
interpreter loop, whereas in C++, it usually doesn't.
 
 
Christian
Muttley@dastardlyhq.com: Mar 10 10:03AM

On Thu, 9 Mar 2023 11:38:42 -0800 (PST)
>ring
>can throw during copying. We don't want to throw in an
>exception copy constructor, lest we throw the wrong exception type.
 
If a there isn't enough memory to copy a short string then the program is going
to collapse in a heap fairly soon anyway so its not something that I'm going
to worry about.
 
>not to throw exceptions during copying, typically it stores the string inte=
>rnally=20
>as a separately-allocated reference-counted string.=20
 
I'll bear it in mind.
Muttley@dastardlyhq.com: Mar 10 10:05AM

On Fri, 10 Mar 2023 08:12:16 +0100
>the object str? In regular code, the compiler knows, e.g. that str is of
>type std::string. It then looks up the address of the function
>std::string::size() and inserts a call to that address. But "str" could
 
Yes, I get the point. Perhaps this is why Apple chose Objective-C with its
rich runtime enviroment which can do reflection.
Sam <sam@email-scan.com>: Mar 10 06:58AM -0500


> Once something is thrown the runtime knows what it is and simply has to
> match it with a catch as it does now. I'm not pretending matching an auto
> would be simple
 
catch (const auto &scooby_doo)
{
size_t mystery=sizeof(scooby_doo);
}
 
Can you tell me what my mystery is? The compiler has to compile it, somehow.
sizeof() is a compile-time constexpr.
 
> but I don't see why it should be impossible. After all, the
> runtime has to differentiate between int, char, parent and child classes to
> do proper catching.
 
Right, so the code has to be compiled here that might potentially catch an
int, char, long, double, every fundamental type, a pointer to every class in
existence, an array of one instance of every class in existence, an array of
two instances of every class in existence, and so in into infinity.
 
It will take a little bit of time for your sufferring C++ compiler to
generate code for all objects and classes that ever existed, or will ever
exist.
"Öö Tiib" <ootiib@hot.ee>: Mar 10 05:04AM -0800


> Yes, I get the point. Perhaps this is why Apple chose Objective-C with its
> rich runtime enviroment which can do reflection.
 
What you mean? There are no such feature about exceptions.
Objective-C throws only objects that have NSError interface.
Swift throws objects that have Error interface. Error and NSError are
exchangeable and interoperate but neither has some kind of generic
catches that can structurally bind to whatever is thrown.
Mr Flibble <flibble2@reddwarf.jmc.corp>: Mar 10 12:46PM

On 09/03/2023 20:31, olcott wrote:
 
> I created the notion of a simulating halt decider in this forum
> On 3/14/2017 at 9:05 AM
 
> Message-ID: <e18ff0a9-7f9d-4799-9d13-55d021afaa82@googlegroups.com>
 
Your simulating halt decider is invalid though as it doesn't distinguish
between non-halting non-pathological input and pathological input. The
Flibble Simulating Halt Decider is the *first* SHD that solves the
halting problem.
 
/Flibble
David Brown <david.brown@hesbynett.no>: Mar 10 12:30AM +0100

On 09/03/2023 21:42, Michael S wrote:
 
> Absolutely not!
> Saturation is non-associative, that's enough to take it out of consideration
> for default behavior.
 
Wrapping doesn't even follow basic laws on ordering, taking it out of
consideration for default behaviour.
 
As I said, overflow will, in general, give incorrect answers. If you
choose to define its behaviour, it doesn't matter how you do it, it will
regularly be wrong and counter-productive, even if it would be helpful
in some use-cases. It will also spoil optimisations for code that does
not overflow.
 
If you want wrapping behaviour, make a class that supports that.
 
 
>> mind-bogglingly insane to suggest that adding one more marble to a full
>> jar would give you a negative jarful of marbles.
 
> Somehow, you don't consider almost the same case insane for unsigned integers.
 
What makes you say that? I think that almost all cases over overflow of
unsigned integer arithmetic are the result of bugs in the code. (There
are a few idiomatic cases, like "unsigned int x = -1;".) Modulo
arithmetic makes more sense for unsigned types than signed types, but it
is still usually wrong.
"Öö Tiib" <ootiib@hot.ee>: Mar 09 07:20PM -0800

On Thursday, 9 March 2023 at 22:13:06 UTC+2, Keith Thompson wrote:
> FILE* pointers. It's a very minor corner case. If I wanted to provide
> definitions for as much undefined behavior as possible, copying FILE
> objects would be very low on my list.
 
For me personally most undefined or unspecified behaviors individually
are low on list. The total time of explaining that this or that is such
behavior will be reduced and so people can deal with something more
valuable and therefore they have better programming language.
 
Compiler is tool, so can be required to add diagnostic. On case of FILE I see
no technical difficulties for neither C nor for C++ compiler. Would probably
just add some __attribute__ to the type for to ensure that diagnostic was
not confusing about copying incomplete type but about copying what
should not be copied.
 
> First you have to define what you mean by "failure". Do you want
> evaluating INT_MAX+1 to abort the program? Throw an exception? Emit
> nasal demons?
 
I would prefer exception or signal.
 
> future. Conceivably if C and C++ started requiring trapping on signed
> overflow, hardware would gradually be updated to make that more
> efficient, but we wouldn't see the effects for decades.
 
It is all about the trend. Most platforms trap on division by zero for
very long time. Yet the standards declare that they define nothing. That
philosophy of unreliability of most performant languages has to be
repaired for hardware designers to see that there is market for their
efforts.
Bonita Montero <Bonita.Montero@gmail.com>: Mar 10 05:59AM +0100

Am 09.03.2023 um 23:59 schrieb Lynn McGuire:
 
 
>> Read this:
>> https://mega.nz/file/ehcR1S5B#5YcRMdcJ0WArshD0szI2bckaqVmk2jC59XmOZh_GXgM
 
> No freaking way.  Looks like a ransomware file to me.
 
Ransomware in a PDF or EPUB ?
"Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Mar 10 09:17AM +0100

On 2023-03-10 5:59 AM, Bonita Montero wrote:
>>> https://mega.nz/file/ehcR1S5B#5YcRMdcJ0WArshD0szI2bckaqVmk2jC59XmOZh_GXgM
 
>> No freaking way.  Looks like a ransomware file to me.
 
> Ransomware in a PDF or EPUB ?
 
When the first .jpg virus was discovered in 2002 I was happy, well a
little, because it was an obvious possibility to me but my students
laughed at me when I mentioned it, middle 1990's.
 
- Alf
David Brown <david.brown@hesbynett.no>: Mar 10 10:36AM +0100

On 10/03/2023 04:20, Öö Tiib wrote:
 
> It is all about the trend. Most platforms trap on division by zero for
> very long time. Yet the standards declare that they define nothing.
 
No, most platforms do not trap on division by zero.
 
The solid majority of different types of platforms that are programmed
in C (and C++ gets this stuff from C) are small microcontrollers and
other embedded processors.
 
The solid majority of processor cores made and sold are small
microcontrollers.
 
 
While it is true that pretty much all "big" processors and "big" OS's
will trap on division by zero, the C and C++ world is very much wider
than that. And it is absolutely correct for the standards to say
nothing about how division by zero should be handled (i.e., it should be
left undefined behaviour).
 
There is a strong tendency amongst programmers to think that all
processors are x86 or ARM, and all OS's are Linux or Windows.
Fortunately, the C and C++ standards committees are not as limited.
 
(I am of the opinion that undefined behaviour is often a good thing for
code that is clearly wrong, even if there were a consensus for how it
might be treated in most hardware. I want division by zero to be
undefined, because it means debug tools and analysers can be used to
help track such bugs in the code. But that is an orthogonal issue.)
David Brown <david.brown@hesbynett.no>: Mar 10 10:44AM +0100

On 10/03/2023 05:59, Bonita Montero wrote:
>>> https://mega.nz/file/ehcR1S5B#5YcRMdcJ0WArshD0szI2bckaqVmk2jC59XmOZh_GXgM
 
>> No freaking way.  Looks like a ransomware file to me.
 
> Ransomware in a PDF or EPUB ?
 
Yes - pdf's in particular need to be treated with caution (especially if
you use that security disaster, Acrobat Reader).
 
But there is nothing in that URL to indicate that the target is a pdf,
epub, or anything else - it's just an incomprehensible string of letters
targeting a web host that is probably unknown to most people. It is
/exactly/ the sort of URL you'd expect for malware. A reader would have
to be very naïve or inexperienced to click on such a link unless they
were expecting to be given such a link from someone they trust, and when
they know what it is. Your post fails on all three accounts - I don't
expect many people will click on it.
 
If you post a link to the original source of the document (whatever it
might be), and a description of it and why it might be interesting for
people to read it, then it would be a lot more useful.
"Öö Tiib" <ootiib@hot.ee>: Mar 10 04:27AM -0800

On Friday, 10 March 2023 at 11:36:26 UTC+2, David Brown wrote:
> other embedded processors.
 
> The solid majority of processor cores made and sold are small
> microcontrollers.
 
Their reasoning of hardware designers is such: "division by 0 is undefined
anyway and so we counted that setting all bits of result to 1 takes few less
internal gates than setting all bits to 0 does."
So the whole reason of such design is lack of market to trap on division
by zero there.
 
> than that. And it is absolutely correct for the standards to say
> nothing about how division by zero should be handled (i.e., it should be
> left undefined behaviour).
 
C and C++ do not want to be portable assemblers of whatever chips,
these want to be programming languages. From that viewpoint there
are no reason why something that hardware does not handle (despite
its cost to performance if handled is hard to notice) should be left
undefined behavior.
 
> might be treated in most hardware. I want division by zero to be
> undefined, because it means debug tools and analysers can be used to
> help track such bugs in the code. But that is an orthogonal issue.)
 
The only "positive" thing of pointless undefined behaviors is job
security. All the time I have wasted into memorising those and
learning usage of tools to track those down gives me advantage
on job market. But the work is anyway plentiful, largely badly or
not done and I could do something more interesting instead of
helping to track down some undefined behavior.
Bonita Montero <Bonita.Montero@gmail.com>: Mar 10 01:38PM +0100

Am 10.03.2023 um 09:17 schrieb Alf P. Steinbach:
 
> When the first .jpg virus was discovered in 2002 I was happy, well
> a little, because it was an obvious possibility to me but my students
> laughed at me when I mentioned it, middle 1990's.
 
There might be an inconsistent content inside the file which might
cause intentional "misinterpretation" by the parser. But that's
rather unlikely.
Andrey Tarasevich <andreytarasevich@hotmail.com>: Mar 09 05:33PM -0800

On 03/09/23 8:03 AM, Jivanmukta wrote:
 
>                     TRACE("before insert");
>                     identifiers[what].insert(identifiers[what].end(),
> ids.begin(), ids.end());
 
The obvious and the most likely candidate is the value of `what`. What
is the value of `what`? Does it go out of `identifiers` range?
 
--
Best regards,
Andrey
Jivanmukta <jivanmukta@poczta.onet.pl>: Mar 10 11:26AM +0100

W dniu 9.03.2023 o 19:03, Jivanmukta pisze:
> Question: how to TRACE values: identifiers[what].end(), ids.begin(),
> ids.end()? I failed to cast them to unsigned long.
 
Could you answer me please? I Suspect there's something wrong with ids.
Jivanmukta <jivanmukta@poczta.onet.pl>: Mar 10 11:41AM +0100

W dniu 10.03.2023 o 02:33, Andrey Tarasevich pisze:
>> ids.begin(), ids.end());
 
> The obvious and the most likely candidate is the value of `what`. What
> is the value of `what`? Does it go out of `identifiers` range?
 
TRACE("ids.size: " << ids.size());
if (ids.size() > 0) { // nie wiem czy to ma sens?
int what = stoi(attr_what.value());
TRACE("what == " << what);
TRACE("size == " << identifiers[what].size());
TRACE("before insert");
identifiers[what].insert(identifiers[what].end(),
ids.begin(), ids.end());
TRACE("after insert"); // !!!błąd - czasami ids
puste i wtedy SIGV
}
 
what == 1 is TRACEd. Then SIGSEGV. size is not TRACEd. What does it mean?
 
I have defined:
 
identifiers_vector identifiers[index_what_num]
 
typedef std::vector<std::string> strvector;
 
class identifiers_vector : public strvector {
public:
identifiers_vector() = default;
identifiers_vector(const strvector &v) {
for (std::string s : v) {
push_back_identifier(s);
}
}
int index_of_identifier(const std::string &needle) const {
return index_of_string(*this, needle);
}
bool has_identifier(const std::string &needle) const {
return index_of_identifier(needle) >= 0;
}
void push_back_identifier(const std::string &s) {
if (!has_identifier(s)) {
push_back(s);
}
}
void sort_by_descending_length() {
std::sort(begin(), end(), [](std::string a, std::string b) {
return a.length() > b.length(); });
}
};
Jivanmukta <jivanmukta@poczta.onet.pl>: Mar 10 11:49AM +0100

enum index_what : unsigned short { i_actions, i_methods, i_functions,
i_properties, i_variables }; // don't change the order
constexpr unsigned short index_what_num = i_variables - i_actions + 1;
Paavo Helde <eesnimi@osa.pri.ee>: Mar 10 01:15PM +0200

10.03.2023 12:26 Jivanmukta kirjutas:
>> Question: how to TRACE values: identifiers[what].end(), ids.begin(),
>> ids.end()? I failed to cast them to unsigned long.
 
> Could you answer me please? I Suspect there's something wrong with ids.
 
Looks like so. Most probably you have corrupted your data by using code
which has UB. As you do not want to show your code, nobody can guess
where the bug is. My crystal ball says it is on line 42, but then again
I have not oiled it for a while.
Paavo Helde <eesnimi@osa.pri.ee>: Mar 10 01:23PM +0200

10.03.2023 12:41 Jivanmukta kirjutas:
> puste i wtedy SIGV
>                 }
 
> what == 1 is TRACEd. Then SIGSEGV. size is not TRACEd. What does it mean?
 
Most probably it means that the size of 'identifiers' is less than 1.
 
Why don't you single-step through your code in the debugger and monitor
the data values directly?
 
From a short look on your code it looks like you are trying to reinvent
std::set or std::map, poorly. Maybe you should start from some book
covering the C++ standard library?
Jivanmukta <jivanmukta@poczta.onet.pl>: Mar 10 12:42PM +0100

W dniu 10.03.2023 o 12:23, Paavo Helde pisze:
>>                  }
 
>> what == 1 is TRACEd. Then SIGSEGV. size is not TRACEd. What does it mean?
 
> Most probably it means that the size of 'identifiers' is less than 1.
how is it possible? here declaration of a parameter identifiers:
 
static bool load_cache(string cache_filename, const char
*parent_node_name, const char *nodes_name, wstring dir, wstring
result_dir, string options, string delim,
bool &cached, identifiers_vector
identifiers[index_what_num], apostrophed_strings_maps_map *strings) {
 
 
> Why don't you single-step through your code in the debugger and monitor
> the data values directly?
because i can't - wherever i set breakpoint i have sigsegv
Sam <sam@email-scan.com>: Mar 10 07:00AM -0500

Jivanmukta writes:
 
> Loaded '/lib/x86_64-linux-gnu/libc.so.6'. Symbols loaded.
 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000428172 in
 
Sorry to hear about this segfault. You will find your debugger down the
hall, last door on your right.
Sam <sam@email-scan.com>: Mar 10 07:01AM -0500

Jivanmukta writes:
 
> ids.begin(), ids.end());
 
> TRACE is executed then SIGSEGV although I have a breakpoint at line with
> insert.
 
Just because the program crashes here doesn't mean this is where the problem
is. C++ does not work this way. The problem can be anywhere in your code.
You will need to use a debugger, and other tools, to figure out where it is.
Sam <sam@email-scan.com>: Mar 10 07:02AM -0500

Jivanmukta writes:
 
>> Question: how to TRACE values: identifiers[what].end(), ids.begin(),
>> ids.end()? I failed to cast them to unsigned long.
 
> Could you answer me please? I Suspect there's something wrong with ids.
 
Nobody can answer this without debugging the full program, themselves.
Bonita Montero <Bonita.Montero@gmail.com>: Mar 10 07:58AM +0100

Am 08.03.2023 um 18:23 schrieb Paavo Helde:
 
> {
>         string s2 = move(s1);
> }
 
Do it the _easy_ way:
 
template<typename String>
requires same_as<String, basic_string<String::char_type,
String::traits_type, String::allocator>>
void myfunc( String &&str )
{
String str2( forward<String>( str ) ) );
}
 
Works with any basic_string variant and with
any of the four forwarding reference types.
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)