Wednesday, August 8, 2018

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

m.labanowicz@gmail.com: Aug 08 05:50AM -0700

Hello,
 
Following program can not be compiled by g++ (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609:
 
--[beg]--[main.cpp]--
 
#include <iostream>
 
class A { public:
void bar(int value) {
std::cout << "bar:" << value << std::endl;
}
void foo(int value) {
std::cout << "foo:" << value << std::endl;
}
};
 
class B : public A { public:
void foo() {
std::cout << "void" << std::endl;
}
};
 
int main(void)
{
B b;
 
int i = 1234;
 
b.foo();
 
b.bar(i);
 
b.foo(i); /* Error is here -> to avoid error 'b.A::foo(i)' has to be called */
 
return 0;
}
 
--[end]--[main.cpp]--
 
# g++ main.cpp
main.cpp: In function 'int main()':
main.cpp:29:10: error: no matching function for call to 'B::foo(int&)'
b.foo(i); /* Error is here -> to avoid error b.A::foo(i) has to be called */
^
main.cpp:14:8: note: candidate: void B::foo()
void foo() {
^
main.cpp:14:8: note: candidate expects 0 arguments, 1 provided
 
 
I don't see any conflicts.
'bar' function implementation is found correctly in A.
Why compiler is not able to find automatically 'foo(int)' implementation in A?
 
Regards
 
--
Maciej Labanowicz
Paavo Helde <myfirstname@osa.pri.ee>: Aug 08 04:23PM +0300


> I don't see any conflicts.
> 'bar' function implementation is found correctly in A.
> Why compiler is not able to find automatically 'foo(int)' implementation in A?
 
foo in b is hiding inherited foo from A. This is a safety feature to
make the code more robust against later changes.
 
To unhide A::foo, add the following line into B:
 
using A::foo;
"Öö Tiib" <ootiib@hot.ee>: Aug 07 04:09PM -0700

On Wednesday, 8 August 2018 00:27:25 UTC+3, Rick C. Hodgin wrote:
 
> If you have a sole central source issuing uuids, that's a different
> matter and remains secure.
 
No single thing is guaranteed to work endlessly reliably because it is
made of real materials and located in real world. The chance
of failure in that central source of uuids is way higher than chance
that the distributed system generates clashing uuids. So the
distributed system should be preferred. It is more reliable as whole
despite there is tiny likelihood of clash. That likelihood is smaller
than that the central source will fail and also generate two clashing
uuids or that it will stop generating these forever.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Aug 07 07:53PM -0400

On 8/7/2018 7:09 PM, Öö Tiib wrote:
> made of real materials and located in real world. The chance
> of failure in that central source of uuids is way higher than chance
> that the distributed system generates clashing uuids.
 
That's why fault tolerant systems exist.
 
In addition, a central source of uuid issuance doesn't have to be a
single machine. It can be a widely distributed system, with each one
doling out from an authorized lot of uuids which are, from the central
repository issuing system, guaranteed to always be unique.
 
> despite there is tiny likelihood of clash. That likelihood is smaller
> than that the central source will fail and also generate two clashing
> uuids or that it will stop generating these forever.
 
There are real-world design considerations which negate your argument.
 
Whenever you have multiple independent servers issuing uuids without
collaboration, the possibility for collision exists. It will happen
at some point, and to not address that issue is to literally invite
failure into your system.
 
--
Rick C. Hodgin
Siri Cruise <chine.bleu@yahoo.com>: Aug 07 05:07PM -0700

In article <pkcps1$1fe$1@dont-email.me>,
> use of any uuid-based system is dangerous and it must be assumed it will
> fail at some point, resulting in data error and/or loss, as well as a
> potential crash of the system.
 
Depends on the design of the system. We use UUIDs without checking. In case of
duplicates, the customer will be annoyed, but we can manually repair the
database since we also employ slower but robust identifiers. It becomes a
question whether it's cheaper to use an automated or by hand solution.
 
Not every program has access to nuclear launch codes.
 
--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
An almond doesn't lactate. This post / \
Yet another supercilious snowflake for justice. insults Islam. Mohammed
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Aug 07 08:21PM -0400

On 8/7/2018 8:07 PM, Siri Cruise wrote:
> database since we also employ slower but robust identifiers. It becomes a
> question whether it's cheaper to use an automated or by hand solution.
 
> Not every program has access to nuclear launch codes.
 
 
Agreed. With the ECS in question, I mean seriously ... what's the
worst that could happen? :-)
 
--
Rick C. Hodgin
scott@slp53.sl.home (Scott Lurndal): Aug 07 08:46PM

>> to consider the problem being solved with a UUID.
 
>If one sends a UUID over the wire, it should be HMAC'ed, or at least
>MAC'ed. So the receivers can verify some sort of authenticity.
 
That's true of any traffic, hence the existence of TLS. There's nothing
special about a UUID vis-a-vis traffic security.
boltar@cylonHQ.com: Aug 08 08:50AM

On Tue, 7 Aug 2018 17:03:49 +0100
>understands
>> the difference between a class and an object in C++.
 
>That's right mate I've been coding in C++ since 1993 and I don't know the
 
1993? Really? You come across as someone who learnt it last week.
 
>difference between a class and an object in C++. Ironically your wording
 
Well thats the way it seems. Also you don't seem to get the difference between
a compile time identifier such as namespaces and runtime identifiers such
as uuids and constantly conflate them.
 
>reveals your own lack of C++ competence: in C++ an object is a region of
>storage so whilst an instance of a class is obviously an object so is an
>instance of an 'int' or an instance of an array. You need to have a
 
Not in C++ it isn't. An object has a specific definition and an "int" is
not an object. Look it up. Perhaps you've spent too long with Smalltalk like
languages where all types are considered objects.
 
>Finger's crossed? Again educate yourself on the nature of UUIDs: chance of
>collision is very low.
 
But non zero unless you do it properly.
 
>You are the one making assumptions such as me "hard coding UUIDs" because
>you saw some hex digits in some C++ code which seems to have been the
>primary trigger for your fucktardery.
 
No, I saw some hard coded UUIDs in code you posted. I'm quite happy to repost
it for you if you've forgotten.
 
>> No, of course I didn't, they'd completely passed me by in the 25 years I've
>> worked in IT.
 
>Liar.
 
Believe what you like sonny. Using uuid's inappropriately is a dumb coders
idea of what smart coding is.
 
>The number of classes isn't the problem: guaranteeing unique
>identification for a class is.
 
Which given the nature of classes being fixed in number at compile time is
a trivial exercise.
 
>just classes it is also dynamically created component objects for which a
>UUID will be generated automatically for that component which will then be
>serialized to a file/database/script.
 
Presumably by serialised you mean dumped into json or XML. You still don't
need a uuid for that.
 
>That doesn't look like a UUID to me. UUIDs have 128-bits.
 
Thats because its not a uuid you mouth breathing muppet. Which part of the
word "encryption" didn't you understand? Its a diffie hellman key. The point
was to demonstrate that hex numbers are not easy to grok.
 
>Someone else wrote my ECS? Amazing given that I haven't finished
>implementing it.
 
Ah, so its your abortion. No wonder you're so defensive.
pooroldalf@oldfolkshome.com: Aug 08 08:54AM

On Tue, 7 Aug 2018 18:17:52 +0200
>I've killfiled Boltar (so far eight identities, I think it is), and I
>suggest you do the same.
 
Of course you do, because you consistently fail to argue your side of the
argument and can't handle criticism.
 
Here's another id to killfile. I've got an infinite number of others btw so
all it achieves is filling up your killfile. But hey, whatever.
David Brown <david.brown@hesbynett.no>: Aug 08 11:28AM +0200

On 07/08/18 23:27, Rick C. Hodgin wrote:
>>> of a collision.
 
> When you use uuids that are sourced from multiple independent servers,
> there's no guarantee you won't have a collision at some point.
 
I think you are misunderstanding the scale of the probabilities involved
here, as well as some details about the UUID generation mechanisms.
 
First, there are UUID generator versions that use the Ethernet MAC
address and timestamps as part of the code. MAC addresses are, in
theory, unique - they have 6 bytes from a central authority, and 6 bytes
from the company that manufactured the Ethernet card. Note, however,
that there is nothing to stop people cheating on this - and people /do/
cheat MAC addresses.
 
The most commonly used UUID generator version is the purely random one.
This has 122 bits that are random. Assuming a reasonable random number
generator (i.e., pretty much any tool except the old MS WinAPI GUID
generator), that's a one in 5 x 10^36 chance of two UUID's colliding.
Compare that to some estimates of the uniqueness of human fingerprints
(based on current recording techniques) of 1 in 64,000,000. You need
103 million, million UUID's interacting on the same system before you
have a one in a thousand million chance of seeing a problem.
 
The chances of the earth being destroyed by a meteor are far higher.
 
More to the point, the chances of UUID collisions are microscopic
compared to the chances of other random errors in your system. To store
these 103 trillion UUID's in a system, you'd need 1600 TB of memory -
assuming the machine was doing nothing else. Without ECC ram, you'd
expect a one in a billion chance of a cosmic ray causing a bit error
within 5 /nanoseconds/. There is no way you could compare the UUIDs to
look for a collision - even with ECC memory the UUIDs would be changing
far faster than you could compare them.
 
 
> lack of guarantee makes it a system of no confidence, one that is use-
> less for anything of production quality, one that is even inviting
> data and/or stability disaster for the app that's relying on it.
 
You have more of a "guarantee" of no collision of random UUIDs than you
have of most "guarantees" - including those from a single central source.
 
 
> If you have a sole central source issuing uuids, that's a different
> matter and remains secure.
 
I don't know what you mean by "secure" here, as the word has many
possible implications, but I'm going to guess you mean "reliable". And
no, a single central source is not more reliable - it is a single point
of failure. Even if you have multiple physical systems, you still have
a logical single point of failure - and the chances of all your multiple
physical systems failing at once is vastly higher than the chances of a
UUID collision. And that is if everyone is honest and no one takes
shortcuts, which is never the case.
boltar@cylonHQ.com: Aug 08 09:54AM

On Wed, 08 Aug 2018 11:28:31 +0200
>First, there are UUID generator versions that use the Ethernet MAC
>address and timestamps as part of the code. MAC addresses are, in
 
Its not a good idea to use MAC addresses. For a start you have to assume
that the cheapo chinese NIC manufacturer is playing ball and not just assigning
them randomly and secondly a lot of (most?) cards support the ability to change
the MAC address on the fly. In linux its trival using the ifconfig command.
 
In fact I used to use this method on my laptop wifi NIC to bypass timeouts in
hotels back in the day when they only allowed you a few hours on their wifi a
day without paying. 99% of them used the MAC as the machine id** and once you
got timed out you simply changed the MAC and logged in again and the router
assumed it was a different machine.
 
** A lot still do to pop up personalised greeting messages whenever you log
into their network from any of their hotels if you've logged in before.
David Brown <david.brown@hesbynett.no>: Aug 08 12:41PM +0200

> that the cheapo chinese NIC manufacturer is playing ball and not just assigning
> them randomly and secondly a lot of (most?) cards support the ability to change
> the MAC address on the fly. In linux its trival using the ifconfig command.
 
Did you bother reading my post? I wrote that /one/ way that UUIDs can
be generated is using the MAC address as part of it - but that purely
random UUIDs are more common. I also wrote that a disadvantage of MACs
is that they are not as unique as theory would suggest, because some
manufacturers cheat, take short-cuts, or simply get things wrong.
 
> assumed it was a different machine.
 
> ** A lot still do to pop up personalised greeting messages whenever you log
> into their network from any of their hotels if you've logged in before.
 
As I said, some people are dishonest, making MAC addresses less unique
than in theory.
boltar@cylonHQ.com: Aug 08 11:31AM

On Wed, 08 Aug 2018 12:41:08 +0200
>random UUIDs are more common. I also wrote that a disadvantage of MACs
>is that they are not as unique as theory would suggest, because some
>manufacturers cheat, take short-cuts, or simply get things wrong.
 
Yup, missed that. My mistake.
 
>> into their network from any of their hotels if you've logged in before.
 
>As I said, some people are dishonest, making MAC addresses less unique
>than in theory.
 
Its not dishonesty to change the MAC if the functionality is there. I can
envisage various network test situations where it might be essential.
David Brown <david.brown@hesbynett.no>: Aug 08 01:50PM +0200

>> is that they are not as unique as theory would suggest, because some
>> manufacturers cheat, take short-cuts, or simply get things wrong.
 
> Yup, missed that. My mistake.
 
Fair 'nuff.
 
>> than in theory.
 
> Its not dishonesty to change the MAC if the functionality is there. I can
> envisage various network test situations where it might be essential.
 
It is certainly not dishonest to change the MAC address. There are even
areas of MAC addresses specifically set aside for "local
administration", that you are free to use (collisions are then your own
responsibility).
 
Changing MAC addresses in order to gain wrongful access to a service -
more free Wifi in this case - is dishonest.
Paavo Helde <myfirstname@osa.pri.ee>: Aug 08 03:33PM +0300

>> instance of an 'int' or an instance of an array. You need to have a
 
> Not in C++ it isn't. An object has a specific definition and an "int" is
> not an object. Look it up.
 
Boltar, maybe you should look it up first?
 
The C++ standard (N4296) says in 1.8/1:
 
"The constructs in a C++ program create, destroy, refer to, access, and
manipulate objects. An object is a region of storage. [ Note: A function
is not an object. [...] An object has a storage duration. [...] An
object has a type. [...]"
 
3.9/1:
 
"There are two kinds of types: fundamental types and compound types.
Types describe objects (1.8), references (8.3.2), or functions (8.3.5)."
 
Fundamental types are discussed in 3.9.1 and include char, int and bool
for example. Special care is taken of char objects, see 3.9.1/1:
 
"Objects declared as characters (char) shall be large enough to store
any member of the implementation's basic character set." etc.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Aug 08 06:12AM -0700

On Wednesday, August 8, 2018 at 5:28:43 AM UTC-4, David Brown wrote:
> [snip]
 
Use them in your systems then.
 
--
Rick C. Hodgin
scott@slp53.sl.home (Scott Lurndal): Aug 08 01:21PM

>> On 8/7/2018 12:54 PM, Scott Lurndal wrote:
 
>When you use uuids that are sourced from multiple independent servers,
>there's no guarantee you won't have a collision at some point.
 
You should stop posting until your understanding of cryptographic
quality hashing progresses to the point that you can converse
intelligently on the topic.
Fraser Ross <fraser.ross8ATbtinternet.com@com>: Aug 08 10:15AM +0100

Using the draft N4750 at 12.4 local class declarations, there is nothing
about friends. At 14.3 friends, it says "Declaring a class to be a
friend implies that the names of private and protected members from the
class granting friendship can be accessed in the base-specifiers and
member declarations of the befriended class." Thats all there is on
this. Nowhere does it say directly that when a class is befriended,
local classes of the befriended class share that befriending.
 
Fraser.
Bo Persson <bop@gmb.dk>: Aug 08 11:47AM +0200

On 2018-08-08 11:15, Fraser Ross wrote:
> this.  Nowhere does it say directly that when a class is befriended,
> local classes of the befriended class share that befriending.
 
> Fraser.
 
Local classes are included in the term "member declarations". It doesn't
say just "member functions", so includes all types of members.
 
 
 
Bo Persson
Fraser Ross <fraser.ross8ATbtinternet.com@com>: Aug 08 11:38AM +0100

On 08/08/2018 10:47, Bo Persson wrote:
 
> Local classes are included in the term "member declarations". It doesn't
> say just "member functions", so includes all types of members.
 
>     Bo Persson
 
I know that. It lacks any detail about local classes.
 
Fraser.
James Kuyper <jameskuyper@alumni.caltech.edu>: Aug 08 07:08AM -0400

On 08/08/2018 05:15 AM, Fraser Ross wrote:
> member declarations of the befriended class." Thats all there is on
> this. Nowhere does it say directly that when a class is befriended,
> local classes of the befriended class share that befriending.
 
True - but it does say it indirectly:
 
"... The local class is in the scope of the enclosing scope, and has the
same access to names outside the function as does the enclosing
function." (9.8p1). Since the friend declaration gave the enclosing
function access to those members, the local class will have that same
access.
Paavo Helde <myfirstname@osa.pri.ee>: Aug 08 08:40AM +0300

On 8.08.2018 6:03, Stefan Ram wrote:
> Someone suggested "DRES", "destruct resources
> on exit scope", because "RAII" was misleading.
 
You can think of RAII as a proper name, then it is not misleading. Where
I am from there is a saying "the name does not spoil a man". Indeed, we
are not going to rename New York despite of it being several centuries
old by now.
 
 
> I see problems with "DRES":
> My own suggestion might be something like "OLIREL",
 
And create an endless confusion and arguments about whether "OLIREL" is
exactly the same as RAII or are there some differences.
 
> I can live very well with just keeping "RAII".
 
Good, we have already enough politicians and C-level managers who are
just renaming departments and state offices because they cannot figure
out anything else to do.
Tim Rentsch <txr@alumni.caltech.edu>: Aug 07 10:05PM -0700


> then in the second case you'll call DerivedClass::something just as
> you would with a pointer, even though the pointer you have in your
> hand is of type SomeClass&
 
Did you miss the part where I said "the dynamic type of the
argument is SomeClass"? If the dynamic type is SomeClass,
the reference must refer to a SomeClass, not a DerivedClass.
 
> BTW Juha is on my small list of people I listen to here.
 
I regret the way my comments came out. Certain styles of
expression sometimes trigger me to respond more severely
than I mean to, and that happened here. I didn't mean to
malign Juha and am sorry it came across that way.
ram@zedat.fu-berlin.de (Stefan Ram): Aug 08 03:03AM

Someone suggested "DRES", "destruct resources
on exit scope", because "RAII" was misleading.
 
I see problems with "DRES":
 
- "At exit scope" sounds wrong to me (for
"at scope exit"). If we are going through
the hassle to change "RAII", the replacement
has to be without obvious faults. Otherwise,
we are just replacing something defective
with something defective.
 
- It is not just bound to scope exit,
but to object lifetime. A "delete"
will active the desctructor, too.
 
My own suggestion might be something like "OLIREL",
"object lifetime is resource lifetime". However,
I can live very well with just keeping "RAII".
woodbrian77@gmail.com: Aug 07 06:40PM -0700

On Thursday, July 19, 2018 at 2:15:11 PM UTC-5, Manfred wrote:
> and this involves calling some extra inline constructors and destructors
> (unless they are optimized away), which may do nothing except
> setting/testing for null on the internal pointer.
 
In this thread
https://www.reddit.com/r/cpp/comments/8zwzv0/expect_the_expected_andrei_alexandrescu/
 
I write about how a version of my code that uses raw
pointers and a delegating constructor is 76 bytes smaller
than a version that uses unique_ptr. There's no moving
involved in the object in question.
 
These results are with g++ 8.1.1. I noticed similar
results a few years ago with an older compiler.
 
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
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)