Saturday, June 27, 2015

Digest for comp.lang.c++@googlegroups.com - 6 updates in 3 topics

alf.p.steinbach@gmail.com: Jun 27 04:13PM -0700

On Saturday, June 27, 2015 at 11:39:02 PM UTC+2, Marcel Mueller wrote:
> functions too. So as soon as you have at least one virtual function it
> makes no difference in size anymore. And, well, it is quite likely to
> have virtual functions when you need virtual inheritance.
 
It would be easy to check such an assumption before posting, especially since I posted code that you could trivially amend for the purpose, e.g. just add
 
virtual ~A() {}
 
in class A, then compile and run.
 
I'm a big fan of checking reality. ;-)
 
Explanation why the vtable is (sually not used to store the offsets:
 
The vtable (AFAIK all extant C++ compilers use vtables) for a class is a single set of function pointers for the class, shared by all instances of that class. In contrast an offset adjustment for a virtual base sub-object is needed per object, although with a very limited number of possible values. Due to the limited number of possible values it is in principle possible to represent it via the vtable pointer, which might point to corresponding offset in a shared vtable, or to corresponding copies of a vtable. But that's neither very practical nor very efficient. The practical and not unduly inefficient way to do things is to store the offset directly in each object.
 

> Of course, none of the assumptions about sizeof are part of the
> standard. They are only typical for common implementations.
 
In a formal view that's right, but in practice we do have vtables and per instance vtable pointers(not the only possible implementation of runtime polymorphism) and in practice we do have per instance virtual base class sub-object offset (again, not the only possible implementation). I don't know of any extant compiler that isn't that way. Admittedly, nowaydays I don't know about a great many compilers, but it would be truly remarkable if such a spirit-of-PHP-like C++ compiler had been /introduced/ since way back then.
 
Cheers & hth.,
 
- Alf
"Öö Tiib" <ootiib@hot.ee>: Jun 27 03:12PM -0700

> aa is 123%6
> The len of bb is 7
 
> I don't know what's happening with aa.
 
Richard Damon's example seemed to contain undefined behavior with 'bb'.
The \045 must be parsed as octal escape sequence by language rules.
http://en.cppreference.com/w/cpp/language/escape
 
Why you didn't attempt to cout the contents of 'bb'?
 
> Anyway, does anyone use that constructor?
 
How can we know? We have no access to all code-bases of world and
even if we had it the usage of constructors is rather painful to
track.
 
In my own code bases I sometimes move constructor to private or
erase it to get compiler errors at places of usage but I never
used that trick to check usage of features of standard library.
Richard Damon <Richard@Damon-Family.org>: Jun 27 06:32PM -0400

On 6/27/15 6:12 PM, Öö Tiib wrote:
 
> Richard Damon's example seemed to contain undefined behavior with 'bb'.
> The \045 must be parsed as octal escape sequence by language rules.
> http://en.cppreference.com/w/cpp/language/escape
 
Yep, I forgot about the octal escape sequence. Should have used the
string "ABC\0DEF"
 
> Why you didn't attempt to cout the contents of 'bb'?
 
>> Anyway, does anyone use that constructor?
 
The use is in building strings from structures of fixed length, non-null
terminated character arrays, like might be found in a definition of a
file directory structure, back in the days of 8.3 file names.
woodbrian77@gmail.com: Jun 27 03:32PM -0700

On Saturday, June 27, 2015 at 5:12:37 PM UTC-5, Öö Tiib wrote:
> The \045 must be parsed as octal escape sequence by language rules.
> http://en.cppreference.com/w/cpp/language/escape
 
> Why you didn't attempt to cout the contents of 'bb'?
 
Lazy.
 
 
> How can we know? We have no access to all code-bases of world and
> even if we had it the usage of constructors is rather painful to
> track.
 
I don't think that's a very popular constructor, but I know
there are probably a few uses out there.
jt@toerring.de (Jens Thoms Toerring): Jun 27 10:05PM

> > former.
 
> Because use of the typedef means you are explicitly documenting in code
> that the size of this type can vary and should be treated as such.
 
That's a wrong expectation. For people that do know that 'int'
has a rather limited range it's just visual noise. And those
that don't know will just be puzzled what this 'magical incan-
tation' is supposed to mean and move on, not any more educated
than before.
 
This isn't a problem that can be solved by some coding conven-
tion (that most won't even understand what it's all about). All
that this will achieve is that a few adopt it in a cargo-cult
programming way, i.e. using 'int_fast16_t' instead of 'int' be-
cause it looks "cool" - but they will still use it to store
too large values - which, in nearly all cases, is going to work
perfectly well on their systems. Without real hard, non-off-
switchable compiler and runtime range checking you can't
stop that kind of behaviour.
 
Just because you know what the '16' in 'int_fast16_t' means in
no way guarantees that others also do. For those that don't it's
not any more "explicitly documenting" than a mere 'int'. I've
seen too many people, including some that had worked for "im-
portant companies" in Silicon Valley, that had no idea at all
of any portability issues - they had never even heard of the
existence of architecures with other ranges for ints, endia-
nnesses or, God beware, chars with more than 8 bits or
alignment issues etc. (admittedly, they mostly came from a
Java background, so they had been living in a "padded cell"
where they couldn't hurt themselves too much;-).
 
<cstdint> is an extremely useful addition when you need types
of guaranteed sizes, especially when doing low level stuff,
but it's not a silver bullet to eradicate unawareness of por-
tability issues. For that people have to become aware of the
mere existence of such problems first. Only then the stuff
from <cstdint> becomes meaningful. Just making them write
 
#include <cstdint>
...
for ( int_fast16_t i = 0; i < 5; ++i )
{...}
 
instead of, more simply,
 
for ( int i = 0; i < 5; ++i )
{...}
 
won't fix any such problems because they'll also do
 
#include <cstdint>
...
for ( int_fast16_t i = 99990; i < 100000; ++i )
{...}
 
and get away with it...
 
On the other hand, making unsubstantiated claims that the
use of 'int' would be inherently "unsafe" or "non-portable"
makes you look a bit "strange" to those that have used
'int' safely and in a portable manner for a quarter of
a century.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
woodbrian77@gmail.com: Jun 27 03:21PM -0700

On Saturday, June 27, 2015 at 4:17:38 PM UTC-5, Öö Tiib wrote:
> things are text these days like (JSON, XML or CSV). It is narrow
> fraction of works where we want to squeeze last out and pick a binary
> format.
 
There are a lot of games that use binary formats. Scientific
and medical applications often use binary formats. Also I
posted an article here a few weeks ago about bandwidth hitting
a wall. This isn't it, but it's related:
 
https://royalsociety.org/events/2015/05/communication-networks/
 
 
Brian
Ebenezer Enterprises - So far G-d has helped us.
http://webEbenezer.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)