Derivation without size increase?

[Paavo Helde]

I have a base class with sizeof 24. There are zillions of objects of
this class so I have tried to get the size of this class to minimum.
Actually the needed size is less than 24, but because of alignment it is
rounded up to 24. Let's say:

class A {
double x[2];
char buffer[6];
char tag;
// ...
};

Now there is another class which uses this class as a storage component
and and adds an additional tag. Logically the relationship is more like
a compound than derivation, but I would not care much which it
technically is:

class B {
A base;
char anotherTag;
public:
B(SomeClass arg, char type): base(arg), anotherTag(type) {}
// ...
};

The size of B is not 24 or 25, but 32, because alignment. This means 33%
increase in size, even though 'anotherTag' could fit in the unused byte
in the end of the A class. As there are zillions of these objects
created and processed as well, I would not like to waste space and
performance just because of that. How to have a clean solution in C++
without increasing the size of objects?

My current solution is to derive B from A and put 'protected char
anotherTag;' in A, where it is not initialized or accessed; it is only
initialized and accessed by Derived constructors and member functions.

class A {
double x[2];
char buffer[6];
char tag;
protected:
char anotherTag;
// ...
};

class B: public A {
public:
Derived(SomeClass arg, char type): A(arg) { anotherTag=type;}
// ...
};

However, this creates a data member in A which is totally unneeded and
unused. Is there a better solution?

[Öö Tiib]

The data layout is only guaranteed for standard-layout classes and when
there is inheritance then it is not standard-layout unless all non-static
data members are in one class.

>
> My current solution is to derive B from A and put 'protected char
> anotherTag;' in A, where it is not initialized or accessed; it is only
> initialized and accessed by Derived constructors and member functions.
>
> class A {
> double x[2];
> char buffer[6];
> char tag;
> protected:
> char anotherTag;
> // ...
> };
>
> class B: public A {
> public:
> Derived(SomeClass arg, char type): A(arg) { anotherTag=type;}
> // ...
> };
>
> However, this creates a data member in A which is totally unneeded and
> unused. Is there a better solution?

You can add array of chars at end that fills it up (to 24 bytes or 32 bytes)
and lets the potential composites containing it or derived classes derived
from it to use such 'A::vacantStorage'. You won't get data member semantics
that way but what is going on (optimization) is hopefully easier to read
out of it.

[Vir Campestris]

On 04/02/2016 20:40, Paavo Helde wrote:
>
> However, this creates a data member in A which is totally unneeded and
> unused. Is there a better solution?

I wonder if you could do something with templates:

class A {
double x[2];
char buffer[6];
char tag;
// ...
};

template <typename parent> class W
{
parent instanceofA;
char anotherTag;
// ...
}

typedef W<A> B;

You might want to play with the pack pragma too if your platform
supports it.

Andy

[Öö Tiib]

On Thursday, 4 February 2016 23:31:05 UTC+2, Öö Tiib wrote:
>
> You can add array of chars at end that fills it up (to 24 bytes or 32 bytes)
> and lets the potential composites containing it or derived classes derived
> from it to use such 'A::vacantStorage'. You won't get data member semantics
> that way but what is going on (optimization) is hopefully easier to read
> out of it.

Note that 'std::array<char,x>' is POD and methods of it are 'constexpr'
since C++14 so I typically use it instead of raw array of char.

[Marcel Mueller]

On 04.02.16 21.40, Paavo Helde wrote:
> class B {
> A base;
> char anotherTag;
> public:
> B(SomeClass arg, char type): base(arg), anotherTag(type) {}
> // ...
> };
>
> The size of B is not 24 or 25, but 32, because alignment.

You are on a 64 bit platform?
I would have expected 28 otherwise.

> created and processed as well, I would not like to waste space and
> performance just because of that. How to have a clean solution in C++
> without increasing the size of objects?

#pragma pack does the magic for me:

#include <stdio.h>
#pragma pack(1)

class A {
double x[2];
char buffer[6];
char tag;
// ...
};

class B {
A base;
char anotherTag;
public:

B(A arg, char type): base(arg), anotherTag(type) {}
// ...
};
int main()
{ printf("%i\n", sizeof(B));
return 0;
}

=> 24

> My current solution is to derive B from A and put 'protected char
> anotherTag;' in A, where it is not initialized or accessed; it is only
> initialized and accessed by Derived constructors and member functions.

This is an option.

> However, this creates a data member in A which is totally unneeded and
> unused. Is there a better solution?

Does your platform support #pragma pack?

Since A is a POD you could also use offsetof to find the amount of free
space in A.


Marcel

[Öö Tiib]

Yes, but that is typical best case test. Add those lines to your 'main':

printf("%i\n", (int)sizeof(A));
A c[2];
printf("%i\n", (int)sizeof c);

That results likely with 23 and 46 there.
So making array of 'A'-s will get your 'A::x' single byte aligned. It
may cause performance drop (needs profiling) that OP does not
want.

[Jerry Stuckle]

Exactly how many are "zillions"? Even if you have 1,000,000 of them at
the same time (very doubtful - trying to process that many items would
take a lot of time), you're only talking about 8 MB of additional memory.

--
==================
Remove the "x" from my email address
Jerry Stuckle
jstu...@attglobal.net
==================

[Paavo Helde]

On 5.02.2016 16:43, Marcel Mueller wrote:
> On 04.02.16 21.40, Paavo Helde wrote:
>> class B {
>> A base;
>> char anotherTag;
>> public:
>> B(SomeClass arg, char type): base(arg), anotherTag(type) {}
>> // ...
>> };
>>
>> The size of B is not 24 or 25, but 32, because alignment.
>
> You are on a 64 bit platform?
> I would have expected 28 otherwise.

Doesn't matter, the doubles in A require 8-byte alignment, which 28 is not.

>
>> created and processed as well, I would not like to waste space and
>> performance just because of that. How to have a clean solution in C++
>> without increasing the size of objects?
>
> #pragma pack does the magic for me:
>
> #include <stdio.h>
> #pragma pack(1)
> class A {
> double x[2];
> char buffer[6];
> char tag;
> // ...
> };
> class B {
> A base;
> char anotherTag;
> public:
> B(A arg, char type): base(arg), anotherTag(type) {}
> // ...
> };
> int main()
> { printf("%i\n", sizeof(B));
> return 0;
> }
>
> => 24

#pragma pack(1) does indeed work (with MSVC), but then sizeof(A)==23.
This means that when placed in an array, larger members like doubles
inside A would be misaligned and cause performance hits.

If I put #pragma pack(1) only before B, then sizeof(A)==24 and
sizeof(B)==25, which is not better.

I could probably derive both A and B from a common sizeof 23 base and
add 'char unused;' or something like that to A. Then sizeof(A)==24, but
I'm afraid the compiler would still think the required alignment is 1
and would not align the objects in memory properly.

Interestingly enough, the other platform which we need to support (gcc
on x64 Linux) seems to do the right thing (sizeof(A)==24,
sizeof(B)==24), with no pragmas or additional flags needed.

Cheers,
Paavo

[Paavo Helde]

On 5.02.2016 17:32, Jerry Stuckle wrote:
> Exactly how many are "zillions"? Even if you have 1,000,000 of them at
> the same time (very doubtful - trying to process that many items would
> take a lot of time), you're only talking about 8 MB of additional memory.

Yes, it might well be that I am wasting my time on a premature
optimization, but I was just curious if using C++ abstractions would
indeed somehow work against the zero overhead principle.

But as I have now seen that gcc does the right thing without any tricks,
I am starting to think this is just a quality of implementation issue.

Cheers
Paavo

[Marcel Mueller]

On 05.02.16 17.08, Paavo Helde wrote:
>>> The size of B is not 24 or 25, but 32, because alignment.
>>
>> You are on a 64 bit platform?
>> I would have expected 28 otherwise.
>
> Doesn't matter, the doubles in A require 8-byte alignment, which 28 is not.

Think, you are a bit too fast.
A 32 bit platform never needs 64 bit alignment.

> #pragma pack(1) does indeed work (with MSVC),

I tested with gcc.

> but then sizeof(A)==23.

That was the intention of the OP.

> This means that when placed in an array, larger members like doubles
> inside A would be misaligned and cause performance hits.

True. One have to take care about that.

> I could probably derive both A and B from a common sizeof 23 base and
> add 'char unused;' or something like that to A.

No #pragma pack should do the job as well. Hmm, seems only to work if
new members are added.

class A
{ union
{ A_base a;
int dummy[(sizeof(A)-1)/sizeof(int)+1];
};
};

... not that pretty.

> Interestingly enough, the other platform which we need to support (gcc
> on x64 Linux) seems to do the right thing (sizeof(A)==24,
> sizeof(B)==24), with no pragmas or additional flags needed.

So probably the optimizer has been enhanced.

This is always the problem with optimization. At some point they work
against you.

[...]
It does not work for me without pragma. B grows one machine size word.
Neither gcc 4.7.2 @ Debian amd64 nor gcc 4.8.4 @ Mint 17 x86 nor gcc
4.9.2 @ Raspbian ARMv6 nor gcc 3.3.5 @ eCS x86 nor IBM icc 3.08 @ eCS x86.

But the above hack works with all of them.


Marcel

[Jerry Stuckle]

Like any performance issue, I concern myself with it when it becomes a
problem, not before. For instance, in your case, I would be very
concerned if this were running on an embedded processor with 512K of
RAM. However, if it's running on a machine with 5GB (or even 50MB) of
RAM, I'd be less concerned until it became a problem.

It may very well be this can cause a problem. If it is, you'll need to
fix it. But remember also that the compilers align data for performance
reasons, also. It's faster to load/store an integer when it's on a 4
byte boundary in most 32 bit processors, for instance. Compressing your
structure may end up slowing the application down. Or, by not using as
much memory, you may cause less paging and application performance may
improve. You just don't know at this point.

Almost every performance issue is a tradeoff somewhere. It's a matter
of finding the right tradeoff.

[Paavo Helde]

On 5.02.2016 19:00, Marcel Mueller wrote:
> On 05.02.16 17.08, Paavo Helde wrote:
>>>> The size of B is not 24 or 25, but 32, because alignment.
>>>
>>> You are on a 64 bit platform?
>>> I would have expected 28 otherwise.
>>
>> Doesn't matter, the doubles in A require 8-byte alignment, which 28 is
>> not.
>
> Think, you are a bit too fast.
> A 32 bit platform never needs 64 bit alignment.

Yes, you are right. It seems I have started to forget about 32-bit world
only after a few years.

>> #pragma pack(1) does indeed work (with MSVC),
>
> I tested with gcc.
>
>> but then sizeof(A)==23.
>
> That was the intention of the OP.

No, not at all.

>
>> Interestingly enough, the other platform which we need to support (gcc
>> on x64 Linux) seems to do the right thing (sizeof(A)==24,
>> sizeof(B)==24), with no pragmas or additional flags needed.
>
> So probably the optimizer has been enhanced.
>
> This is always the problem with optimization. At some point they work
> against you.
>
> [...]
> It does not work for me without pragma. B grows one machine size word.
> Neither gcc 4.7.2 @ Debian amd64 nor gcc 4.8.4 @ Mint 17 x86 nor gcc
> 4.9.2 @ Raspbian ARMv6 nor gcc 3.3.5 @ eCS x86 nor IBM icc 3.08 @ eCS x86.

For any case, I tried with an example which resembles my real code more
exactly:

~>cat main.cpp
#include <iostream>
#include <stdint.h>
#include <string>

class X;

class A {
union xunion {
int64_t k;
double f;
const void *p;
struct Extra {
std::string* s;
X* x;
} x;
char buf[16];
} x;
struct {
char buf_continued[6];
} y;
char tag;
};


class B: A {
char anotherTag;
public:
// ...
};

int main() {
std::cout << "sizeof(A)==" << sizeof(A) << "\nsizeof(B)==" <<
sizeof(B) << "\n";
return 0;
}

~>g++ -Wall main.cpp

~>./a.out
sizeof(A)==24
sizeof(B)==24

~>g++ -v
...
gcc version 4.6.2 (SUSE Linux)

Maybe they have abandoned this optimization in later versions...

MSVC produces 24 and 32 for this code, or 23 and 24 with #pragma pack(1).

[Robert Wessel]

On Fri, 05 Feb 2016 18:00:30 +0100, Marcel Mueller
<news.5...@spamgourmet.org> wrote:

>On 05.02.16 17.08, Paavo Helde wrote:
>>>> The size of B is not 24 or 25, but 32, because alignment.
>>>
>>> You are on a 64 bit platform?
>>> I would have expected 28 otherwise.
>>
>> Doesn't matter, the doubles in A require 8-byte alignment, which 28 is not.
>
>Think, you are a bit too fast.
>A 32 bit platform never needs 64 bit alignment.

There is certainly no such rule. S/360 required 64-bit alignment for
both a number of integer operations that accessed memory and for
doubles, and IIRC, Alpha required doubles to be 64-bit aligned even
when the system was used as a 32 bit one, as the versions of Windows
for Alpha did. Requiring more than 32-bit alignment for doubles is
not that uncommon in hardware, and is preferred in many cases for
performance reasons even if the hardware does not require it.

[Paavo Helde]

And SSE2 et al require or strongly encourage 128-bit alignment also on
32-bit x86.

[Marcel Mueller]

On 06.02.16 14.20, Paavo Helde wrote:
>> There is certainly no such rule. S/360 required 64-bit alignment for
>> both a number of integer operations that accessed memory and for
>> doubles, and IIRC, Alpha required doubles to be 64-bit aligned even
>> when the system was used as a 32 bit one, as the versions of Windows
>> for Alpha did. Requiring more than 32-bit alignment for doubles is
>> not that uncommon in hardware, and is preferred in many cases for
>> performance reasons even if the hardware does not require it.
>
> And SSE2 et al require or strongly encourage 128-bit alignment also on
> 32-bit x86.

Well, SSE2 is not really 32 bit, as well as Alpha 64 is not.


Marcel

[Jorgen Grahn]

On Fri, 2016-02-05, Jerry Stuckle wrote:
> On 2/4/2016 3:40 PM, Paavo Helde wrote:
>>
>> I have a base class with sizeof 24. There are zillions of objects of
>> this class so I have tried to get the size of this class to minimum.

...

> Exactly how many are "zillions"? Even if you have 1,000,000 of them at
> the same time (very doubtful - trying to process that many items would
> take a lot of time),

I don't want to nitpick, but a million objects is not that uncommon,
nor do they necessarily take a lot of time to process.

I don't believe you're making this mistake, but I sometimes meet
people who have absurdly low expectations in this area. Brute force,
modernish computers and the absence of total stupidity takes you far.
For example,

$ time od /dev/urandom| head -1000000 | sort | md5sum

Sorting those 1,000,000 lines of text takes 7 seconds on my machine,
which is ten years old. Calculating the checksum takes 200 ms.

> you're only talking about 8 MB of additional memory.

Yes.

/Jorgen

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

[Ian Collins]

Jorgen Grahn wrote:
> On Fri, 2016-02-05, Jerry Stuckle wrote:
>> On 2/4/2016 3:40 PM, Paavo Helde wrote:
>>>
>>> I have a base class with sizeof 24. There are zillions of objects of
>>> this class so I have tried to get the size of this class to minimum.

> ....

>
>> Exactly how many are "zillions"? Even if you have 1,000,000 of them at
>> the same time (very doubtful - trying to process that many items would
>> take a lot of time),
>
> I don't want to nitpick, but a million objects is not that uncommon,
> nor do they necessarily take a lot of time to process.
>
> I don't believe you're making this mistake, but I sometimes meet
> people who have absurdly low expectations in this area. Brute force,
> modernish computers and the absence of total stupidity takes you far.
> For example,
>
> $ time od /dev/urandom| head -1000000 | sort | md5sum
>
> Sorting those 1,000,000 lines of text takes 7 seconds on my machine,
> which is ten years old. Calculating the checksum takes 200 ms.

To be fair, that probably shows your /dev/urandom isn't as random as it
could be :)

I agree with everything else...

--
Ian Collins

[Jerry Stuckle]

It depends on the randomness and the operations being performed. A
simple sort of text could be quick . Other operations could take much
longer. How many applications have you had that actually have 1,000,000
objects in memory? I don't think in almost 50 years of programming I
have ever had it. But I have used databases with tens of billions of rows.

And, as Ian pointed out, your urandom may not be so random.

[Öö Tiib]

Yes in 80s it happened rarely since good hard drive was 20 MB. Now it is
common, yet another damn 10MB xml file to chew or other crap like that.

[Ian Collins]

Jerry Stuckle wrote:
>
> It depends on the randomness and the operations being performed. A
> simple sort of text could be quick . Other operations could take much
> longer. How many applications have you had that actually have 1,000,000
> objects in memory? I don't think in almost 50 years of programming I
> have ever had it. But I have used databases with tens of billions of rows.

Only one of mine - an in-memory file metadata database for a filesystem
with several million files in a million odd directories! It used about
4GB of RAM...

--
Ian Collins

[Jerry Stuckle]

You don't have tens of billions of rows on a 20MB drive, either.

A 10MB xml file will not have > 1M items - that would be less than 10
chars per item, including syntactical characters and newline characters.
And I'm not talking about PC's with 20MB disk drives. I'm also talking
about mainframes with terabytes of drives.

[woodb...@gmail.com]

On Monday, February 8, 2016 at 7:31:29 PM UTC-6, Öö Tiib wrote:

Please don't swear here.

Brian
Ebenezer Enterprises
http://webEbenezer.net

[Ian Collins]

woodb...@gmail.com wrote:

> On Monday, February 8, 2016 at 7:31:29 PM UTC-6, 嘱 Tiib wrote:
>
> Please don't swear here.

Do what? Have you anything useful to contribute?

--
Ian Collins

[Chris Vine]

On Mon, 8 Feb 2016 18:41:00 -0800 (PST)
woodb...@gmail.com wrote:
> On Monday, February 8, 2016 at 7:31:29 PM UTC-6, Öö Tiib wrote:
>
> Please don't swear here.

Can you explain one thing for me? I have heard that Americans of a
tender disposition find the word "damn" offensive, particularly if
they are in their 70s or older. Apparently, Clark Gable's "Frankly, my
dear, I don't give a damn" in Gone with the Wind was regarded there as
slightly daring at the time.

This doesn't seem to be the case in any other part of the English
speaking world. Its root as you probably know is, via Middle French,
from the Latin damnare, which has no connotation of "swearing" as you
rather oddly like to put it. It meant to censure in some way, usually
by judicial authorities.

What about the word "damn" do you regard as offensive?

Chris

[David Brown]

Maybe his concern was the word "crap" - which is not really swearing
either. If I remember the derivation correctly, "crap" was the term for
the bits of impurities that floated to the top when rendering down whale
blubber to oil. (There is a popular myth that it comes from Thomas
Crapper, the inventor of the ball-and-cock mechanism of toilets.)

It is hard to imagine someone being so prudish as to be bothered by an
occasional "damn" or "crap". It is easy to imagine people being
irritated by repeated and pointless requests "please don't swear here".

[Chris Vine]

Ah right. Yes, I guess it might be crap which he was finding a
problem with. But it was Brian's view of the American use of damn which
I was interested in, and which he has objected to previously. For
example, one might read in the newspaper here that an official
investigation had given a "damning assessment" or issued a "damning
report" about something. I wonder if that would be regarded as
offensive amongst his co-religionists.

Interesting about the whale blubber, that's not one I have heard.
https://en.wikipedia.org/wiki/Thomas_Crapper says about crap that:

"The word crap is actually of Middle English origin and predates its
application to bodily waste. Its most likely etymological origin is a
combination of two older words, the Dutch krappen: to pluck off, cut
off, or separate; and the Old French crappe: siftings, waste or
rejected matter (from the medieval Latin crappa, chaff). In English,
it was used to refer to chaff, and also to weeds or other rubbish.
Its first application to bodily waste, according to the Oxford
English Dictionary, appeared in 1846 under a reference to a crapping
ken, or a privy, where ken means a house."

It seems to have retained its meaning of some kind of rubbish, and
this might well suggest that the expression was also applied to the
unwanted side products of dealing with whale blubber. Today, one might
often hear the expression "XXX is a piece of crap", meaning that it is
no good rather than that it is composed of animal or human excrement.
However, there are probably occasions you might choose not to use the
word because of its wider meaning, but I don't think newsgroups are one
of them.

One interesting feature of religious fruitcakes is that it is often the
absence of circumlocution they object to rather than the intent, which
seems rather odd. So, if someone like Brian objects to "damn", they do
not object to "dang". I don't know if Brian is of that persuasion.

Chris

[David Brown]

Certainly this is all consistent with the use of "crap" as the flotsam
to be scraped off and thrown away when boiling up blubber. But it is at
least equally possible that the derivation is much older, and that this
was just one use of the word. What we can say, is that the word itself
is not a swear word as such, even if it is sometimes used as swearing
(but the same can be said of "sugar").

[Scott Lurndal]

=?ISO-8859-1?Q?=D6=F6_Tiib?= <oot...@hot.ee> writes:

>Yes in 80s it happened rarely since good hard drive was 20 MB. Now it is
>common, yet another damn 10MB xml file to chew or other crap like that.

say what? We had 1GB disks in 1982[*].

We also had 5MB HPT disks for speed. We also had SSDs (using DRAM chips, not flash).

[*] http://www.chipsetc.com/memorex.html

[Scott Lurndal]

woodb...@gmail.com writes:

>On Monday, February 8, 2016 at 7:31:29 PM UTC-6, =D6=F6 Tiib wrote:
>
>Please don't swear here.
>

Damn straight, none of that shit here, please.

[Scott Lurndal]

Chris Vine <chris@cvine--nospam--.freeserve.co.uk> writes:
>On Mon, 8 Feb 2016 18:41:00 -0800 (PST)
>woodb...@gmail.com wrote:

>> On Monday, February 8, 2016 at 7:31:29 PM UTC-6, =C3=96=C3=B6 Tiib wrote:
>>=20

>> Please don't swear here.
>
>Can you explain one thing for me? I have heard that Americans of a
>tender disposition find the word "damn" offensive, particularly if
>they are in their 70s or older. Apparently, Clark Gable's "Frankly, my
>dear, I don't give a damn" in Gone with the Wind was regarded there as
>slightly daring at the time.
>
>This doesn't seem to be the case in any other part of the English
>speaking world. Its root as you probably know is, via Middle French,
>from the Latin damnare, which has no connotation of "swearing" as you
>rather oddly like to put it. It meant to censure in some way, usually
>by judicial authorities.
>
>What about the word "damn" do you regard as offensive?

I think it was the perfectly cromulent "crap" that he was complaining about.

[Geoff]

On Tue, 09 Feb 2016 14:55:58 GMT, sc...@slp53.sl.home (Scott Lurndal)
wrote:

Don't forget bubble memory! But that had nothing to do with speed. :)

[Jerry Stuckle]

Actually, I think the U.S. usage anyway came from a Londoner - Thomas
Crapper. While the common belief is that he invented the flush toilet,
he really didn't. He did, however, increase its popularity.

And during WWI, soldiers visiting the facilities would "take a crap".

Now the usage on the other side of the pond may be different.

[Jorgen Grahn]

On Tue, 2016-02-09, Jerry Stuckle wrote:
> On 2/8/2016 5:23 PM, Jorgen Grahn wrote:
>> On Fri, 2016-02-05, Jerry Stuckle wrote:
>>> On 2/4/2016 3:40 PM, Paavo Helde wrote:
>>>>
>>>> I have a base class with sizeof 24. There are zillions of objects of
>>>> this class so I have tried to get the size of this class to minimum.
>> ...
>>
>>> Exactly how many are "zillions"? Even if you have 1,000,000 of them at
>>> the same time (very doubtful - trying to process that many items would
>>> take a lot of time),
>>
>> I don't want to nitpick, but a million objects is not that uncommon,
>> nor do they necessarily take a lot of time to process.
>>
>> I don't believe you're making this mistake, but I sometimes meet
>> people who have absurdly low expectations in this area. Brute force,
>> modernish computers and the absence of total stupidity takes you far.
>> For example,
>>
>> $ time od /dev/urandom| head -1000000 | sort | md5sum
>>
>> Sorting those 1,000,000 lines of text takes 7 seconds on my machine,
>> which is ten years old. Calculating the checksum takes 200 ms.
>>
>>> you're only talking about 8 MB of additional memory.

> It depends on the randomness and the operations being performed. A
> simple sort of text could be quick . Other operations could take much
> longer. How many applications have you had that actually have 1,000,000
> objects in memory?

The one above, for example ... I didn't write sort(1) myself of
course, but I don't hesitate to operate on large data sets in Unix
pipelines.

And even I am frequently surprised when I see a badly written Perl
script chew up megabytes of data in almost no time at all.

> I don't think in almost 50 years of programming I have ever had it.
> But I have used databases with tens of billions of rows.

People do different things with computers, obviously.

I used to write simulators for mobile networks, and these were used to
simulate millions of cell phones doing stuff, each with one or more
data bearers (which also were modeled as objects, of course).

If you're asking because you still believe having a million objects is
a problem that needs special care, I can just say it never was, in my
experience.

I didn't have to do anything unusual to support that -- just normal
objects, and standard containers. I think at some point I analyzed
what used up memory in such an object, and split out things which were
shared by many similar CellPhone objects ... but that had more to do
with refactoring for clarity, and less with conservation of RAM.

> And, as Ian pointed out, your urandom may not be so random.

He did, but I fail to see how that's relevant. I just wanted to
produce a million lines of text, and forgot that I could use 'seq 1
1000000' instead of the head of an infinite sequence.

[David Brown]

On 09/02/16 19:15, Jerry Stuckle wrote:
> On 2/9/2016 9:36 AM, David Brown wrote:
>> On 09/02/16 15:13, Chris Vine wrote:
>>> On Tue, 09 Feb 2016 14:14:00 +0100
>>> David Brown <david...@hesbynett.no> wrote:

<snip>

>>>> Maybe his concern was the word "crap" - which is not really swearing
>>>> either. If I remember the derivation correctly, "crap" was the term
>>>> for the bits of impurities that floated to the top when rendering
>>>> down whale blubber to oil. (There is a popular myth that it comes
>>>> from Thomas Crapper, the inventor of the ball-and-cock mechanism of
>>>> toilets.)
>>>>

<snip>

>
> Actually, I think the U.S. usage anyway came from a Londoner - Thomas
> Crapper. While the common belief is that he invented the flush toilet,
> he really didn't. He did, however, increase its popularity.

Jerry, do you know why a "newsreader" program is called a "newsreader"?
It is because it allows you to /read/ postings on Usenet. Look a
little above, and you'll see that Thomas Crapper has already been mentioned.

>
> And during WWI, soldiers visiting the facilities would "take a crap".
>

<http://www.snopes.com/business/names/crapper.asp>

[Jerry Stuckle]

On 2/10/2016 4:52 AM, David Brown wrote:
> On 09/02/16 19:15, Jerry Stuckle wrote:
>> On 2/9/2016 9:36 AM, David Brown wrote:
>>> On 09/02/16 15:13, Chris Vine wrote:
>>>> On Tue, 09 Feb 2016 14:14:00 +0100
>>>> David Brown <david...@hesbynett.no> wrote:
>
> <snip>
>
>>>>> Maybe his concern was the word "crap" - which is not really swearing
>>>>> either. If I remember the derivation correctly, "crap" was the term
>>>>> for the bits of impurities that floated to the top when rendering
>>>>> down whale blubber to oil. (There is a popular myth that it comes
>>>>> from Thomas Crapper, the inventor of the ball-and-cock mechanism of
>>>>> toilets.)
>>>>>
>
> <snip>
>
>>
>> Actually, I think the U.S. usage anyway came from a Londoner - Thomas
>> Crapper. While the common belief is that he invented the flush toilet,
>> he really didn't. He did, however, increase its popularity.
>
> Jerry, do you know why a "newsreader" program is called a "newsreader"?
> It is because it allows you to /read/ postings on Usenet. Look a
> little above, and you'll see that Thomas Crapper has already been mentioned.
>

I did. I'm just pointing out that's why in the United States. Can you
post anything without an insult?

>>
>> And during WWI, soldiers visiting the facilities would "take a crap".
>>
>
> <http://www.snopes.com/business/names/crapper.asp>
>

http://www.urbandictionary.com/define.php?term=Crapper

>> Now the usage on the other side of the pond may be different.
>>
>

[woodb...@gmail.com]

On Tuesday, February 9, 2016 at 7:14:22 AM UTC-6, David Brown wrote:
> On 09/02/16 12:24, Chris Vine wrote:
> > On Mon, 8 Feb 2016 18:41:00 -0800 (PST)
> > woodb...@gmail.com wrote:
> >> On Monday, February 8, 2016 at 7:31:29 PM UTC-6, Öö Tiib wrote:
> >>
> >> Please don't swear here.
> >
> > Can you explain one thing for me? I have heard that Americans of a
> > tender disposition find the word "damn" offensive, particularly if
> > they are in their 70s or older. Apparently, Clark Gable's "Frankly, my
> > dear, I don't give a damn" in Gone with the Wind was regarded there as
> > slightly daring at the time.
> >
> > This doesn't seem to be the case in any other part of the English
> > speaking world. Its root as you probably know is, via Middle French,
> > from the Latin damnare, which has no connotation of "swearing" as you
> > rather oddly like to put it. It meant to censure in some way, usually
> > by judicial authorities.
> >
> > What about the word "damn" do you regard as offensive?
> >
>
> Maybe his concern was the word "crap" - which is not really swearing

I don't think "crap" is swearing.

http://www.wikihow.com/Stop-Swearing

[Ian Collins]

woodb...@gmail.com wrote:
> On Tuesday, February 9, 2016 at 7:14:22 AM UTC-6, David Brown wrote:
>> On 09/02/16 12:24, Chris Vine wrote:
>>> On Mon, 8 Feb 2016 18:41:00 -0800 (PST)
>>> woodb...@gmail.com wrote:

>>>> On Monday, February 8, 2016 at 7:31:29 PM UTC-6, 嘱 Tiib wrote:
>>>>
>>>> Please don't swear here.
>>>
>>> Can you explain one thing for me? I have heard that Americans of a
>>> tender disposition find the word "damn" offensive, particularly if
>>> they are in their 70s or older. Apparently, Clark Gable's "Frankly, my
>>> dear, I don't give a damn" in Gone with the Wind was regarded there as
>>> slightly daring at the time.
>>>
>>> This doesn't seem to be the case in any other part of the English
>>> speaking world. Its root as you probably know is, via Middle French,
>>> from the Latin damnare, which has no connotation of "swearing" as you
>>> rather oddly like to put it. It meant to censure in some way, usually
>>> by judicial authorities.
>>>
>>> What about the word "damn" do you regard as offensive?
>>>
>>
>> Maybe his concern was the word "crap" - which is not really swearing
>
>
> I don't think "crap" is swearing.

So what did you object to?

--
Ian Collins

[red floyd]

On 2/10/2016 11:04 AM, Ian Collins wrote:
> woodb...@gmail.com wrote:
>> On Tuesday, February 9, 2016 at 7:14:22 AM UTC-6, David Brown wrote:
>>> On 09/02/16 12:24, Chris Vine wrote:
>>>> On Mon, 8 Feb 2016 18:41:00 -0800 (PST)
>>>> woodb...@gmail.com wrote:

>>>>> On Monday, February 8, 2016 at 7:31:29 PM UTC-6, Öö Tiib wrote:
>>>>>
>>>>> Please don't swear here.
>>>>
>>>> Can you explain one thing for me? I have heard that Americans of a
>>>> tender disposition find the word "damn" offensive, particularly if
>>>> they are in their 70s or older. Apparently, Clark Gable's "Frankly, my
>>>> dear, I don't give a damn" in Gone with the Wind was regarded there as
>>>> slightly daring at the time.
>>>>
>>>> This doesn't seem to be the case in any other part of the English
>>>> speaking world. Its root as you probably know is, via Middle French,
>>>> from the Latin damnare, which has no connotation of "swearing" as you
>>>> rather oddly like to put it. It meant to censure in some way, usually
>>>> by judicial authorities.
>>>>
>>>> What about the word "damn" do you regard as offensive?
>>>>
>>>
>>> Maybe his concern was the word "crap" - which is not really swearing
>>
>>
>> I don't think "crap" is swearing.
>
> So what did you object to?
>

Who gives a shit?