Monday, May 25, 2015

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

Juha Nieminen <nospam@thanks.invalid>: May 25 09:30AM

> Google's coding standard has a do not indent namespaces rule and most
> editors I've seen can be configured to follow that rule.
 
Google can eat my shorts.
 
{} is a block, and its contents are indented.
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
woodbrian77@gmail.com: May 25 01:37PM -0700

On Monday, May 25, 2015 at 4:30:25 AM UTC-5, Juha Nieminen wrote:
> > editors I've seen can be configured to follow that rule.
 
> Google can eat my shorts.
 
> {} is a block, and its contents are indented.
 
I prefer https://duckduckgo.com to Google.
 
But I don't indent namespaces either. I'm big on
indentation in general, but in this case don't seem
to miss it.
 
Brian
Ebenezer Enterprises - "For a righteous man falls seven
times, and rises again, but the wicked stumble in time
of calamity." Proverbs 24:16
 
http://webEbenezer.net
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: May 25 06:30PM +0100

On Sun, 24 May 2015 10:36:41 -0700 (PDT)
> > > in advance.
 
> > The warning is quite valid: you are indeed using an uninitialised
 
> Is taking/storing the address of an uninitialized variable wrong?
 
It is not just that the array is uninitialized, but that it doesn't
exist at all, and you cannot take the address of a non-existent
object. It doesn't exist because the constructor of SendBuffer is
called before any of the members of its sub-class (SendBufferStack) are
constructed. You could lawfully do an assignment (not initialization)
in the body of SendBufferStack's constructor if SendBuffer's member
being assigned to is protected or has a protected accessor, but more
likely you want to consider templating the base class or using a
virtual function.
 
Of course, as Flibble has pointed out, you are not just taking the
array's address, but you are applying operator[] to the non-existent
array in order to take the address of its first (but also non-existent)
member. So you have doubly undefined behaviour.
 
Possibly your unnecessary use of the initial scoping operator in
declaring 'ar' is adding to the cognitive load when your read your code.
If you write your code more conventionally without such superfluous
nonsense you would find it easier to see errors like this.
 
Chris
woodbrian77@gmail.com: May 25 11:20AM -0700

On Monday, May 25, 2015 at 12:31:08 PM UTC-5, Chris Vine wrote:
> being assigned to is protected or has a protected accessor, but more
> likely you want to consider templating the base class or using a
> virtual function.
 
If I change it like this:
 
template <unsigned long N = udp_packet_max>
class SendBufferStack : public SendBuffer
{
char ar[N];
 
public:
SendBufferStack () : SendBuffer(ar, N) {}
};
 
Clang and Gcc are fine with it.
 
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: May 25 07:36PM +0100

On Mon, 25 May 2015 11:20:10 -0700 (PDT)
woodbrian77@gmail.com wrote:
[snip]
> SendBufferStack () : SendBuffer(ar, N) {}
> };
 
> Clang and Gcc are fine with it.
 
If they still refuse to listen, tell it to the church; and if they
refuse to listen even to the church, treat them as you would a pagan or
a tax collector: [Matthew 18:17]
 
Chris
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: May 25 07:47PM +0100

On Mon, 25 May 2015 19:36:37 +0100
 
> If they still refuse to listen, tell it to the church; and if they
> refuse to listen even to the church, treat them as you would a pagan
> or a tax collector: [Matthew 18:17]
 
It now occurs to me that you may not just be being deliberately
awkward for the fun of it, but that you don't understand the basics.
Referring to 'ar' takes its address by pointer decay. So whether you
are to be treated as a pagan or a tax collector I leave to you.
"Öö Tiib" <ootiib@hot.ee>: May 25 06:36AM -0700


> https://fgiesen.wordpress.com/2014/10/25/little-endian-vs-big-endian/
 
> As far as I can tell using big-endian for network order was
> an arbitrary choice.
 
Picking big-endian for network order was possibly arbitrary decision
but that does not mean that usage of big-endian in architectures of
some systems is arbitrary decision. Besides ... you can get ten
different answers to any question from random blogs in internet.
David Brown <david.brown@hesbynett.no>: May 25 04:30PM +0200

On 25/05/15 15:36, 嘱 Tiib wrote:
> but that does not mean that usage of big-endian in architectures of
> some systems is arbitrary decision. Besides ... you can get ten
> different answers to any question from random blogs in internet.
 
There are a few good technical reasons for preferring one format over
the other in architecture design. Big-endian is apparently easier to
implement efficiently in hardware, especially for wider paths - hence
its popularity in many RISC designs. Little-endian is convenient for
arithmetic with multi-byte values, hence its popularity with 8-bit
designs or those that can trace their ancestry back to 8-bit designs.
 
The most common reason for choosing one format over the other is, of
course, consistency with some particular previous system.
Ben Bacarisse <ben.usenet@bsb.me.uk>: May 25 05:23PM +0100


> On Sunday, 24 May 2015 22:16:01 UTC+3, woodb...@gmail.com wrote:
<snip>
> but that does not mean that usage of big-endian in architectures of
> some systems is arbitrary decision. Besides ... you can get ten
> different answers to any question from random blogs in internet.
 
To give one just one (with no more authoritative backing than the fact
that I've been around long enough to confirm that the idea is an old
one), it was said that you could route packets faster if the high-order
bits of address came down the line first, since that's often the only
part you need to determine the route.
 
--
Ben.
Juha Nieminen <nospam@thanks.invalid>: May 25 04:30PM

> the other in architecture design. Big-endian is apparently easier to
> implement efficiently in hardware, especially for wider paths - hence
> its popularity in many RISC designs.
 
In a big-endian system string comparisons can be made more efficient
because you can directly compare strings as if they were unsigned long
arrays (assuming enough padding at the end of the string).
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Juha Nieminen <nospam@thanks.invalid>: May 25 09:32AM


> I wonder what book out there exists that uses the term "class variable"
> as opposed to "member variable" to refer to *static data members* in
> comparison to *non-static data members*...
 
"Class variable" is common terminology (and is exactly what 'static' does
when specified for a variable inside a class).
 
http://en.wikipedia.org/wiki/Class_variable
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
bleachbot <bleachbot@httrack.com>: May 23 04:00PM +0200

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)