ECS

[Mr Flibble]

Hi!

I'mma making an ECS!

That is all.

Message ends.

/Flibble

--
"Suppose it’s all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I’d say, bone cancer in children? What’s that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It’s not right, it’s utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That’s what I would say."

[Mr Flibble]

On 31/07/2018 18:14, Mr Flibble wrote:
> Hi!
>
> I'mma making an ECS!
>
> That is all.
>
> Message ends.

It compiles!

namespace archetypes
{
const ng::entity_archetype spaceship
{
neolib::uuid{ 0x26730030, 0xa999, 0x4d99, 0xa7ad,{ 0x80, 0x89, 0x69,
0x23, 0x95, 0xf9 } },
"Spaceship",
{ ng::rigid_body::meta::id(), ng::box_collider::meta::id() }
};

const ng::entity_archetype asteroid
{
neolib::uuid{ 0x8283650f, 0x6e59, 0x4f0f, 0x8ae0, { 0x1d, 0x99, 0xeb,
0xf2, 0x49, 0xe0 } },
"Atsteroid",
{ ng::rigid_body::meta::id(), ng::box_collider::meta::id() }
};
}

void create_game(ng::i_layout& aLayout)
{
auto& ecs = ng::ecs::instance();
auto ecsContext = ecs.create_context();
ecs.register_archetype(ecsContext, archetypes::spaceship);
ecs.register_archetype(ecsContext, archetypes::asteroid);
auto spaceship = ecs.create_entity(ecsContext,
archetypes::spaceship.id(), ng::rigid_body{ ng::vec3{ 400.0, 18.0, 0.0 },
1.0 });
neolib::basic_random<double> prng;
for (int i = 0; i < 1000; ++i)
auto asteroid = ecs.create_entity(ecsContext, archetypes::asteroid.id(),
ng::rigid_body{ ng::vec3{ prng(1000.0), prng(1000.0), 0.0 }, 1.0 });

[Chris M. Thomasson]

On 7/31/2018 4:26 PM, Mr Flibble wrote:
> On 31/07/2018 18:14, Mr Flibble wrote:
>> Hi!
>>
>> I'mma making an ECS!
>>
>> That is all.
>>
>> Message ends.
>
> It compiles!
>
> namespace archetypes
> {
>     const ng::entity_archetype spaceship
>     {
>         neolib::uuid{ 0x26730030, 0xa999, 0x4d99, 0xa7ad,{ 0x80, 0x89,
> 0x69, 0x23, 0x95, 0xf9 } },
>         "Spaceship",
>         { ng::rigid_body::meta::id(), ng::box_collider::meta::id() }
>     };
>
>     const ng::entity_archetype asteroid
>     {
>         neolib::uuid{ 0x8283650f, 0x6e59, 0x4f0f, 0x8ae0, { 0x1d, 0x99,
> 0xeb, 0xf2, 0x49, 0xe0 } },
>         "Atsteroid",
>         { ng::rigid_body::meta::id(), ng::box_collider::meta::id() }
>     };
> }

The uuid's must look up the geometry for the object, a spaceship or
asteroid, right? ng::entity_archetype just abstractly represents an
entity within the game?

[Mr Flibble]

No the uuids uniquely identify entity archetypes. Geometry would be in
another component alongside rigid_body and box_collider.

/Flibble

[Chris M. Thomasson]

Okay, thanks.

[bol...@cylonhq.com]

Why do you need uuids to identify objects inside a self contained game?
Use "this" or just a simple name. Why do some people just love to make things
more complicated than they need to be?

[Öö Tiib]

The simple ints can be used as identity but random strings are often
more expensive to generate and store than uuids. Communicating about
game state over network or storing it in save file needs ids (not
pointers) anyway. Also the entities may be are destroyed or moved in
memory by faster containers where one typically wants to keep their
game entities and then the pointers will become wrong.

[Mr Flibble]

+1. Also, my ECS won't just be used for games.

[bol...@cylonhq.com]

On Wed, 1 Aug 2018 09:20:12 -0700 (PDT)
=?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote:
>On Wednesday, 1 August 2018 12:24:46 UTC+3, bol...@cylonhq.com wrote:
>> On Tue, 31 Jul 2018 20:07:11 -0500
>> Mr Flibble <flibbleREM...@i42.co.uk> wrote:
>> >Chris M. Thomasson <invalid_chr...@invalid.invalid> wrote:
>> >> The uuid's must look up the geometry for the object, a spaceship or
>> >> asteroid, right? ng::entity_archetype just abstractly represents an
>> >> entity within the game?
>> >>
>> >
>> >No the uuids uniquely identify entity archetypes. Geometry would be in
>>
>> Why do you need uuids to identify objects inside a self contained game?
>> Use "this" or just a simple name. Why do some people just love to make things
>
>> more complicated than they need to be?
>
>The simple ints can be used as identity

So use a simple int then instead of a load of hex digits that IMO are simply
there to make the programmer look impressive but make the code look a mess.
There's nothing clever about using hexadecimal if the individual bits have
no meaning and base16 maths isn't required unless you always want make sure
you fill up every byte of the id variable (why?).

>but random strings are often
>more expensive to generate and store than uuids. Communicating about

So don't use random strings, use actual names which will be far more helpful
to maintenance coders int the future. Given your uuids were hard coded
anyway there's no reason you couldn't use a hard coded name string other than
it doesn't look as flash.

[bol...@cylonhq.com]

On Wed, 1 Aug 2018 19:22:20 +0100
Mr Flibble <flibbleREM...@i42.co.uk> wrote:
>On 01/08/2018 17:20, Öö Tiib wrote:
>> On Wednesday, 1 August 2018 12:24:46 UTC+3, bol...@cylonhq.com wrote:
>>> On Tue, 31 Jul 2018 20:07:11 -0500
>>> Mr Flibble <flibbleREM...@i42.co.uk> wrote:
>>>> Chris M. Thomasson <invalid_chr...@invalid.invalid> wrote:
>>>>> The uuid's must look up the geometry for the object, a spaceship or
>>>>> asteroid, right? ng::entity_archetype just abstractly represents an
>>>>> entity within the game?
>>>>>
>>>>
>>>> No the uuids uniquely identify entity archetypes. Geometry would be in
>>>
>>> Why do you need uuids to identify objects inside a self contained game?
>>> Use "this" or just a simple name. Why do some people just love to make
>things
>>> more complicated than they need to be?
>>
>> The simple ints can be used as identity but random strings are often
>> more expensive to generate and store than uuids. Communicating about
>> game state over network or storing it in save file needs ids (not
>> pointers) anyway. Also the entities may be are destroyed or moved in
>> memory by faster containers where one typically wants to keep their
>> game entities and then the pointers will become wrong.
>
>+1. Also, my ECS won't just be used for games.

So what? If the hex values are hard coded it could simply be a human readable
hard coded string instead. Using hex digits in this way when its not
required is just showing off and I see it a lot in code and it just pisses
me off. If you want to show off go into show business, code is there to do
a job and should be as clear as possible.

[Mr Flibble]

On 02/08/2018 09:46, bol...@cylonHQ.com wrote:
> On Wed, 1 Aug 2018 09:20:12 -0700 (PDT)
> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote:
>> On Wednesday, 1 August 2018 12:24:46 UTC+3, bol...@cylonhq.com wrote:
>>> On Tue, 31 Jul 2018 20:07:11 -0500
>>> Mr Flibble <flibbleREM...@i42.co.uk> wrote:
>>>> Chris M. Thomasson <invalid_chr...@invalid.invalid> wrote:
>>>>> The uuid's must look up the geometry for the object, a spaceship or
>>>>> asteroid, right? ng::entity_archetype just abstractly represents an
>>>>> entity within the game?
>>>>>
>>>>
>>>> No the uuids uniquely identify entity archetypes. Geometry would be in
>>>
>>> Why do you need uuids to identify objects inside a self contained game?
>>> Use "this" or just a simple name. Why do some people just love to make things
>>
>>> more complicated than they need to be?
>>
>> The simple ints can be used as identity
>
> So use a simple int then instead of a load of hex digits that IMO are simply
> there to make the programmer look impressive but make the code look a mess.
> There's nothing clever about using hexadecimal if the individual bits have
> no meaning and base16 maths isn't required unless you always want make sure
> you fill up every byte of the id variable (why?).

If you care to educate yourself as to the nature of UUIDs by reading
https://en.wikipedia.org/wiki/Universally_unique_identifier you will see
that groups of hexadecimal numbers are THE canonical way of representing a
UUID. I am certainly not using hexadecimal numbers to "look impressive"
or make the code "look a mess"; I am simply using the correct common form
for a UUID. All 128-bits need to be used and it needs to be relatively
random to help avoid collisions. This UUID has been generated using a
UUID generator .. I certainly didn't "make them up".

>
>> but random strings are often
>> more expensive to generate and store than uuids. Communicating about
>
> So don't use random strings, use actual names which will be far more helpful
> to maintenance coders int the future. Given your uuids were hard coded
> anyway there's no reason you couldn't use a hard coded name string other than
> it doesn't look as flash.

Actual names require the use of a unique namespace to unsure uniqueness
and such unique strings will be more expensive to compare against than
comparing two UUIDs. The UUIDs are indeed hard coded: a copy of the
result of using a UUID generator.

Your reply to my post is typical of someone replying who is totally
fucking ignorant and doesn't have a fucking clue as to what they are
talking about.

[Mr Flibble]

On 02/08/2018 09:48, bol...@cylonHQ.com wrote:
> On Wed, 1 Aug 2018 19:22:20 +0100
> Mr Flibble <flibbleREM...@i42.co.uk> wrote:

You think I am using hex digits to "show off" because you are fucking
clueless as far as UUIDs are concerned. Educate yourself.

[bol...@cylonhq.com]

On Thu, 2 Aug 2018 19:55:58 +0100
Mr Flibble <flibbleREM...@i42.co.uk> wrote:
>On 02/08/2018 09:46, bol...@cylonHQ.com wrote:
>> So use a simple int then instead of a load of hex digits that IMO are simply
>> there to make the programmer look impressive but make the code look a mess.
>> There's nothing clever about using hexadecimal if the individual bits have
>> no meaning and base16 maths isn't required unless you always want make sure
>> you fill up every byte of the id variable (why?).
>
>If you care to educate yourself as to the nature of UUIDs by reading
>https://en.wikipedia.org/wiki/Universally_unique_identifier you will see
>that groups of hexadecimal numbers are THE canonical way of representing a
>UUID. I am certainly not using hexadecimal numbers to "look impressive"

And you need something as long as a uuid for some simple game - why? Just
how many game objects does it have? 2^64?

>or make the code "look a mess"; I am simply using the correct common form
>for a UUID. All 128-bits need to be used and it needs to be relatively
>random to help avoid collisions. This UUID has been generated using a

So you're not capable of thinking up numbers that don't collide yourself?

>> So don't use random strings, use actual names which will be far more helpful
>> to maintenance coders int the future. Given your uuids were hard coded
>> anyway there's no reason you couldn't use a hard coded name string other than
>
>> it doesn't look as flash.
>
>Actual names require the use of a unique namespace to unsure uniqueness

No, really? And thats hard to do it is without a generator?

>and such unique strings will be more expensive to compare against than
>comparing two UUIDs.

Howso? Its a stream of bytes. Last time I looked memcmp doesn't care whether
its ascii or not.

>Your reply to my post is typical of someone replying who is totally
>fucking ignorant and doesn't have a fucking clue as to what they are
>talking about.

I not exactly what I'm talking about , but you're clearly just another dumb
sheep who follows the herd instead of thinking for himself.

>You think I am using hex digits to "show off" because you are fucking
>clueless as far as UUIDs are concerned. Educate yourself.

Of course you are. Hex always makes code look more complex and the coder gets
the reflected glory. There is zero reason to use hard coded uuids to be used
within the same small system. Uuids are meant to be auto generated to uniquely
distinguish disparate objects or hardware when there may be thousands or
millions of them. I very doubt you have that number of classes or master
objects in your game. If you were using an auto generated on the fly uuid for
each object that would make sense, but a hard coded uuid for each class is just
grade A asshattery. Now I suggest YOU go get a clue you fucking tool.

[Mr Flibble]

On 03/08/2018 09:32, bol...@cylonHQ.com wrote:
> On Thu, 2 Aug 2018 19:55:58 +0100
> Mr Flibble <flibbleREM...@i42.co.uk> wrote:
>> On 02/08/2018 09:46, bol...@cylonHQ.com wrote:
>>> So use a simple int then instead of a load of hex digits that IMO are simply
>>> there to make the programmer look impressive but make the code look a mess.
>>> There's nothing clever about using hexadecimal if the individual bits have
>>> no meaning and base16 maths isn't required unless you always want make sure
>>> you fill up every byte of the id variable (why?).
>>
>> If you care to educate yourself as to the nature of UUIDs by reading
>> https://en.wikipedia.org/wiki/Universally_unique_identifier you will see
>> that groups of hexadecimal numbers are THE canonical way of representing a
>> UUID. I am certainly not using hexadecimal numbers to "look impressive"
>
> And you need something as long as a uuid for some simple game - why? Just
> how many game objects does it have? 2^64?

I am not making "some simple game"; I am making an app/game library and
framework. The UUIDs are not for identifying object instances; they are
used for uniquely identifying object archetypes, components and systems.
As I am making a library it has to support all possible applications with
the least constraints.

>
>> or make the code "look a mess"; I am simply using the correct common form
>> for a UUID. All 128-bits need to be used and it needs to be relatively
>> random to help avoid collisions. This UUID has been generated using a
>
> So you're not capable of thinking up numbers that don't collide yourself?

What a fucktarded thing to say. Obviously I would use a UUID generator to
randomly generate the UUID bytes. The whole point of UUIDs is that they
don't collide.

>
>>> So don't use random strings, use actual names which will be far more helpful
>>> to maintenance coders int the future. Given your uuids were hard coded
>>> anyway there's no reason you couldn't use a hard coded name string other than
>>
>>> it doesn't look as flash.
>>
>> Actual names require the use of a unique namespace to unsure uniqueness
>
> No, really? And thats hard to do it is without a generator?
>
>> and such unique strings will be more expensive to compare against than
>> comparing two UUIDs.
>
> Howso? Its a stream of bytes. Last time I looked memcmp doesn't care whether
> its ascii or not.

"Names" tend to be human readable strings and if we restrict ourselves to
Latin character set with mixed case the bulk of the possible values for a
byte will go unused. "Names" to be unique would require a unique
namespace prefix which would lead to a lot more bytes to compare than for
a UUID.

>
>> Your reply to my post is typical of someone replying who is totally
>> fucking ignorant and doesn't have a fucking clue as to what they are
>> talking about.
>
> I not exactly what I'm talking about , but you're clearly just another dumb
> sheep who follows the herd instead of thinking for himself.

Project much? https://en.wikipedia.org/wiki/Psychological_projection

>
>> You think I am using hex digits to "show off" because you are fucking
>> clueless as far as UUIDs are concerned. Educate yourself.
>
> Of course you are. Hex always makes code look more complex and the coder gets
> the reflected glory. There is zero reason to use hard coded uuids to be used

As I said in my previous reply hex is the canonical way to define a UUID.
In general hex certainly does NOT make code look more complex and only a
fucktard with no clue would say such a thing.

> within the same small system. Uuids are meant to be auto generated to uniquely
> distinguish disparate objects or hardware when there may be thousands or
> millions of them. I very doubt you have that number of classes or master
> objects in your game. If you were using an auto generated on the fly uuid for

As I said previously I am not making a game I am making an app/game
library and framework so I have no idea how many object types etc a user
of my library would want.

> each object that would make sense, but a hard coded uuid for each class is just
> grade A asshattery. Now I suggest YOU go get a clue you fucking tool.

A hard coded UUID for internal reserved type identification makes perfect
sense as does using UUIDs for user created types that can be serialized to
file; used in scripts etc.

So I repeat what I said earlier: get a fucking clue you fucktarded cockwomble.

[Öö Tiib]

On Thursday, 2 August 2018 11:46:20 UTC+3, bol...@cylonhq.com wrote:
> On Wed, 1 Aug 2018 09:20:12 -0700 (PDT)
> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote:
> >On Wednesday, 1 August 2018 12:24:46 UTC+3, bol...@cylonhq.com wrote:
> >> On Tue, 31 Jul 2018 20:07:11 -0500
> >> Mr Flibble <flibbleREM...@i42.co.uk> wrote:
> >> >Chris M. Thomasson <invalid_chr...@invalid.invalid> wrote:
> >> >> The uuid's must look up the geometry for the object, a spaceship or
> >> >> asteroid, right? ng::entity_archetype just abstractly represents an
> >> >> entity within the game?
> >> >>
> >> >
> >> >No the uuids uniquely identify entity archetypes. Geometry would be in
> >>
> >> Why do you need uuids to identify objects inside a self contained game?
> >> Use "this" or just a simple name. Why do some people just love to make things
> >
> >> more complicated than they need to be?
> >
> >The simple ints can be used as identity
>
> So use a simple int then instead of a load of hex digits that IMO are simply
> there to make the programmer look impressive but make the code look a mess.
> There's nothing clever about using hexadecimal if the individual bits have
> no meaning and base16 maths isn't required unless you always want make sure
> you fill up every byte of the id variable (why?).

The simple ints are useful for ids when there are potentially less than
billions of ids and these are generated by single source. That means on
lot of cases. The 4 times bigger uuid values are useful on cases when
ints are insufficient. Ints are usually generated sequentially, uuids
are generated so that chance of clashes was minimal.

>
> >but random strings are often
> >more expensive to generate and store than uuids. Communicating about
>
> So don't use random strings, use actual names which will be far more helpful
> to maintenance coders int the future. Given your uuids were hard coded
> anyway there's no reason you couldn't use a hard coded name string other than
> it doesn't look as flash.

Most objects in program and ids of such are generated by events during
program run. When events repeat then new objects are generated with
different ids. That is the whole point of unique id. When object
and its id is directly set by code then it is likely not real production
code but some test or demo.

[bol...@cylonhq.com]

On Fri, 3 Aug 2018 17:44:47 +0100
Mr Flibble <flibbleREM...@i42.co.uk> wrote:
>On 03/08/2018 09:32, bol...@cylonHQ.com wrote:
>> And you need something as long as a uuid for some simple game - why? Just
>> how many game objects does it have? 2^64?
>
>I am not making "some simple game"; I am making an app/game library and
>framework. The UUIDs are not for identifying object instances; they are
>used for uniquely identifying object archetypes, components and systems.

Even less reason to use them then since there will be an order of magnitude
less to deal with.

>As I am making a library it has to support all possible applications with
>the least constraints.

If its a library you should let the library user set the ids, NOT hard code
them yourself.

-1

>> So you're not capable of thinking up numbers that don't collide yourself?
>
>What a fucktarded thing to say. Obviously I would use a UUID generator to
>randomly generate the UUID bytes. The whole point of UUIDs is that they
>don't collide.

You don't understand the whole point of uuids, that pretty clear.

>> Howso? Its a stream of bytes. Last time I looked memcmp doesn't care whether
>> its ascii or not.
>
>"Names" tend to be human readable strings and if we restrict ourselves to
>Latin character set with mixed case the bulk of the possible values for a
>byte will go unused. "Names" to be unique would require a unique
>namespace prefix which would lead to a lot more bytes to compare than for
>a UUID.

Why are you conflating namespaces with a string of bytes stored in a class
or similar to identify then? They are unrelated.

>> I not exactly what I'm talking about , but you're clearly just another dumb
>> sheep who follows the herd instead of thinking for himself.
>
>Project much? https://en.wikipedia.org/wiki/Psychological_projection

Stating an obvious fact is not projection.

>As I said in my previous reply hex is the canonical way to define a UUID.
>In general hex certainly does NOT make code look more complex and only a
>fucktard with no clue would say such a thing.

Doesn't it? You'll be able to guess what this is for then won't you:

mpz_set_str(P,\
"FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1"
"29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD"
"EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245"
"E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED"

etc

>> distinguish disparate objects or hardware when there may be thousands or
>> millions of them. I very doubt you have that number of classes or master
>> objects in your game. If you were using an auto generated on the fly uuid for
>
>
>As I said previously I am not making a game I am making an app/game
>library and framework so I have no idea how many object types etc a user
>of my library would want.

This is a C++ group, not javascript, object types = class and classes are
fixed. And if your uses subclasses your classes then his class will end up with
the same fixed uuid which is idiotic.

>A hard coded UUID for internal reserved type identification makes perfect
>sense as does using UUIDs for user created types that can be serialized to
>file; used in scripts etc.

I suppose it makes sense if you've only ever experienced the uuid fuckwittery
in Windows and think its a sane model to copy.

>So I repeat what I said earlier: get a fucking clue you fucktarded cockwomble.

Look in the mirror sonny.

[bol...@cylonhq.com]

On Sun, 5 Aug 2018 23:42:49 -0700 (PDT)
=?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote:
>On Thursday, 2 August 2018 11:46:20 UTC+3, bol...@cylonhq.com wrote:
>> So use a simple int then instead of a load of hex digits that IMO are simply
>> there to make the programmer look impressive but make the code look a mess.
>> There's nothing clever about using hexadecimal if the individual bits have
>> no meaning and base16 maths isn't required unless you always want make sure
>> you fill up every byte of the id variable (why?).
>
>The simple ints are useful for ids when there are potentially less than
>billions of ids and these are generated by single source. That means on
>lot of cases. The 4 times bigger uuid values are useful on cases when
>ints are insufficient. Ints are usually generated sequentially, uuids
>are generated so that chance of clashes was minimal.

The point is that he's not generating them , he's hard coding them. Which
means he could easily use a much more readable name that would make life
easier for anyone who uses his code.

>> So don't use random strings, use actual names which will be far more helpful
>> to maintenance coders int the future. Given your uuids were hard coded
>> anyway there's no reason you couldn't use a hard coded name string other than
>
>> it doesn't look as flash.
>
>Most objects in program and ids of such are generated by events during
>program run. When events repeat then new objects are generated with
>different ids. That is the whole point of unique id. When object
>and its id is directly set by code then it is likely not real production
>code but some test or demo.

See above.

[Mr Flibble]

On 06/08/2018 09:44, bol...@cylonHQ.com wrote:
> On Fri, 3 Aug 2018 17:44:47 +0100
> Mr Flibble <flibbleREM...@i42.co.uk> wrote:
>> On 03/08/2018 09:32, bol...@cylonHQ.com wrote:
>>> And you need something as long as a uuid for some simple game - why? Just
>>> how many game objects does it have? 2^64?
>>
>> I am not making "some simple game"; I am making an app/game library and
>> framework. The UUIDs are not for identifying object instances; they are
>> used for uniquely identifying object archetypes, components and systems.
>
> Even less reason to use them then since there will be an order of magnitude
> less to deal with.

The problem isn't the number of IDs the problem is guaranteeing the
uniqueness of the IDs without using a central authority to generate them.
UUIDs are perfect for this.

>
>> As I am making a library it has to support all possible applications with
>> the least constraints.
>
> If its a library you should let the library user set the ids, NOT hard code
> them yourself.

The IDs are NOT hard coded: they are generated with a GUID generation tool
and then either manually pasted into a manually edited ECS description
language or automatically generated as part of the ECS description
language generation. The C++ code is generated from the ECS description
language.

>
> -1

-1? Yes you would think that as you are fucking clueless: you do not know
what you are talking about.

>
>>> So you're not capable of thinking up numbers that don't collide yourself?
>>
>> What a fucktarded thing to say. Obviously I would use a UUID generator to
>> randomly generate the UUID bytes. The whole point of UUIDs is that they
>> don't collide.
>
> You don't understand the whole point of uuids, that pretty clear.

That is a description of yourself not me. You didn't even know what UUIDs
were before I created this topic on this Usenet group.

>
>>> Howso? Its a stream of bytes. Last time I looked memcmp doesn't care whether
>>> its ascii or not.
>>
>> "Names" tend to be human readable strings and if we restrict ourselves to
>> Latin character set with mixed case the bulk of the possible values for a
>> byte will go unused. "Names" to be unique would require a unique
>> namespace prefix which would lead to a lot more bytes to compare than for
>> a UUID.
>
> Why are you conflating namespaces with a string of bytes stored in a class
> or similar to identify then? They are unrelated.

Without a namespace the string would be inordinately long which takes time
to compare with other strings. Even with a namespace the typical string
would have more bytes than a UUID. A typically namespace would be a URL:
see XML namespaces.

>
>>> I not exactly what I'm talking about , but you're clearly just another dumb
>>> sheep who follows the herd instead of thinking for himself.
>>
>> Project much? https://en.wikipedia.org/wiki/Psychological_projection
>
> Stating an obvious fact is not projection.

You are projecting your ignorance on to me though.

>
>> As I said in my previous reply hex is the canonical way to define a UUID.
>> In general hex certainly does NOT make code look more complex and only a
>> fucktard with no clue would say such a thing.
>
> Doesn't it? You'll be able to guess what this is for then won't you:
>
> mpz_set_str(P,\
> "FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1"
> "29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD"
> "EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245"
> "E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED"
>
> etc

etc? As I said previously hex digits are the canonical way to represent a
UUID.

>
>
>>> distinguish disparate objects or hardware when there may be thousands or
>>> millions of them. I very doubt you have that number of classes or master
>>> objects in your game. If you were using an auto generated on the fly uuid for
>>
>>
>> As I said previously I am not making a game I am making an app/game
>> library and framework so I have no idea how many object types etc a user
>> of my library would want.
>
> This is a C++ group, not javascript, object types = class and classes are
> fixed. And if your uses subclasses your classes then his class will end up with
> the same fixed uuid which is idiotic.

No ECS objects are not just instances of classes they can also be
dynamically generated at runtime from a script/database (so will use the
same class internally) but will still need a unique ID and this unique ID
HAS TO BE THE SAME EVERY TIME THE PROGRAM IS RUN.

>
>> A hard coded UUID for internal reserved type identification makes perfect
>> sense as does using UUIDs for user created types that can be serialized to
>> file; used in scripts etc.
>
> I suppose it makes sense if you've only ever experienced the uuid fuckwittery
> in Windows and think its a sane model to copy.
>
>> So I repeat what I said earlier: get a fucking clue you fucktarded cockwomble.
>
> Look in the mirror sonny.

Again I repeat: get a fucking clue you fucktarded cockwomble.

[Öö Tiib]

Perhaps these ids need to be same from run to run for to simplify
testing or demonstration of something.

[bol...@cylonhq.com]

On Mon, 6 Aug 2018 17:12:58 +0100
Mr Flibble <flibbleREM...@i42.co.uk> wrote:
>On 06/08/2018 09:44, bol...@cylonHQ.com wrote:
>> Even less reason to use them then since there will be an order of magnitude
>> less to deal with.
>
>The problem isn't the number of IDs the problem is guaranteeing the
>uniqueness of the IDs without using a central authority to generate them.
>UUIDs are perfect for this.

So you're just hoping they don't collide by making them very large. You have
to love the fingers crossed approach.

>> If its a library you should let the library user set the ids, NOT hard code
>> them yourself.
>
>The IDs are NOT hard coded: they are generated with a GUID generation tool
>and then either manually pasted into a manually edited ECS description
>language or automatically generated as part of the ECS description
>language generation. The C++ code is generated from the ECS description
>language.

So you finally mention this after how many posts?

>> You don't understand the whole point of uuids, that pretty clear.
>
>That is a description of yourself not me. You didn't even know what UUIDs
>were before I created this topic on this Usenet group.

No, of course I didn't, they'd completely passed me by in the 25 years I've
worked in IT.

>> Why are you conflating namespaces with a string of bytes stored in a class
>> or similar to identify then? They are unrelated.
>
>Without a namespace the string would be inordinately long which takes time
>to compare with other strings. Even with a namespace the typical string
>would have more bytes than a UUID. A typically namespace would be a URL:
>see XML namespaces.

So exactly how many classes are you expecting in this system? Just a rough
round number.

>> Doesn't it? You'll be able to guess what this is for then won't you:
>>
>> mpz_set_str(P,\
>> "FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1"
>> "29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD"
>> "EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245"
>> "E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED"
>>
>> etc
>
>etc? As I said previously hex digits are the canonical way to represent a
>UUID.

Do you need the definition of etc or do you want to see the whole thing? Ok:

mpz_set_str(P,\
"FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1"
"29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD"
"EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245"
"E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED"

"EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D"
"C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F"
"83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D"
"670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B"
"E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9"
"DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510"
"15728E5A 8AACAA68 FFFFFFFF FFFFFFFF",16);

Any clearer? Anyone who knows about encryption might recognise it. Why not
tell us what it is since you seem to view yourself as some kind of genius.

>> This is a C++ group, not javascript, object types = class and classes are
>> fixed. And if your uses subclasses your classes then his class will end up
>with
>> the same fixed uuid which is idiotic.
>
>No ECS objects are not just instances of classes they can also be
>dynamically generated at runtime from a script/database (so will use the

I don't give a rats arse what poxy little game dev scripting language
thinks it is , its what C++ that comes out the other end that matters.
Now are these uuids linked to a classs or instantiated objects? You don't
have any other options. If its classes please explain why you have so many
you need uuids to id them.

>HAS TO BE THE SAME EVERY TIME THE PROGRAM IS RUN.

So they are hard coded then. Make your fucking mind up.

>>> A hard coded UUID for internal reserved type identification makes perfect
>>> sense as does using UUIDs for user created types that can be serialized to
>>> file; used in scripts etc.
>>
>> I suppose it makes sense if you've only ever experienced the uuid fuckwittery
>
>> in Windows and think its a sane model to copy.
>>
>>> So I repeat what I said earlier: get a fucking clue you fucktarded
>cockwomble.
>>
>> Look in the mirror sonny.
>
>Again I repeat: get a fucking clue you fucktarded cockwomble.

Can't say I'm surprised you keep repeating yourself, you don't really even
seem to understand why you're using uuids yourself other than ECS (written
by someone else who obviously was smarter than you) uses them.

[bol...@cylonhq.com]

He can't seem to make his mind up if his uuid's are hard coded or not, he
just waffles about his ECS system generating them. I don't think he really
understands what it does or why it does it and I'm not even sure he understands
the difference between a class and an object in C++.

[Mr Flibble]

That's right mate I've been coding in C++ since 1993 and I don't know the
difference between a class and an object in C++. Ironically your wording
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
serious word with yourself mate.

[Mr Flibble]

On 07/08/2018 10:02, bol...@cylonHQ.com wrote:
> On Mon, 6 Aug 2018 17:12:58 +0100
> Mr Flibble <flibbleREM...@i42.co.uk> wrote:
>> On 06/08/2018 09:44, bol...@cylonHQ.com wrote:
>>> Even less reason to use them then since there will be an order of magnitude
>>> less to deal with.
>>
>> The problem isn't the number of IDs the problem is guaranteeing the
>> uniqueness of the IDs without using a central authority to generate them.
>> UUIDs are perfect for this.
>
> So you're just hoping they don't collide by making them very large. You have
> to love the fingers crossed approach.

Finger's crossed? Again educate yourself on the nature of UUIDs: chance of
collision is very low.

>
>>> If its a library you should let the library user set the ids, NOT hard code
>>> them yourself.
>>
>> The IDs are NOT hard coded: they are generated with a GUID generation tool
>> and then either manually pasted into a manually edited ECS description
>> language or automatically generated as part of the ECS description
>> language generation. The C++ code is generated from the ECS description
>> language.
>
> So you finally mention this after how many posts?

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.

>
>>> You don't understand the whole point of uuids, that pretty clear.
>>
>> That is a description of yourself not me. You didn't even know what UUIDs
>> were before I created this topic on this Usenet group.
>
> No, of course I didn't, they'd completely passed me by in the 25 years I've
> worked in IT.

Liar.

>
>>> Why are you conflating namespaces with a string of bytes stored in a class
>>> or similar to identify then? They are unrelated.
>>
>> Without a namespace the string would be inordinately long which takes time
>> to compare with other strings. Even with a namespace the typical string
>> would have more bytes than a UUID. A typically namespace would be a URL:
>> see XML namespaces.
>
> So exactly how many classes are you expecting in this system? Just a rough
> round number.

The number of classes isn't the problem: guaranteeing unique
identification for a class is. But as I said in my previous post it isn't
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.

>
>>> Doesn't it? You'll be able to guess what this is for then won't you:
>>>
>>> mpz_set_str(P,\
>>> "FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1"
>>> "29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD"
>>> "EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245"
>>> "E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED"
>>>
>>> etc
>>
>> etc? As I said previously hex digits are the canonical way to represent a
>> UUID.
>
> Do you need the definition of etc or do you want to see the whole thing? Ok:
>
> mpz_set_str(P,\
> "FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1"
> "29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD"
> "EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245"
> "E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED"
> "EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D"
> "C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F"
> "83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D"
> "670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B"
> "E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9"
> "DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510"
> "15728E5A 8AACAA68 FFFFFFFF FFFFFFFF",16);

That doesn't look like a UUID to me. UUIDs have 128-bits.

>
> Any clearer? Anyone who knows about encryption might recognise it. Why not
> tell us what it is since you seem to view yourself as some kind of genius.

Irrelevant.

>
>
>>> This is a C++ group, not javascript, object types = class and classes are
>>> fixed. And if your uses subclasses your classes then his class will end up
>> with
>>> the same fixed uuid which is idiotic.
>>
>> No ECS objects are not just instances of classes they can also be
>> dynamically generated at runtime from a script/database (so will use the
>
> I don't give a rats arse what poxy little game dev scripting language
> thinks it is , its what C++ that comes out the other end that matters.
> Now are these uuids linked to a classs or instantiated objects? You don't
> have any other options. If its classes please explain why you have so many
> you need uuids to id them.

It is for both. ECS component can have either a static (C++ class)
definition or a dynamic definition; both types require a UUID to uniquely
identify the ECS component.

>
>> HAS TO BE THE SAME EVERY TIME THE PROGRAM IS RUN.
>
> So they are hard coded then. Make your fucking mind up.

No they are not "hard coded"; they are generated once using a UUID
generator and then put in the appropriate place.

>
>>>> A hard coded UUID for internal reserved type identification makes perfect
>>>> sense as does using UUIDs for user created types that can be serialized to
>>>> file; used in scripts etc.
>>>
>>> I suppose it makes sense if you've only ever experienced the uuid fuckwittery
>>
>>> in Windows and think its a sane model to copy.
>>>
>>>> So I repeat what I said earlier: get a fucking clue you fucktarded
>> cockwomble.
>>>
>>> Look in the mirror sonny.
>>
>> Again I repeat: get a fucking clue you fucktarded cockwomble.
>
> Can't say I'm surprised you keep repeating yourself, you don't really even
> seem to understand why you're using uuids yourself other than ECS (written
> by someone else who obviously was smarter than you) uses them.

Someone else wrote my ECS? Amazing given that I haven't finished
implementing it.

Again I repeat: get a fucking clue you fucktarded cockwomble.

[Alf P. Steinbach]

On 07.08.2018 18:14, Mr Flibble wrote:
> On 07/08/2018 10:02, bol...@cylonHQ.com wrote:
>> On Mon, 6 Aug 2018 17:12:58 +0100
>> Mr Flibble <flibbleREM...@i42.co.uk> wrote:
>>>
>>> You didn't even know what UUIDs
>>> were before I created this topic on this Usenet group.
>>
>> No, of course I didn't, they'd completely passed me by in the 25 years
>> I've
>> worked in IT.
>
> Liar.
>

I've killfiled Boltar (so far eight identities, I think it is), and I
suggest you do the same.


Cheers!,

- Alf

[Scott Lurndal]

Mr Flibble <flibbleREM...@i42.co.uk> writes:
>On 07/08/2018 10:02, bol...@cylonHQ.com wrote:
>> On Mon, 6 Aug 2018 17:12:58 +0100
>> Mr Flibble <flibbleREM...@i42.co.uk> wrote:
>>> On 06/08/2018 09:44, bol...@cylonHQ.com wrote:
>>>> Even less reason to use them then since there will be an order of magnitude
>>>> less to deal with.
>>>
>>> The problem isn't the number of IDs the problem is guaranteeing the
>>> uniqueness of the IDs without using a central authority to generate them.
>>> UUIDs are perfect for this.
>>
>> So you're just hoping they don't collide by making them very large. You have
>> to love the fingers crossed approach.
>
>Finger's crossed? Again educate yourself on the nature of UUIDs: chance of
>collision is very low.

Some references for the galactica fan

$ man uuidgen
NAME
uuidgen - create a new UUID value

SYNOPSIS
uuidgen [options]

DESCRIPTION
The uuidgen program creates (and prints) a new universally unique iden-
tifier (UUID) using the libuuid(3) library. The new UUID can reason-
ably be considered unique among all UUIDs created on the local system,
and among UUIDs created on other systems in the past and in the future.

There are two types of UUIDs which uuidgen can generate: time-based
UUIDs and random-based UUIDs. By default uuidgen will generate a ran-
dom-based UUID if a high-quality random number generator is present.
Otherwise, it will choose a time-based UUID. It is possible to force
the generation of one of these two UUID types by using the -r or -t
options.

https://en.wikipedia.org/wiki/Universally_unique_identifier

[Siri Cruise]

In article <xcGdncdHbYzoWPTG...@giganews.com>,

Mr Flibble <flibbleREM...@i42.co.uk> wrote:

> >> The problem isn't the number of IDs the problem is guaranteeing the
> >> uniqueness of the IDs without using a central authority to generate them.
> >> UUIDs are perfect for this.
> >
> > So you're just hoping they don't collide by making them very large. You have
> > to love the fingers crossed approach.
>
> Finger's crossed? Again educate yourself on the nature of UUIDs: chance of
> collision is very low.

The question is does the world end in case of a collision or is there some kind
of recovery?

--
:-<> 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]

On 8/7/2018 2:30 PM, Siri Cruise wrote:
> The question is does the world end in case of a collision or is there some kind
> of recovery?

Unless there is a central authority issuing truly unique ids relative to
the system (and the things it communicates with using those uuids), the
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.

It's not a good solution outside of a central issuing authority.

--
Rick C. Hodgin

[Scott Lurndal]

"Rick C. Hodgin" <rick.c...@gmail.com> writes:
>On 8/7/2018 2:30 PM, Siri Cruise wrote:
>> The question is does the world end in case of a collision or is there some kind
>> of recovery?
>
>Unless there is a central authority issuing truly unique ids relative to
>the system (and the things it communicates with using those uuids), the
>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.

That's not true at at all. With the current algorithms, you must
generate over a trillion UUID's to have a one-in-one-billion chance
of a collision.

>
>It's not a good solution outside of a central issuing authority.

That's not a correct statement, not the least because it fails
to consider the problem being solved with a UUID.

[Chris M. Thomasson]

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.

[Scott Lurndal]

That's true of any traffic, hence the existence of TLS. There's nothing
special about a UUID vis-a-vis traffic security.

[Rick C. Hodgin]

> On 8/7/2018 12:54 PM, Scott Lurndal wrote:

I don't read your posts, Scott. They go straight to trash on my
Usenet reader. I only saw this one because Chris quoted it. I
won't be able to reply to you unless it's quoted again by someone.

>>> Unless there is a central authority issuing truly unique ids relative to
>>> the system (and the things it communicates with using those uuids), the
>>> 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.
>>
>> That's not true at at all.   With the current algorithms, you must
>> generate over a trillion UUID's to have a one-in-one-billion chance
>> 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. That
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.

If you have a sole central source issuing uuids, that's a different
matter and remains secure.

--
Rick C. Hodgin

[Öö Tiib]

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]

On 8/7/2018 7:09 PM, Öö Tiib wrote:
> 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.

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.

> 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.

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]

In article <pkcps1$1fe$1...@dont-email.me>,

"Rick C. Hodgin" <rick.c...@gmail.com> wrote:

> On 8/7/2018 2:30 PM, Siri Cruise wrote:
> > The question is does the world end in case of a collision or is there some
> > kind
> > of recovery?
>
> Unless there is a central authority issuing truly unique ids relative to
> the system (and the things it communicates with using those uuids), the
> 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.

[Rick C. Hodgin]

On 8/7/2018 8:07 PM, Siri Cruise wrote:
> In article <pkcps1$1fe$1...@dont-email.me>,
> "Rick C. Hodgin" <rick.c...@gmail.com> wrote:
>
>> On 8/7/2018 2:30 PM, Siri Cruise wrote:
>>> The question is does the world end in case of a collision or is there some
>>> kind
>>> of recovery?
>>
>> Unless there is a central authority issuing truly unique ids relative to
>> the system (and the things it communicates with using those uuids), the
>> 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.

Agreed. With the ECS in question, I mean seriously ... what's the
worst that could happen? :-)

--
Rick C. Hodgin

[bol...@cylonhq.com]

On Tue, 7 Aug 2018 17:03:49 +0100
Mr Flibble <flibbleREM...@i42.co.uk> wrote:
>On 07/08/2018 10:05, bol...@cylonHQ.com wrote:
>> He can't seem to make his mind up if his uuid's are hard coded or not, he
>> just waffles about his ECS system generating them. I don't think he really
>> understands what it does or why it does it and I'm not even sure he
>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.

[pooro...@oldfolkshome.com]

On Tue, 7 Aug 2018 18:17:52 +0200
"Alf P. Steinbach" <alf.p.stein...@gmail.com> wrote:
>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]

On 07/08/18 23:27, Rick C. Hodgin wrote:
>> On 8/7/2018 12:54 PM, Scott Lurndal wrote:
>
> I don't read your posts, Scott. They go straight to trash on my
> Usenet reader. I only saw this one because Chris quoted it. I
> won't be able to reply to you unless it's quoted again by someone.
>
>>>> Unless there is a central authority issuing truly unique ids
>>>> relative to
>>>> the system (and the things it communicates with using those uuids), the
>>>> 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.
>>>
>>> That's not true at at all. With the current algorithms, you must
>>> generate over a trillion UUID's to have a one-in-one-billion chance
>>> 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.

> That
> 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.

[bol...@cylonhq.com]

On Wed, 08 Aug 2018 11:28:31 +0200
David Brown <david...@hesbynett.no> wrote:
>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]

On 08/08/18 11:54, bol...@cylonHQ.com wrote:
> On Wed, 08 Aug 2018 11:28:31 +0200
> David Brown <david...@hesbynett.no> wrote:
>> 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.

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.

>
> 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.
>

As I said, some people are dishonest, making MAC addresses less unique
than in theory.

[bol...@cylonhq.com]

On Wed, 08 Aug 2018 12:41:08 +0200

David Brown <david...@hesbynett.no> wrote:
>On 08/08/18 11:54, bol...@cylonHQ.com wrote:
>> On Wed, 08 Aug 2018 11:28:31 +0200
>> David Brown <david...@hesbynett.no> wrote:
>>> 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.
>
>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.

Yup, missed that. My mistake.

>> ** 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.

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]

On 08/08/18 13:31, bol...@cylonHQ.com wrote:
> On Wed, 08 Aug 2018 12:41:08 +0200
> David Brown <david...@hesbynett.no> wrote:
>> On 08/08/18 11:54, bol...@cylonHQ.com wrote:
>>> On Wed, 08 Aug 2018 11:28:31 +0200
>>> David Brown <david...@hesbynett.no> wrote:
>>>> 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.
>>
>> 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.
>
> Yup, missed that. My mistake.

Fair 'nuff.

>
>>> ** 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.
>
> 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]

On 8.08.2018 11:50, bol...@cylonHQ.com wrote:
> On Tue, 7 Aug 2018 17:03:49 +0100
> Mr Flibble <flibbleREM...@i42.co.uk> wrote:

>> 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.

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]

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 Lurndal]

"Rick C. Hodgin" <rick.c...@gmail.com> writes:

>> 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.

[David Brown]

On 08/08/18 15:12, Rick C. Hodgin wrote:
> On Wednesday, August 8, 2018 at 5:28:43 AM UTC-4, David Brown wrote:
>> [snip]
>
> Use them in your systems then.
>

They are not something I need in my systems. But I certainly would have
no fear of them. I've used random identifications with far fewer
entropy bits than UUIDs with no fear of collisions.

[Rick C. Hodgin]

It is an inappropriate and even foolish design, in my opinion, when
used for unique ids. Tick tock, David san.

--
Rick C. Hodgin

[bol...@cylonhq.com]

On Wed, 08 Aug 2018 15:33:55 +0300
Paavo Helde <myfir...@osa.pri.ee> wrote:
>On 8.08.2018 11:50, bol...@cylonHQ.com wrote:
>> On Tue, 7 Aug 2018 17:03:49 +0100
>> Mr Flibble <flibbleREM...@i42.co.uk> wrote:
>
>>> 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.
>
>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. [...]"

Thats an object in the low level sense, not in the OO sense. An object in the
latter has to be instantiated from a class or cloned from a prototype. If basic
types were objects then that would make C an object oriented language too which
clearly it is not.

[bol...@cylonhq.com]

On Wed, 08 Aug 2018 13:50:40 +0200
David Brown <david...@hesbynett.no> wrote:

>On 08/08/18 13:31, bol...@cylonHQ.com wrote:
>> 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.

Given a lot of these chains advertised free wifi and it was only when you
got there you found out about the time limit I'm not going to well up with
guilt over it. Thankfully those days are past anyway.

[David Brown]

Fortunately, your opinion is not relevant here. I've explained why
worrying about random UUID collisions is not sensible. If you don't
understand the maths involved, that's fine - trust someone who does. I
/do/ understand the maths - as does Mr. Flibble (who is the one actually
using them here). A great many other people use UUIDs for all sorts of
purposes - either they understand the maths, or they are willing to
trust those who do.

As for "tick tock", perhaps you think it is only a matter of time before
it is inevitable that there will be a UUID collision. Mathematically,
that is of course nonsense. But it /is/ possible to give some numbers.
If a new UUID is generated by some programmer every second, there will
come a point where there is at least a 50% chance that it will collide
with a previous random UUID. That time will be in about 86 billion
years - about 6 times the age of the universe.

Call me irresponsible, but I'd say that at that point, it would not be
my problem any more.

[David Brown]

Like it or not, the C standard defines "object" in a specific way - and
C++ defines it in the same way. It is /not/ the same meaning as the
term used in "object oriented language". In C++, "object" means what
the standards say it means. (And for most purposes, the language does
not make a distinction between objects that are simple, standard types
like "int" and class instantiations.)

[Paavo Helde]

It was yourself who introduced the topic of objects in this thread:

"I'm not even sure he understands the difference between a class and an
object in C++".

Note the qualification you used - "in C++". Had you said "in OOP" or
something, then indeed int would not qualify. But in C++ int is an
object, period.

Also, look at the name of the newsgroup you are posting. At any time one
is talking about an "object" without qualification in this group this
means "C++ object".

> If basic
> types were objects then that would make C an object oriented language too which
> clearly it is not.

No, it would not. Besides, the whole C standard is built upon the notion
of object, see 3.15/1 in the latest C standard draft
(http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf):

"object - region of data storage in the execution environment, the
contents of which can represent value"

The C standard is full of statements like:

"An object declared as type signed char occupies the same amount of
storage as a “plain” char object".

[bol...@cylonhq.com]

On Wed, 08 Aug 2018 16:52:08 +0200
David Brown <david...@hesbynett.no> wrote:
>On 08/08/18 16:17, bol...@cylonHQ.com wrote:
>> latter has to be instantiated from a class or cloned from a prototype. If
>basic
>> types were objects then that would make C an object oriented language too
>which
>> clearly it is not.
>>
>
>Like it or not, the C standard defines "object" in a specific way - and
>C++ defines it in the same way. It is /not/ the same meaning as the
>term used in "object oriented language". In C++, "object" means what

Quite. So lets drop the pedantry shall we?

[bol...@cylonhq.com]

On Wed, 08 Aug 2018 18:04:08 +0300
Paavo Helde <myfir...@osa.pri.ee> wrote:

>On 8.08.2018 17:17, bol...@cylonHQ.com wrote:
>> latter has to be instantiated from a class or cloned from a prototype.
>
>It was yourself who introduced the topic of objects in this thread:
>
>"I'm not even sure he understands the difference between a class and an
>object in C++".

The meaning would be crystal clear to a native english speaker. Perhaps
something got lost in translation for you.

>No, it would not. Besides, the whole C standard is built upon the notion

Yes it would be. You can't have it both ways, either object simply means an
addressable non text area memory location defined by a name in the language
or it means something instantiated from a class. If its the former then C is
an OO language. Take your pick.

>"object - region of data storage in the execution environment, the
>contents of which can represent value"
>
>The C standard is full of statements like:
>
>"An object declared as type signed char occupies the same amount of
>storage as a “plain” char object".

The english language is vague and words can have double meanings, it doesn't
mean all meanings apply in all cases. I'd have thought that was obvious.

[Rick C. Hodgin]

On Wednesday, August 8, 2018 at 10:43:19 AM UTC-4, David Brown wrote:
> ...I've explained why
> worrying about random UUID collisions is not sensible...

It's a simple matter: collisions remain possible. It is an
improper design given there are algorithms and protocols which
can guarantee no collisions, even using far fewer bits, which
give confidence that the possibility of failure at any time is
not lurking over your head in uncertainty.

To me it's a straight-forward train of thought to seek another
solution.

We'll never agree on this. I resign from the "discussion." I
wish you well when you "place your bets."

--
Rick C. Hodgin

[Paavo Helde]

On 8.08.2018 18:21, bol...@cylonHQ.com wrote:
> On Wed, 08 Aug 2018 18:04:08 +0300
> Paavo Helde <myfir...@osa.pri.ee> wrote:
>> On 8.08.2018 17:17, bol...@cylonHQ.com wrote:
>>> latter has to be instantiated from a class or cloned from a prototype.
>>
>> It was yourself who introduced the topic of objects in this thread:
>>
>> "I'm not even sure he understands the difference between a class and an
>> object in C++".
>
> The meaning would be crystal clear to a native english speaker. Perhaps
> something got lost in translation for you.

You are not going to wiggle out of this, so better stop now.

>
>> No, it would not. Besides, the whole C standard is built upon the notion
>
> Yes it would be. You can't have it both ways, either object simply means an
> addressable non text area memory location defined by a name in the language
> or it means something instantiated from a class. If its the former then C is
> an OO language. Take your pick.

No, it's not. In the context of a standardized programming language
which happens to define "object", object means exactly that and nothing
else.

>
>> "object - region of data storage in the execution environment, the
>> contents of which can represent value"
>>
>> The C standard is full of statements like:
>>
>> "An object declared as type signed char occupies the same amount of
>> storage as a “plain” char object".
>
> The english language is vague and words can have double meanings, it doesn't
> mean all meanings apply in all cases. I'd have thought that was obvious.

That's why we have standards. That's why when you say "object in C++"
this means "object in C++".

[Mr Flibble]

This is not an OOP newsgroup it is a C++ newsgroup and C++ is a
multi-paradigm programming language with object oriented features and NOT
an object oriented programming language. An example of an object oriented
programming language would be Java.

Like it or not the default terms of reference which defines our *default*
terminology for discussion used in this newsgroup is the C++ programming
language as defined by the C++ ISO Standard which clearly states that in
C++ an object isn't just an instance of a class. The fact that you were
ignorant of this fact doesn't change anything including your fractal
wrongness mainly because you are such an obtuse fucker who will not back
down despite the evidence and admit his mistake.

/Flibble

--
"Suppose it’s all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I’d say, bone cancer in children? What’s that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It’s not right, it’s utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That’s what I would say."

[Mr Flibble]

So you are just as egregious IRL as you are on the Internet. Thieving scum.

[Mr Flibble]

On 08/08/2018 09:50, bol...@cylonHQ.com wrote:
> On Tue, 7 Aug 2018 17:03:49 +0100
> Mr Flibble <flibbleREM...@i42.co.uk> wrote:
>> On 07/08/2018 10:05, bol...@cylonHQ.com wrote:
>>> He can't seem to make his mind up if his uuid's are hard coded or not, he
>>> just waffles about his ECS system generating them. I don't think he really
>>> understands what it does or why it does it and I'm not even sure he
>> 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.

So says you.

>
>> 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.

If you were intelligent enough to make the not too large mental leap you
would have realized that I was wasn't conflating anything but that in my
use the word "namespace" I was referring to namespaces in general and not
a C++ namespace: in fact I believe I even mentioned XML namespaces in one
of my replies.

>
>> 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.

See elsewhere in this thread for why you don't have a fucking clue what a
C++ object is.

>
>> 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.

See elsewhere in this thread for why this isn't an issue of any great
importance.

>
>> 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.

"Hard coded" suggests I didn't automatically generate the UUID but that I
just made it up; I didn't.

>
>>> 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.

Given the fractal wrongness on several issues that you have displayed in
this thread I think it is safe to continue with the assumption that you
are fucking clueless.

>
>> 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.

ECS component classes created independently by different people on
different projects that use my ECS need to be unique with respect to each
other to ensure any inter-operation wouldn't be an issue. In case you
haven't noticed people share a lot more code today than they did even
decade ago.

>
>> 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.

I need a UUID for my use-cases.

>
>> 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.

And I repeat: hex numbers are the canonical way to represent UUIDs even in
code.

>
>> 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.

Correcting your vomit replies isn't being defensive it is just being
helpful to other casual readers of this thread.

Again I repeat: get a fucking clue you fucktarded cockwomble.

[David Brown]

As long as you are happy that in a C++ discussion on c.l.c++, "object"
means what C++ says it means - and not what you apparently thought it
meant. When you are in a Java newsgroup, or a Smalltalk newsgroup, you
can use their terms - when you are in a C++ newsgroup, use C++ terms.
It makes discussions /so/ much easier, and saves pointless arguments
where one side is so clearly wrong.

[Chris M. Thomasson]

On 8/7/2018 1:46 PM, Scott Lurndal wrote:

> "Chris M. Thomasson" <invalid_chr...@invalid.invalid> writes:
>> On 8/7/2018 12:54 PM, Scott Lurndal wrote:
>>> "Rick C. Hodgin" <rick.c...@gmail.com> writes:

>>>> On 8/7/2018 2:30 PM, Siri Cruise wrote:
>>>>> The question is does the world end in case of a collision or is there some kind
>>>>> of recovery?

>>>>
>>>> Unless there is a central authority issuing truly unique ids relative to
>>>> the system (and the things it communicates with using those uuids), the
>>>> 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.
>>>
>>> That's not true at at all. With the current algorithms, you must
>>> generate over a trillion UUID's to have a one-in-one-billion chance
>>> of a collision.
>>>
>>>>

>>>> It's not a good solution outside of a central issuing authority.
>>>
>>> That's not a correct statement, not the least because it fails
>>> 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.
>

Right. Rick now needs to worry about possible HMAC and/or MAC
collisions. If he sends a UUID, and it meets the dreaded "something in
the middle" that maliciously alters even a single bit, well... Not good.

;^)

[Rick C. Hodgin]

On 08/08/2018 04:09 PM, Chris M. Thomasson wrote:
> Right. Rick now needs to worry about possible HMAC and/or MAC
> collisions. If he sends a UUID, and it meets the dreaded "something in
> the middle" that maliciously alters even a single bit, well... Not good.

Separate issue, and one rooted in hardware and infrastructure that may
be outside of my control. Very little you can do about that. You can
only encrypt and work with your payload, not the delivery system.

--
Rick C. Hodgin

[Chris M. Thomasson]

On 8/7/2018 5:21 PM, Rick C. Hodgin wrote:
> On 8/7/2018 8:07 PM, Siri Cruise wrote:
>> In article <pkcps1$1fe$1...@dont-email.me>,

>>   "Rick C. Hodgin" <rick.c...@gmail.com> wrote:
>>
>>> On 8/7/2018 2:30 PM, Siri Cruise wrote:
>>>> The question is does the world end in case of a collision or is
>>>> there some
>>>> kind
>>>> of recovery?
>>>
>>> Unless there is a central authority issuing truly unique ids relative to
>>> the system (and the things it communicates with using those uuids), the
>>> 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.
>
>
> Agreed.  With the ECS in question, I mean seriously ... what's the
> worst that could happen? :-)
>

In the context of a game, what about cheating and forging UUID's?

[Chris M. Thomasson]

You can try to double check UUID's with the "central" data farm,
however, they still need to be HMAC or MAC'ed. It seems to want to boil
down to the forging of UUID's and exploits in the hash used for the MAC's.

Design your own crypto strong hash. I have some highly experimental
algorithms based on fractals, still not sure about their strength.

[Mr Flibble]

And Satan invented fossils yes?

[Rick C. Hodgin]

On Wednesday, August 8, 2018 at 5:20:09 PM UTC-4, Mr Flibble wrote:
> And Satan invented fossils yes?

Do you enjoy lies and falseness? Or do you seek the truth?
Will you investigate a claim of fact, one of science, one
contrary to your current belief?

https://answersingenesis.org/fossils/

https://www.youtube.com/watch?v=XY7tDeQHdY8

Ignorance is bliss, but the truth establishes the foundation.

Would you even dare to muster up enough courage to peek
inside, Leigh? Or do you like gambling not only on uuid
uniqueness, but also your own eternal fate?

What'll it be? "Cluck cluck?" Or "Oh... interesting?"

--
Rick C. Hodgin

[Mr Flibble]

Speed of light mate.

[bol...@cylonhq.com]

On Wed, 08 Aug 2018 18:38:33 +0300

Paavo Helde <myfir...@osa.pri.ee> wrote:
>On 8.08.2018 18:21, bol...@cylonHQ.com wrote:
>> On Wed, 08 Aug 2018 18:04:08 +0300
>> Paavo Helde <myfir...@osa.pri.ee> wrote:
>>> On 8.08.2018 17:17, bol...@cylonHQ.com wrote:
>>>> latter has to be instantiated from a class or cloned from a prototype.
>>>
>>> It was yourself who introduced the topic of objects in this thread:
>>>
>>> "I'm not even sure he understands the difference between a class and an
>>> object in C++".
>>
>> The meaning would be crystal clear to a native english speaker. Perhaps
>> something got lost in translation for you.
>
>You are not going to wiggle out of this, so better stop now.

I'm not wriggling, but you seem to be somewhat.

>> Yes it would be. You can't have it both ways, either object simply means an
>> addressable non text area memory location defined by a name in the language
>> or it means something instantiated from a class. If its the former then C is
>> an OO language. Take your pick.
>
>No, it's not. In the context of a standardized programming language
>which happens to define "object", object means exactly that and nothing
>else.

SO when I refered to classes and objects you thought I was talking about the
C++ definition of class but the CS definition of object? You're an idiot.

[bol...@cylonhq.com]

On Wed, 8 Aug 2018 17:28:27 +0100
Mr Flibble <flibbleREM...@i42.co.uk> wrote:
>ignorant of this fact doesn't change anything including your fractal
>wrongness mainly because you are such an obtuse fucker who will not back
>down despite the evidence and admit his mistake.

You really need to sort out your tourettes.

>If you were intelligent enough to make the not too large mental leap you
>would have realized that I was wasn't conflating anything but that in my
>use the word "namespace" I was referring to namespaces in general and not
>a C++ namespace: in fact I believe I even mentioned XML namespaces in one
>of my replies.

So when caught out you use the old "Oh, but I meant the OTHER definition of
xyz..". Yeah, nice try, doesn't wash.

>this thread I think it is safe to continue with the assumption that you
>are fucking clueless.

Says the guy who couldn't even put 2+2 together when I posted what was
clearly an encyrption key and even mentioned encryption. "Duh, hey Yogi, that
doesn't look like a uuid! Huh?".

>Correcting your vomit replies isn't being defensive it is just being
>helpful to other casual readers of this thread.
>Again I repeat: get a fucking clue you fucktarded cockwomble.

Ah , my "vomit" replies, "cockwomble". You really do come across as a arsey
little brat. Coding C++ in 1993? I doubt you were even born then.

>So you are just as egregious IRL as you are on the Internet. Thieving scum.

Aww, don't be jealous. Just because you're too dumb to have figured it out
yourself :)

[Paavo Helde]

On 9.08.2018 11:39, bol...@cylonHQ.com wrote:

> SO when I refered to classes and objects you thought I was talking about the
> C++ definition of class but the CS definition of object?

Look at the name of the newsgroup. If you talk about classes or objects
here then this is about C++ classes and objects, unless clearly stated
otherwise.

[bol...@cylonhq.com]

Clang:

$ cat t.cc
int main()
{
int i;
i.~int();
return 0;
}
$ c++ t.cc
t.cc:4:5: error: expected a class name after '~' to name a destructor
i.~int();
^
1 error generated.

gcc:
$ c++ t.cc
t.cc: In function ‘int main()’:
t.cc:4: error: expected class-name before ‘int’
t.cc:4: error: expected ‘;’ before ‘int’

Oops. What was it you were saying about simple type instances being objects?

[David Brown]

They are objects. They are not objects of a type which have destructors
that can be called like this.

What is your point here - that you would rather argue indefinitely,
making yourself look even more ignorant and pig-headed, than accept you
were wrong about a simple piece of terminology? You've blown this all
completely out of proportion, and you are only making it worse for yourself.

You are in a hole. Stop digging, and lets close this thread.

[bol...@cylonhq.com]

On Thu, 09 Aug 2018 15:20:47 +0200
David Brown <david...@hesbynett.no> wrote:
>On 09/08/18 15:14, bol...@cylonHQ.com wrote:
>> Oops. What was it you were saying about simple type instances being objects?
>>
>
>They are objects. They are not objects of a type which have destructors
>that can be called like this.

Quite, they're not class based objects which is what I was talking about
when I said he didn't know the difference between classes and objects. The
other poster is estonian, English obviously isn't his first language so maybe
he missed that. Whats your excuse?

>What is your point here - that you would rather argue indefinitely,
>making yourself look even more ignorant and pig-headed, than accept you
>were wrong about a simple piece of terminology? You've blown this all

I'm not wrong.

>completely out of proportion, and you are only making it worse for yourself.
>
>You are in a hole. Stop digging, and lets close this thread.

I'm not in the hole, I'm standing at the edge looking at the fools who've
fallen into it. Whats it like down there?

[Paavo Helde]

On 9.08.2018 16:14, bol...@cylonHQ.com wrote:
> On Thu, 09 Aug 2018 13:23:43 +0300
> Paavo Helde <myfir...@osa.pri.ee> wrote:
>> On 9.08.2018 11:39, bol...@cylonHQ.com wrote:
>>
>>> SO when I refered to classes and objects you thought I was talking about the
>>> C++ definition of class but the CS definition of object?
>>
>> Look at the name of the newsgroup. If you talk about classes or objects
>> here then this is about C++ classes and objects, unless clearly stated
>> otherwise.
>
> Clang:
>
> $ cat t.cc
> int main()
> {
> int i;
> i.~int();
> return 0;
> }
> $ c++ t.cc
> t.cc:4:5: error: expected a class name after '~' to name a destructor
> i.~int();
> ^
> 1 error generated.

An int is an object in C++ as defined by C++ standard. This has nothing
to do with the existence of destructors. Consult your C++ textbook about
the language basics, inventing and spreading your own silly fantasies is
not useful for anything.

Besides:

template<typename T>
void foo() {
T i;
i.~T();
}


int main() {
foo<int>();
}

This compiles fine and shows that object types, including int, are
handled uniformly in C++ where it makes sense and does matter (in
templates).

[Paavo Helde]

On 9.08.2018 16:52, bol...@cylonHQ.com wrote:
> On Thu, 09 Aug 2018 15:20:47 +0200
> David Brown <david...@hesbynett.no> wrote:
>> On 09/08/18 15:14, bol...@cylonHQ.com wrote:
>>> Oops. What was it you were saying about simple type instances being objects?
>>>
>>
>> They are objects. They are not objects of a type which have destructors
>> that can be called like this.
>
> Quite, they're not class based objects which is what I was talking about
> when I said he didn't know the difference between classes and objects. The
> other poster is estonian, English obviously isn't his first language so maybe
> he missed that. Whats your excuse?

Boltar, once more I re-post your original statement which introduced the
subject of objects in this thread:

"I'm not even sure he understands the difference between a class and an
object in C++."

To which Mr Flibble answered:

"Ironically your wording 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."

To that you responded

"Not in C++ it isn't. An object has a specific definition and an "int"

is not an object.",

revealing that Mr Flibble was right and you had no clue what is called
object in C++. Hopefully you have by now learned something from this
thread, although you don't want to admit that by some weird reason.

[David Brown]

On 09/08/18 15:52, bol...@cylonHQ.com wrote:
> On Thu, 09 Aug 2018 15:20:47 +0200
> David Brown <david...@hesbynett.no> wrote:
>> On 09/08/18 15:14, bol...@cylonHQ.com wrote:
>>> Oops. What was it you were saying about simple type instances being objects?
>>>
>>
>> They are objects. They are not objects of a type which have destructors
>> that can be called like this.
>
> Quite, they're not class based objects which is what I was talking about
> when I said he didn't know the difference between classes and objects. The
> other poster is estonian, English obviously isn't his first language so maybe
> he missed that. Whats your excuse?

Paavo has an excellent mastery of English.

Everyone else here is aware of the use of the word "object" as "instance
of a class type" in many programming languages - equally, we are aware
of the word "object" as (approximately) "identified region of memory
representing some value", as used in C and C++. If you want to use the
word "object" in a C++ discussion, please learn the difference and use
the term appropriately - with qualifications as necessary.

The big joke here is you were getting this wrong while gratuitously
insulting a long-term group member who has an excellent grasp of C++ in
theory and in practice. He may be a bit of a potty-mouth, but he has
demonstrated a far greater knowledge of the language than you have.

>
>> What is your point here - that you would rather argue indefinitely,
>> making yourself look even more ignorant and pig-headed, than accept you
>> were wrong about a simple piece of terminology? You've blown this all
>
> I'm not wrong.
>
>> completely out of proportion, and you are only making it worse for yourself.
>>
>> You are in a hole. Stop digging, and lets close this thread.
>
> I'm not in the hole, I'm standing at the edge looking at the fools who've
> fallen into it. Whats it like down there?
>

When everyone else says something different from you, you've got to ask
yourself - am I so much smarter and more knowledgeable than everyone
else here put together, or could it be that I am wrong?

You figure it out.

[bol...@cylonhq.com]

Most people used to think the world was flat and made in 7 days. Your
point is?

[bol...@cylonhq.com]

A rather contrived example. The fact is simple types are treated differently
to objects. Its not up for debate.

[bol...@cylonhq.com]

On Thu, 09 Aug 2018 17:16:19 +0300
Paavo Helde <myfir...@osa.pri.ee> wrote:
>On 9.08.2018 16:52, bol...@cylonHQ.com wrote:
>> On Thu, 09 Aug 2018 15:20:47 +0200
>> David Brown <david...@hesbynett.no> wrote:
>>> On 09/08/18 15:14, bol...@cylonHQ.com wrote:
>>>> Oops. What was it you were saying about simple type instances being
>objects?
>>>>
>>>
>>> They are objects. They are not objects of a type which have destructors
>>> that can be called like this.
>>
>> Quite, they're not class based objects which is what I was talking about
>> when I said he didn't know the difference between classes and objects. The
>> other poster is estonian, English obviously isn't his first language so maybe
>
>> he missed that. Whats your excuse?
>
>Boltar, once more I re-post your original statement which introduced the
>subject of objects in this thread:
>
>"I'm not even sure he understands the difference between a class and an
>object in C++."

As I said, your English comprehension is perhaps lacking and you didn't
get the fact I was comparing a class with a class instance. Next time I'll
be sure to to clarify it just for you. Ok?

[Paavo Helde]

Thanks, we all understood perfectly well that you wanted to compare a
class with a class instance. The problem is you used a wrong term, the
term "object" is not synonymous with "class instance" in C++. Mr Flibble
started to nitpick you about that and it went downhill from there for you.

> Next time I'll
> be sure to to clarify it just for you. Ok?

Does this mean you have learned the difference? Cool!

[Paavo Helde]

The instances of simple types *are* objects in C++, so how could they be
treated differently from themselves?

[Rick C. Hodgin]

Many people still think the world is flat. There's actually this huge
movement by the anti-Christ spirit to infiltrate the church and sow
those seeds of doubt and confusion beginning sometime in 2016. And so
many people today are even buying into it.

But, the world was made in seven days. Literal 24-hour days. It is
as is recorded in Genesis 1-3.

There really is evidence for the things of the Bible. Archaeological
evidence. Genetics evidence. Fossil record evidence.

--
Rick C. Hodgin

[Mr Flibble]

On 09/08/2018 16:24, Rick C. Hodgin wrote:
> On 8/9/2018 10:39 AM, bol...@cylonHQ.com wrote:
>> On Thu, 09 Aug 2018 16:27:03 +0200
>> David Brown <david...@hesbynett.no> wrote:
>>> When everyone else says something different from you, you've got to ask
>>> yourself - am I so much smarter and more knowledgeable than everyone
>>> else here put together, or could it be that I am wrong?
>>>
>>> You figure it out.
>>
>> Most people used to think the world was flat and made in 7 days. Your
>> point is?
>
>
> Many people still think the world is flat.  There's actually this huge
> movement by the anti-Christ spirit to infiltrate the church and sow
> those seeds of doubt and confusion beginning sometime in 2016.  And so
> many people today are even buying into it.

Who cares about what is upsetting the god botherers? I certainly don't care.

>
> But, the world was made in seven days.  Literal 24-hour days.  It is
> as is recorded in Genesis 1-3.

Assertions made without evidence can be dismissed without evidence.

>
> There really is evidence for the things of the Bible.  Archaeological
> evidence.  Genetics evidence.  Fossil record evidence.

There is no evidence that Genesis is true and there is no evidence that
your assertion that there is is true so that assertion can also be
summarily dismissed.

#atheism

[Rick C. Hodgin]

On Thursday, August 9, 2018 at 12:00:25 PM UTC-4, Mr Flibble wrote:
> There is no evidence that Genesis is true and there is no evidence that
> your assertion that there is is true so that assertion can also be
> summarily dismissed.
>
> #atheism

Your flesh won't want to read this. You'll gloss over it with an
annoying "tl;dr" response. But if you bypass that attitude and
seek to expand yourself beyond your confined self-belief-dominion,
then you will learn something.

-----
What you speak of is in the flesh, Leigh. There is no evidence
in the flesh that anything I claim is true. There is evidence,
however, if you look at it that way, which the flesh cannot do.
But by the spirit, the evidence is everywhere. And to be truthful,
even your flesh knows it's true because God put His stamp on your
creation, but in your sin and rebellion you deny the truth, so you
discount it by a conscious effort.

The thing you must understand is God is not flesh. He is spirit.
And for those who will be saved, their personal existence will be
changed and augmented beyond just flesh into both flesh + spirit.
John 3 describes this. When that happens, you are then aware of
things you could not be aware of before. You can hear God's guid-
ance, and not as a literal voice, but as your new sense guides you
from within. It's like how your eyes give you different input than
your ears. Now your spirit gives you different input than your
flesh.

-----
It is the spirit that affirms the things the flesh cannot know.
And it's why you are absolutely resolute in your belief that you
are right, just as I was before I was saved, because in my flesh
I knew I was right. I knew there could be no God. And I knew I
couldn't be wrong. Period and paragraph. End of discussion.

But... what I was not prepared for was the change that comes
when I sought the truth with a serious seeking, and God knew
I was seeking the truth and He brought it to me, and me to it.
Then my spiritual eyes were opened and then I was able to know
the things you could not know before.

It still, to this day some 14+ years later, astounds me daily,
because God never leaves you or abandons you.

Amazing Grace:

"I once was lost, but now am found.
Was blind, but now I see."

Those words convey this concept completely.

-----
Go to your local churches and speak to people who are born
again. Ask them for true born again believers who can give
you testimony about the changes the've had in their lives.

There's someone named Dawn Martin there in England in London
who you could speak to. She could teach you personally.
And there are countless others.

Pick some and go speak to them and listen to them, not me,
and see if they don't teach you the same things I'm teaching
you.

--
Rick C. Hodgin

[Mr Flibble]

On 09/08/2018 19:26, Rick C. Hodgin wrote:
> On Thursday, August 9, 2018 at 12:00:25 PM UTC-4, Mr Flibble wrote:
>> There is no evidence that Genesis is true and there is no evidence that
>> your assertion that there is is true so that assertion can also be
>> summarily dismissed.
>>
>> #atheism
>
> Your flesh won't want to read this. You'll gloss over it with an

[snip]

tl;dr.

[Rick C. Hodgin]

On Thursday, August 9, 2018 at 3:22:42 PM UTC-4, Mr Flibble wrote:
> On 09/08/2018 19:26, Rick C. Hodgin wrote:
> > Your flesh won't want to read this. You'll gloss over it with an
> [snip]
> tl;dr.
>
> #atheism

It's your soul, Leigh. I can only point you to truth. It's not
my job to make you receive it. That's God's. Not everyone will
be saved.

--
Rick C. Hodgin

[Mr Flibble]

On 09/08/2018 21:08, Rick C. Hodgin wrote:
> On Thursday, August 9, 2018 at 3:22:42 PM UTC-4, Mr Flibble wrote:
>> On 09/08/2018 19:26, Rick C. Hodgin wrote:
>>> Your flesh won't want to read this. You'll gloss over it with an
>> [snip]
>> tl;dr.
>>
>> #atheism
>
> It's your soul, Leigh.

Souls don't exist.

> I can only point you to truth.

Your truth, my falsehood.

> It's not my job to make you receive it.

Then stop posting religious bullshit here.

> That's God's.

God doesn't exist.

> Not everyone will be saved.

Nobody will be "saved".

[guinne...@gmail.com]

On Thursday, 9 August 2018 21:36:03 UTC+1, Mr Flibble wrote:
> On 09/08/2018 21:08, Rick C. Hodgin wrote:
> > On Thursday, August 9, 2018 at 3:22:42 PM UTC-4, Mr Flibble wrote:
> >> On 09/08/2018 19:26, Rick C. Hodgin wrote:
> >>> Your flesh won't want to read this. You'll gloss over it with an
> >> [snip]
> >> tl;dr.
> >>
> >> #atheism
> >
> > It's your soul, Leigh.
>
> Souls don't exist.
>
> > I can only point you to truth.
>
> Your truth, my falsehood.
>
> > It's not my job to make you receive it.
>
> Then stop posting religious bullshit here.
>
> > That's God's.
>
> God doesn't exist.
>
> > Not everyone will be saved.
>
> Nobody will be "saved".
>
> #atheism

+1. Hear, hear.

[Chris M. Thomasson]

On 8/9/2018 1:35 PM, Mr Flibble wrote:
> On 09/08/2018 21:08, Rick C. Hodgin wrote:
>> On Thursday, August 9, 2018 at 3:22:42 PM UTC-4, Mr Flibble wrote:
>>> On 09/08/2018 19:26, Rick C. Hodgin wrote:
>>>> Your flesh won't want to read this.  You'll gloss over it with an
>>> [snip]
>>> tl;dr.
>>>
>>> #atheism
>>
>> It's your soul, Leigh.
>
> Souls don't exist.
>
>> I can only point you to truth.
>
> Your truth, my falsehood.
>
>> It's not my job to make you receive it.
>
> Then stop posting religious bullshit here.
>
>> That's God's.
>
> God doesn't exist.
>
>> Not everyone will be saved.
>
> Nobody will be "saved".
>
> #atheism

Atheist or not, imvvho, just try really hard to live a good life, and if
there is an afterlife, well... All of your great works on Earth should
be of wonderful service, and experience. If there is an afterlife, there
probably is a jail. Well, just keep on trying to be good, and no worries. :)

[Jorgen Grahn]

If we forget for a moment that boltar is (unsurprisingly) being an ass
about this, I have to say that when I read "object" in this group, I
tend to think the author doesn't mean an int. Even though I know C++
standard inherited the meaning of "object" from the C standard.

This ambiguity has never been a problem in reality, as far as I can
recall. When it /does/ matter it's usually clear from context.

/Jorgen

PS. It's a pity that the original "people say class when they mean
object" complaint got lost along the way.

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[bol...@cylonhq.com]

On Thu, 09 Aug 2018 17:59:07 +0300

Paavo Helde <myfir...@osa.pri.ee> wrote:
>On 9.08.2018 17:41, bol...@cylonHQ.com wrote:
>> On Thu, 09 Aug 2018 16:57:28 +0300
>> Paavo Helde <myfir...@osa.pri.ee> wrote:
>>> template<typename T>
>>> void foo() {
>>> T i;
>>> i.~T();
>>> }
>>>
>>>
>>> int main() {
>>> foo<int>();
>>> }
>>>
>>> This compiles fine and shows that object types, including int, are
>>> handled uniformly in C++ where it makes sense and does matter (in
>>> templates).
>>
>> A rather contrived example. The fact is simple types are treated differently
>> to objects.
>
>The instances of simple types *are* objects in C++, so how could they be
>treated differently from themselves?

Why not ask the authors of the compilers.

[bol...@cylonhq.com]

On Thu, 9 Aug 2018 11:24:09 -0400
"Rick Hodgin" <rick.c...@gmail.com> wrote:
>But, the world was made in seven days. Literal 24-hour days. It is
>as is recorded in Genesis 1-3.

Was that a long time before Smeagol found the ring? Oh wait, wrong fantasy
book.

>There really is evidence for the things of the Bible. Archaeological
>evidence. Genetics evidence. Fossil record evidence.

That fossil evidence is in the same layer as the unicorns presumably.

[bol...@cylonhq.com]

On 10 Aug 2018 07:18:55 GMT

Jorgen Grahn <grahn...@snipabacken.se> wrote:
>On Thu, 2018-08-09, Paavo Helde wrote:
>> The instances of simple types *are* objects in C++, so how could they be
>> treated differently from themselves?
>
>If we forget for a moment that boltar is (unsurprisingly) being an ass
>about this, I have to say that when I read "object" in this group, I

Perhaps I am being an ass, but pedantry for its own sake just gets up my
nose. When I say class and object in the same sentence I'm obviously not
talking about a uniquely referenced memory object, I'm talking about a class
instance.

>tend to think the author doesn't mean an int. Even though I know C++
>standard inherited the meaning of "object" from the C standard.

That fact that C calls these "objects" should have been a red flag, but no,
some people just love to argue.

[Rick C. Hodgin]

Investigate it.

You have information in your life now that there is information which
refutes the things you've learned your whole life. You have infor-
mation that there is an enemy bent on seeing your soul destroyed in
Hell. You have information that there is a loving God who came to the
Earth to save you.

The information is before you, and there are men and women like me
who are willing to teach you and answer any questions you have. You
will not enter Hell blindfolded. You will only enter Hell by choice
because everything you need to know the truth and have salvation has
been made available and set before you.

--
Rick C. Hodgin

[Chris M. Thomasson]

On 8/8/2018 1:34 PM, Rick C. Hodgin wrote:
> On 08/08/2018 04:09 PM, Chris M. Thomasson wrote:
>> Right. Rick now needs to worry about possible HMAC and/or MAC
>> collisions. If he sends a UUID, and it meets the dreaded "something in
>> the middle" that maliciously alters even a single bit, well... Not good.
>
>
> Separate issue, and one rooted in hardware and infrastructure that may
> be outside of my control. Very little you can do about that. You can
> only encrypt and work with your payload, not the delivery system.
>

The encryption can sort of, override the delivery system in a sense. If
Bob II cannot recreate the same hashes, then he knows something is not
Kosher with the payload, or ciphertext if you will.

[Chris M. Thomasson]

Actually, there is a way to make bit level sensitivity down to the
ciphertext level, HMAC or any MAC aside for a moment. Change one bit in
the ciphertext, and the decrypted result is radically different than the
original plaintext. Fwiw, the algorithm can be found here...

http://funwithfractals.atspace.cc/ct_cipher

[Rick C. Hodgin]

On 08/12/2018 03:32 AM, Chris M. Thomasson wrote:
> On 8/8/2018 1:34 PM, Rick C. Hodgin wrote:
>> On 08/08/2018 04:09 PM, Chris M. Thomasson wrote:
>>> Right. Rick now needs to worry about possible HMAC and/or MAC
>>> collisions. If he sends a UUID, and it meets the dreaded "something in
>>> the middle" that maliciously alters even a single bit, well... Not good.
>>
>> Separate issue, and one rooted in hardware and infrastructure that may
>> be outside of my control.  Very little you can do about that.  You can
>> only encrypt and work with your payload, not the delivery system.
>
> The encryption can sort of, override the delivery system in a sense.

You have to be able to have something like our existing RSA or
Diffie-Hellman exchange, then you can send something they can use
to encrypt, and send back, etc., then you can have secure connections
in both directions regardless of the man in the middle.

That's already well-established.

By delivery system I mean the physical layer, meaning you cannot
control if something makes it there or not. That's technology
outside of your control. But, you should be able to detect if
there is something invalid because the decrypting won't work as
it should.

> If
> Bob II cannot recreate the same hashes, then he knows something is not
> Kosher with the payload, or ciphertext if you will.

Bob II? Bob who? :-)

--
Rick C. Hodgin

[Mr Flibble]

On 12/08/2018 17:21, Rick C. Hodgin wrote:
> On 08/12/2018 03:32 AM, Chris M. Thomasson wrote:
>> On 8/8/2018 1:34 PM, Rick C. Hodgin wrote:
>>> On 08/08/2018 04:09 PM, Chris M. Thomasson wrote:
>>>> Right. Rick now needs to worry about possible HMAC and/or MAC
>>>> collisions. If he sends a UUID, and it meets the dreaded "something in
>>>> the middle" that maliciously alters even a single bit, well... Not good.
>>>
>>> Separate issue, and one rooted in hardware and infrastructure that may
>>> be outside of my control.  Very little you can do about that.  You can
>>> only encrypt and work with your payload, not the delivery system.
>>
>> The encryption can sort of, override the delivery system in a sense.
>
> You have to be able to have something like our existing RSA or
> Diffie-Hellman exchange, then you can send something they can use
> to encrypt, and send back, etc., then you can have secure connections
> in both directions regardless of the man in the middle.
>
> That's already well-established.
>
> By delivery system I mean the physical layer, meaning you cannot
> control if something makes it there or not. That's technology
> outside of your control. But, you should be able to detect if
> there is something invalid because the decrypting won't work as
> it should.

And Satan invented fossils yes?

[Chris M. Thomasson]

On 8/12/2018 9:21 AM, Rick C. Hodgin wrote:
> On 08/12/2018 03:32 AM, Chris M. Thomasson wrote:
>> On 8/8/2018 1:34 PM, Rick C. Hodgin wrote:
>>> On 08/08/2018 04:09 PM, Chris M. Thomasson wrote:
>>>> Right. Rick now needs to worry about possible HMAC and/or MAC
>>>> collisions. If he sends a UUID, and it meets the dreaded "something in
>>>> the middle" that maliciously alters even a single bit, well... Not good.
>>>
>>> Separate issue, and one rooted in hardware and infrastructure that may
>>> be outside of my control.  Very little you can do about that.  You can
>>> only encrypt and work with your payload, not the delivery system.
>>
>> The encryption can sort of, override the delivery system in a sense.
>
> You have to be able to have something like our existing RSA or
> Diffie-Hellman exchange, then you can send something they can use
> to encrypt, and send back, etc., then you can have secure connections
> in both directions regardless of the man in the middle.

Be careful:

https://weakdh.org

> That's already well-established.
>
> By delivery system I mean the physical layer, meaning you cannot
> control if something makes it there or not. That's technology
> outside of your control. But, you should be able to detect if
> there is something invalid because the decrypting won't work as
> it should.
>
>> If
>> Bob II cannot recreate the same hashes, then he knows something is not
>> Kosher with the payload, or ciphertext if you will.
>
> Bob II? Bob who? :-)
>

It is an ongoing thing over in sci.crypt. Bob I already died because of
a man in the middle attack. Now, Bob II took his place. We want to keep
him alive.

Bob I was directed to go to a certain area where he got beaten up really
bad, and finally murdered. Alice was nowhere in sight.

[Chris M. Thomasson]

Actually, iirc it was a mixture of a chosen plaintext and man in the
middle attacks.