Sunday, September 21, 2014

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

comp.lang.c++@googlegroups.com Google Groups
Unsure why you received this message? You previously subscribed to digests from this group, but we haven't been sending them for a while. We fixed that, but if you don't want to get these messages, send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Robert Hutchings <rm.hutchings@gmail.com>: Sep 21 08:36AM -0700


> Please don't snip attributions: doing so is considered as rude on Usenet.
> Ian Collins
 
 
Okay Ian. Is this better?
David Brown <david.brown@hesbynett.no>: Sep 21 06:25PM +0200

On 21/09/14 17:36, Robert Hutchings wrote:
 
>> Please don't snip attributions: doing so is considered as rude on Usenet.
>> Ian Collins
 
> Okay Ian. Is this better?
 
No, that is /not/ okay - you have snipped that attributions (the lines
at the top saying things like "On 21/09/14 17:36, Robert Hutchings wrote:").
 
Please look at almost anybody else's posts, and you will see how it
works. (This is also a matter of politeness in any situation - look at
how other people communicate, and try to fit in with the existing style.)
 
Of preference, you should get a proper newsreader and proper newserver,
rather than the google groups monstrosity. People have different
opinions on the best choices, but Thunderbird along with
news.eternal-september.org is a popular and free choice.
Robert Hutchings <rm.hutchings@gmail.com>: Sep 21 10:04AM -0700


> rather than the google groups monstrosity. People have different
 
> opinions on the best choices, but Thunderbird along with
 
> news.eternal-september.org is a popular and free choice.
 
 
 
On Sunday, September 21, 2014 11:26:12 AM UTC-5, David Brown wrote:
 
> rather than the google groups monstrosity. People have different
 
> opinions on the best choices, but Thunderbird along with
 
> news.eternal-september.org is a popular and free choice.
 
 
 
On Sunday, September 21, 2014 11:26:12 AM UTC-5, David Brown wrote:
 
 
> rather than the google groups monstrosity. People have different
 
> opinions on the best choices, but Thunderbird along with
 
> news.eternal-september.org is a popular and free choice.
 
How about now?
Robert Hutchings <rm.hutchings@gmail.com>: Sep 21 10:17AM -0700

On Sunday, September 21, 2014 11:26:12 AM UTC-5, David Brown wrote:
 
> rather than the google groups monstrosity. People have different
> opinions on the best choices, but Thunderbird along with
> news.eternal-september.org is a popular and free choice.
 
OK, I will check out Thunderbird. Thank you.
David Brown <david.brown@hesbynett.no>: Sep 21 11:26PM +0200

On 21/09/14 19:17, Robert Hutchings wrote:
>> opinions on the best choices, but Thunderbird along with
>> news.eternal-september.org is a popular and free choice.
 
> OK, I will check out Thunderbird. Thank you.
 
I don't know what sort of copy-and-paste job you did on the other post,
but you got the attributions right on this one. (We are not telling you
this to be annoying or pedantic - it really is easier to follow posts
when the quoting and attributions are correct, and people use
bottom-posting or inline answers. So when your post follow the
standard, more people read them and respond to them.)
 
I hope you get to like Thunderbird. I don't know what OS you are using
- there are many other newsreaders available for most systems. But
Thunderbird is a pretty good start - it's easy to use, follows most of
the rules by default, and makes a fine email client as well. So it is a
solid choice to start with, and then in the future you can look at
alternatives once you are familiar with newsreader basics. (Or, as I
do, you can just stick with Thunderbird ever after.)
 
You also need a newsserver. It used to be the case that most ISP's
provided a free access newsserver for their customers, but that seems to
be rare now. news.eternal-september.org provides free access to anyone,
but you have to register with a valid email (some people don't like
that). Again, it's a fine choice to start with - people with unusual
requirements might look elsewhere.
"Öö Tiib" <ootiib@hot.ee>: Sep 21 06:00AM -0700

On Friday, 19 September 2014 11:25:28 UTC+3, Paavo Helde wrote:
 
> Unfortunately, sizeof 1/8 is not representable in size_t.
 
> Thus, the C++ standards group should have invented a special std::bitvector
> instead.
 
Yes. The controversial situation with 'vector<bool>' lost good opportunity
to make a clear distinction between bit-packed and not bit-packed
containers in standard library.
 
For bits there is 'boost::dynamic_bitset'; that is fine enough for
bools too.
 
On the other hand bit-packing may be sometimes beneficial with other
types as well. Typically there are integers or enums that have often
short range of meaningful values or some class types whose possible
states may be representable with only few bits. It seems more likely
that we have something like that in big numbers and not bools.
Mr Flibble <flibble@i42.co.uk>: Sep 21 07:39PM +0100

On 21/09/2014 14:00, Öö Tiib wrote:
 
> Yes. The controversial situation with 'vector<bool>' lost good opportunity
> to make a clear distinction between bit-packed and not bit-packed
> containers in standard library.
 
It is hard making sasuage fit into vector if sausage is uncooked; cooked
sausage has less problems.
Juha Nieminen <nospam@thanks.invalid>: Sep 21 11:14AM

> wantedRecs = (1ul<<1) | (1ul<<2) | (1ul<<3) | (1ul<<8);
 
How about simply: wantedRecs = 0b100001110;
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Paavo Helde <myfirstname@osa.pri.ee>: Sep 21 09:49AM -0500

Juha Nieminen <nospam@thanks.invalid> wrote in news:lvmbub$vue$1
 
> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>> wantedRecs = (1ul<<1) | (1ul<<2) | (1ul<<3) | (1ul<<8);
 
> How about simply: wantedRecs = 0b100001110;
 
Yes, that's how it should work in an ideal world. However, the binary
literals appear in the C++14 standard, which is just about to be released.
So it will probably take some years before all major C++ vendors have
upgraded their compilers to support them.
 
Cheers
Paavo
Norbert_Paul <norbertpauls_spambin@yahoo.com>: Sep 21 05:12PM +0200

Paavo Helde wrote:
> literals appear in the C++14 standard, which is just about to be released.
> So it will probably take some years before all major C++ vendors have
> upgraded their compilers to support them.
 
Then how about something like
#define PMBINARY(i) ((i % 10 ? 1ul : 0ul) | ((i/10) % 10 ? 2ul : 0ul) | ((i/100) % 10 ? 4ul : 0ul) | ...etc... )
?
Wouldn't then
PMBINARY(101)
give 5?
 
> Cheers
> Paavo
 
Cheers
Norbert
 
Note. "PM" stands for "Poor man's".
Paavo Helde <myfirstname@osa.pri.ee>: Sep 21 12:45PM -0500

Norbert_Paul <norbertpauls_spambin@yahoo.com> wrote in
> Wouldn't then
> PMBINARY(101)
> give 5?
 
To be honest, this solution looks worse than the problem. It does not
scale up over 9 or 19 bits. It uses a convoluted convention and performs
unneeded calculations. And why is it a macro?
 
Actually, none of the solutions so far have addressed the main problem in
the OP's code: usage of magic constants. In the real code it should look
something like this instead:
 
enum FooBarFlag {
featureFoo = (1ul<<1),
featureBar = (1ul<<2),
adjustBaz = (1ul<<3),
// ...
featureQux = (1ul<<8),
// ...
};
 
FooBarFlag operator|(FooBarFlag a, FooBarFlag b);
 
// ...
 
wantedRecs |= (featureFoo | featureBar | adjustBaz | featureQux);
 
Cheers
Paavo
AP <udtelco@gmail.com>: Sep 20 07:50PM -0700

When should one consider implementing a an explicit move ctor (such as Class::Class(const Class&&) ) ?
Thank you in advance !
Ian Collins <ian-news@hotmail.com>: Sep 21 05:19PM +1200

AP wrote:
> When should one consider implementing a an explicit move ctor (such
> as Class::Class(const Class&&) ) ? Thank you in advance !
 
Without the const... When the const of copying the class makes a move
constructor worth while.
 
--
Ian Collins
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Sep 21 09:39AM +0100

On Sat, 20 Sep 2014 19:50:45 -0700 (PDT)
> When should one consider implementing a an explicit move ctor (such
> as Class::Class(const Class&&) ) ? Thank you in advance !
 
That is not a move constructor. It is a copy constructor for immutable
rvalues. I cannot think of any case where one would want to consider
implementing one of those.
 
You would consider implementing a move constructor where there is an
efficiency advantage to be obtained by moving the internals of a mutable
rvalue (such as a temporary) instead of copying it.
 
Chris
"Öö Tiib" <ootiib@hot.ee>: Sep 21 08:56AM -0700

On Sunday, 21 September 2014 05:50:58 UTC+3, AP wrote:
> When should one consider implementing a an explicit move ctor (such as Class::Class(const Class&&) ) ?
 
> Thank you in advance !
 
This article
http://flamingdangerzone.com/cxx11/2012/08/15/rule-of-zero.html
elaborates some things about those special functions
quite nicely.
"AP(unixpronospam@verizon.net)" <udtelco@gmail.com>: Sep 20 07:07PM -0700

In item 13 (Lazy optimization / copy-on-write) we see following ctor :
 
String::String( const String& other ): buf_(new char[other.len_]),
len_(other.len_), used_(other.used_)
{ copy(other.buf_, other.buf_+used_, buf_); }
 
Class is defined thus :
class String
{
public:
String(const String&);
...
private:
char* buf_;
size_t len_;
size_t used_;
...
}
 
Question : how does our ctor have access to her argument's private data ?
The situation repeats on quite a few occasions in the book,
 
In fact, such behavior is observed :
 
class CC
{
public:
CC(){}
CC(size_t A) : DATA(A) { cerr << "Straight ctor(" << A << ")" << endl; }
CC(const CC& cc) : DATA(cc.DATA) { cerr << "Copy ctor" << endl; }
void Copy(CC& cc) { DATA = cc.DATA; }
void CopyTo(CC& cc) { cc.DATA = DATA; }
size_t Extract(CC& cc) { DATA = cc.DATA; return DATA;}
private:
size_t DATA;
};
 
int main(int argc,char **argv, char **envp)
{
CC cc(1), dd(2), ee(cc);
cerr << ee.Extract(cc);
// Does not compute :
cerr << ee.DATA << endl;
}
 
The last line, of course, doesn't compile. The rest does so. Why am I able
to access explicitly private DATA member of my argument cc in methods Copy
and CopyTo, as well as the rest of the class ?
Ian Collins <ian-news@hotmail.com>: Sep 21 02:28PM +1200

> }
 
> Question : how does our ctor have access to her argument's private data ?
> The situation repeats on quite a few occasions in the book,
 
Because both are objects of type String. That's how access protection
works in C++. If it were any other way, objects with private data
members couldn't be coped without a public accessor for each private member.
 
--
Ian Collins
Paavo Helde <myfirstname@osa.pri.ee>: Sep 21 02:45AM -0500

"AP(unixpronospam@verizon.net)" <udtelco@gmail.com> wrote in
 
> Question : how does our ctor have access to her argument's private
> data ?
 
The purpose of protection in C++ is to enforce clean encapsulation and
limit the amount of code one needs to review and adjust when making changes
in the private pieces. This means that of course the copy constructors (as
well as all other member functions) have access to the private data of the
same class, regardless of which object it belongs to.
 
With 'protected' keyword this becomes a bit more complicated (but having
'protected' data members is dicouraged anyway).
 
Cheers
Paavo
Juha Nieminen <nospam@thanks.invalid>: Sep 21 11:16AM

> Question : how does our ctor have access to her argument's private data ?
 
Why exactly shouldn't a String function have access to the members of
its own type?
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)