Thursday, February 4, 2016

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

Lynn McGuire <lmc@winsim.com>: Feb 04 03:19PM -0600

I have an object called DataItem that is the basic variant storage unit for our software. In the latest release, there can be tens
of millions of these objects which is using up all our memory in Windows (we run out at 1.9 GB of memory usage). We cannot change to
x64 at the moment so I have decided to build a DataItem cache and use one DataItem for many of the same objects wherever possible. I
will use copy on write mechanism to create new DataItems that are being modified.
 
I have structured the DataItem cache using a vector inside a vector inside a map:
 
static std::map <int, std::vector <std::vector <DataItem *>>> g_DataItem_Cache;
 
In other words, a sparse cube. The outside map is for the identity of the major object type, i.e. SYM_AirCoolerGroup. The middle
vector is for the index of the DataItems in that group, i.e. AIR_DUT. The inside vector is for the various different copies of
DataItems that are referenced by that Data Group type and index. Each Data Group will need to know which version of the Data Item
that it is using.
 
I am wondering if I can make this more efficient (less memory usage). Any thoughts here? One of my staff is totally for this and
another is not. I am about 25% complete on making the code changes for testing.
 
Thanks,
Lynn
Paavo Helde <myfirstname@osa.pri.ee>: Feb 04 11:29PM +0200

On 4.02.2016 23:19, Lynn McGuire wrote:
> for our software. In the latest release, there can be tens of millions
> of these objects which is using up all our memory in Windows (we run out
> at 1.9 GB of memory usage).
 
AFAIK there is a simple way to increase that to 3 GB.
 
 
> I am wondering if I can make this more efficient (less memory usage).
> Any thoughts here? One of my staff is totally for this and another is
> not.
 
Totally for what? What is the alternative?
Lynn McGuire <lmc@winsim.com>: Feb 04 04:03PM -0600

On 2/4/2016 3:29 PM, Paavo Helde wrote:
>> Any thoughts here? One of my staff is totally for this and another is
>> not.
 
> Totally for what? What is the alternative?
 
We will hit the 3 GB barrier also using the current storage methodology.
 
My other programmer wants to move to x64. At least 1/4 of our customers are still running x86 Windows, not gonna happen yet.
 
Thanks,
Lynn
Paavo Helde <myfirstname@osa.pri.ee>: Feb 04 10:40PM +0200

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" <ootiib@hot.ee>: Feb 04 01:30PM -0800

On Thursday, 4 February 2016 22:40:40 UTC+2, Paavo Helde wrote:
> 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?
 
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.
 
> };
 
> 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 <vir.campestris@invalid.invalid>: Feb 04 09:35PM

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" <ootiib@hot.ee>: Feb 04 01:53PM -0800

On Thursday, 4 February 2016 23:31:05 UTC+2, Öö Tiib wrote:
> 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.
red floyd <no.spam@its.invalid>: Feb 04 11:11AM -0800

On 2/4/2016 10:38 AM, Andrea Venturoli wrote:
 
>> BOOST_CHECK_THROW(z(3,4))
 
> Think 20-40 lines of those comments, followed by the 20-40 lines of
> code, which soon will get out of sync.
 
I once had the dubious "pleasure" of examining code where the standards
said that each function would have a block comment describing
functionality.
 
So far, so good.
 
However, this code was written in Ada by an idiot who figured that since
well written Ada code was "self-documenting", the block comment was
literally a commented out copy of the function.
 
Of course, the code was neither well written nor self documenting.
 
FWIW, my block comments look like this:
 
//
// func_name() -- one line description
//
// INPUTS: [input 1] -- description or NONE
// ...
//
// OUTPUTS: [output 1] -- description
// ...
//
// RETURNS: description, or NONE
//
// Short description of what function is intended to do and why
//
red floyd <no.spam@its.invalid>: Feb 04 11:16AM -0800

On 2/4/2016 6:03 AM, Jerry Stuckle wrote:
 
> Well written comments indicate WHY the code does what it does. It also
> defines input and output conditions to a function, and other information
> not part of the code.
 
One time, I wrote a comment that was about five times the length of the
actual code. I was working on a Z80, and using 14-bit scaled fixed
point trig. To avoid losing precision when I multiplied the sines and
cosines, I had worked out a whole bunch of transformations that involved
adding angles instead of multiplying sin/cos.
 
The comment was the derivation of the transformations, since the code
was non-obvious. However, upon reading the comment, anyone familiar
with trig would understand what I had done, and why.
Jerry Stuckle <jstucklex@attglobal.net>: Feb 04 02:49PM -0500

On 2/4/2016 1:38 PM, Andrea Venturoli wrote:
>> BOOST_CHECK_THROW(g(0))
>> ...
>> BOOST_CHECK_THROW(z(3,4))
 
That's even worse than the one I saw (from a "senior" programmer who
didn't like to write documentation and had to be forced to do so):
 
i++; /* increment i */
 
 
> Of course, writing *why* something should fail would probably avoid
> wading through hundred of pages of technical specs, but that would be
> too good apparently.
 
BTDTGTTS!
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Juha Nieminen <nospam@thanks.invalid>: Feb 04 09:40PM

> have disastrous consequences if incorrect assumptions are made based on
> them.
 
> The best form of documentation is the code itself!
 
You comment *what* the code does, not *how*.
 
Except in cases of very complex algorithms, where it just can't be
clear from the implementation itself how and why the algorithm works.
In that case it's good to explain the algorithm.
 
Without comments it's hard to remember months later what does what,
so they are really useful.
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Vir Campestris <vir.campestris@invalid.invalid>: Feb 04 09:41PM

On 04/02/2016 19:16, red floyd wrote:
> One time, I wrote a comment that was about five times the length of the
> actual code.
 
The other day I put a comment against this:
 
char* workbuffer = malloc(strlen(input));
 
The code is correct. The first operation is guaranteed to remove at
least one char from the input, and put the rest in workbuffer. But it
looks wrong!
 
Andy
--
p.s. Didn't anyone like my German sausages?
Ian Collins <ian-news@hotmail.com>: Feb 05 08:22AM +1300

Daniel wrote:
> How do you organize your put-downs with regards to the number of posts you make? Lets say you have 20-30 different put-downs and each takes one to two lines of text, e.g. "you apparently haven't worked since the PC was invented", "leave you there in your own little out-of-date pigsty". Would you separate them to different posts or put them in the same post? Is it a good idea to have a lot of smaller put-downs in a post, or combine them?
 
Please learn to wrap your lines :)
 
--
Ian Collins
David Brown <david.brown@hesbynett.no>: Feb 04 09:44PM +0100

On 04/02/16 18:06, Daniel wrote:
> out-of-date pigsty". Would you separate them to different posts or
> put them in the same post? Is it a good idea to have a lot of smaller
> put-downs in a post, or combine them?
 
I'd say separate them, and try not to use the same put-down multiple
times. After all, a put-down has to be appropriate (used for someone
well beyond listening to reason), and it should not be too annoying to
other readers. So avoiding repetition is good, as is being witty in
some way. It can be okay to cut-and-paste the same put-down multiple
times in one reply, where the post is just so hopelessly wrong that it
is too much effort to correct. But repeating the same rather dull
put-down in multiple posts is poor style, IMHO.
Jerry Stuckle <jstucklex@attglobal.net>: Feb 04 01:58PM -0500

On 2/4/2016 12:32 PM, Richard wrote:
 
> I can do that too.
 
> The Utah group has met every month for it's entire existence.
 
> Therefore, the list is flawless.
 
Nope, just one of several examples of user groups which no longer exist
- and haven't, for quite a while.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
woodbrian77@gmail.com: Feb 04 12:24PM -0800

On Thursday, February 4, 2016 at 12:58:12 PM UTC-6, Jerry Stuckle wrote:
 
> > Therefore, the list is flawless.
 
> Nope, just one of several examples of user groups which no longer exist
> - and haven't, for quite a while.
 
I could put some of the "meetings" in a different
section and mention that they may no longer be
meeting. Besides Washington, DC what others do you
think are no longer meeting?
 
I hope to help start a C++ group in the St. Paul,
Minnesota area. My plan is to meet quarterly rather
than monthly. I think it's pretty tough to come up
with good content on a monthly basis. It would be
great if some of the groups that have stopped meeting
would restart on a less ambitious basis.
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
Jerry Stuckle <jstucklex@attglobal.net>: Feb 04 03:35PM -0500

> section and mention that they may no longer be
> meeting. Besides Washington, DC what others do you
> think are no longer meeting?
 
Sacramento, for one. I'm sure if you're interested you can find others.
 
 
> Brian
> Ebenezer Enterprises
> http://webEbenezer.net
 
That's nice. But the only thing worse than no list is an incorrect list.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 04 08:15PM

Hi!
 
Just to let you peeps know that progress is proceeding well on a brand
new OpenGL/SDL based C++ GUI library called "neogfx". I hope to have it
finished by the end of summer. N.B. not a sausage in sight!
 
http://neogfx.org
https://github.com/FlibbleMr/neogfx
 
/Flibble
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 04 06:52PM

On 04/02/2016 17:17, Öö Tiib wrote:
> {
> v.visit(*this);
> }
 
It leaks into the widget_visitor interface which has to know about radio
buttons: widget_visitor would be a closed class yet would have to have a
visit method for each widget type which just isn't feasible.
 
/Flibble
"Öö Tiib" <ootiib@hot.ee>: Feb 04 12:05PM -0800

On Thursday, 4 February 2016 20:52:19 UTC+2, Mr Flibble wrote:
 
> It leaks into the widget_visitor interface which has to know about radio
> buttons: widget_visitor would be a closed class yet would have to have a
> visit method for each widget type which just isn't feasible.
 
Ok, so then you are out of tools I suspect. Double dispatch is inappropriate.
Making 'set_on_state' virtual feels even worse. Things like boost::variant
and polymorphic_get can only result with 'dynamic_cast' written more
verbosely. So there is only 'dynamic_cast' left I suspect.
Jerry Stuckle <jstucklex@attglobal.net>: Feb 04 01:56PM -0500

On 2/4/2016 12:23 PM, Öö Tiib wrote:
> On Thursday, 4 February 2016 19:04:35 UTC+2, Jerry Stuckle wrote:
 
>> Oink, oink!
 
> Jerry, dating that Circe is clearly not good to your health.
 
Just trying to teach a pig to sing!
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Jerry Stuckle <jstucklex@attglobal.net>: Feb 04 01:57PM -0500

On 2/4/2016 12:29 PM, Geoff wrote:
 
> This, from someone who claims to have 30 years industrial experience
> and to be a consultant and project manager, demonstrates an astounding
> level of immaturity.
 
Just trying to teach a pig to sing!
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Ian Collins <ian-news@hotmail.com>: Feb 05 08:06AM +1300

Jerry Stuckle wrote:
 
> Real project management uses repos, not file systems, to store the code.
 
So where do these repos live?
 
--
Ian Collins
Ian Collins <ian-news@hotmail.com>: Feb 05 08:16AM +1300

Jerry Stuckle wrote:
 
>>> I understand that. And what does your disk do?
 
>> So you did you say "you won't get 100MB/s throughput on a lan"?
 
> You won't get it through a WAN, either, with your disk. Oink, oink.
 
Ah, I see you are unable to put up anything close to a coherent argument
and have reverted to type. I was expecting more, but life is full of
disappointments.
 
I don't have "a disk" I have a storage pool. I'm happy to explain how
they work (I build them for a living) and to refer you to the
appropriate forum if you with to learn something. I doubt that you will
take me up on either offer.
 
--
Ian Collins
Ian Collins <ian-news@hotmail.com>: Feb 05 08:18AM +1300

Jerry Stuckle wrote:
 
> Real projects don't depend on disk file systems. They use repos. But
> you've never worked on a real project - one that has been properly
> managed. And a file system is NOT a repository.
 
Where do your mythical "repos" live?
 
If you can't answer that simple question, game over.
 
Do you even know what a repo is?
 
If you can't answer that simple question either, game over.
--
Ian Collins
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)