Wednesday, July 18, 2018

Digest for comp.lang.c++@googlegroups.com - 18 updates in 10 topics

Daniel <danielaparker@gmail.com>: Jul 18 09:57AM -0700

Consider
 
class A
{
int32_t value1_;
int64_t value2_;
public:
A() : value1_(10), value2_(20) {}
 
explicit operator int32_t() const
{
return value1_;
}
 
explicit operator int64_t() const
{
return value2_;
}
}
 
such that we can write
 
int main()
{
A a;
 
std::cout << (int32_t)a << ", " << (int64_t)a << std::endl;
}
 
and get the expected output
 
10, 20
 
The important feature in the problem statement is that a cast to an integer
of size sizeof(int32_t) gets a value one way, and a cast to an integer of
size sizeof(int64_t) gets it another way.
 
Now suppose we want to have this work for all integer types in a platform
independent way, e.g. we want
 
std::cout << (int)a << ", " << (long)a << ", " << (long long)a << std::endl;
 
to return 10 or 20 depending on the size of the integer, or not compile if
the integer type is not 32 or 64 bits.
 
I'm having some difficulty solving this with SFINAE. Any suggestions?
 
Thanks,
Daniel
Paavo Helde <myfirstname@osa.pri.ee>: Jul 18 08:49PM +0300

On 18.07.2018 19:57, Daniel wrote:
 
> to return 10 or 20 depending on the size of the integer, or not compile if
> the integer type is not 32 or 64 bits.
 
> I'm having some difficulty solving this with SFINAE. Any suggestions?
 
Something like this?
 
#include <iostream>
 
class A
{
int32_t value1_;
int64_t value2_;
private:
template<int sz> struct traits { using type = void; };
template<> struct traits<4> { using type = int32_t; };
template<> struct traits<8> { using type = int64_t; };
 
template<int sz> typename traits<sz>::type Get() const;
template<> traits<4>::type Get<4>() const { return value1_; }
template<> traits<8>::type Get<8>() const { return value2_; }
 
public:
A() : value1_(10), value2_(20) {}
 
template<typename T>
explicit operator T() const
{
return Get<sizeof(T)>();
}
};
 
int main()
{
A a;
 
std::cout << (int32_t)a << ", " << (int64_t)a << std::endl;
}
Daniel <danielaparker@gmail.com>: Jul 18 04:19PM -0700

On Wednesday, July 18, 2018 at 1:49:41 PM UTC-4, Paavo Helde wrote:
 
> A a;
 
> std::cout << (int32_t)a << ", " << (int64_t)a << std::endl;
> }
 
Thanks!
Daniel
Tim Rentsch <txr@alumni.caltech.edu>: Jul 18 11:46AM -0700

> manipulation of objects in C++ at all. All member functions get an
> implicit 'this' "pointer", and all member variables are accessed
> through it.
 
You think that's nitpicking? Is your understanding that shallow?
 
The difference is essential because passing an object by value
throws away dynamic type information. Any object passed by value
has a dynamic type that is the same as its static type. Virtual
function calls are dynamic only when the dynamic type is (at
least potentially) different than the static type. Passing an
object by pointer/reference is necessary for dynamic dispatch
of virtual functions actually to be dynamic rather than static.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jul 18 10:09PM +0100

On 18/07/2018 19:46, Tim Rentsch wrote:
> least potentially) different than the static type. Passing an
> object by pointer/reference is necessary for dynamic dispatch
> of virtual functions actually to be dynamic rather than static.
 
What you are saying is only applicable if slicing occurs otherwise it is
perfectly fine to pass objects by value albeit accepting that copies are
being made.
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."
ram@zedat.fu-berlin.de (Stefan Ram): Jul 18 08:52PM

>the notion about 'leaking resources' in particular memory,
>i'd think would sound foreign to say a java or c# programmer
 
You open a connection to a database in Java. Ok, you can't
even spell "Java". So, say, a Java programmer opens a
connection to a database. At a certaint point, he does not
need it anymore, but he does not close it. What do you call
this if not a "resource leak"?
 
(You even can leak /memory/ by adding it to a stack and then
setting the stack pointer to the start without clearing
the references in the stack.)
 
>in java, you simply do a
>MyClass myobject = new MyClass();
 
How is that simpler than
 
My_class my_object;
 
?
 
>and you literally *forget* about it (yup that's leaked), when
>it goes out of scope say that it is allocated on the stack,
>garbage collection takes care of cleaning that up
 
GC does not clean up when »myobject« goes out of scope,
but it /might/ clean up the object created when it is not
reachable by the programs code anymore, which might be
way before or way after »myobject« goes out of scope.
 
(Not read on.)
Andrew Goh <andrewgoh0@gmail.com>: Jul 18 01:21PM -0700

hi all,
i tend to agree with Paavo Helde point of view about smart pointers and all
the notion about 'leaking resources' in particular memory, i'd think would sound foreign to say a java or c# programmer
 
in java, you simply do a
MyClass myobject = new MyClass();
 
and you literally *forget* about it (yup that's leaked), when it goes out of scope say that it is allocated on the stack, garbage collection takes care of cleaning that up
 
but i had to say these things are 'difficult' in c++ not because it isn't possible to do GC in C++. but more because
 
1) c++ allows raw pointers to be used, if you look at the above statement from java that isn't a pointer, it is simply a reference, and the underlying memory manager takes care of cleaning those up
 
Bjarne Stroustrup basically mentioned some of the issues when raw pointers is used along with garbage collection
http://www.stroustrup.com/C++11FAQ.html#gc-abi
the use of raw pointers may lead to ambiguous situations where it may not be possible for gc to tell if a particular object is after all still 'in use'
 
the cool thing is that 'smart' pointers is invented in place of raw pointers
and 'smart' pointers are basically *references* - not real pointers
but referenced counted smart pointers couldn't resolve circular references (i.e. loops) without GC
 
there is also this article about Boost shared_ptr being '10 times slower than other means e.g. raw pointers', i'm not sure if this is still true today
http://flyingfrogblog.blogspot.com/2011/01/boosts-sharedptr-up-to-10-slower-than.html
 
ideally i'd prefer to have implementations amounting to 'a smarter smart pointers', i.e. the smart pointers are literally used as a full blown garbage collection implementation rather than simply reference counting scheme
 
today's desktop cpus and various mobile arm based cpus are moving towards a trend of multi cores and in addition vector computing is becoming increasingly common e.g. AVX2, AVX512 coming next to all new X86_64 platforms. given this it would be better to see memory management as a 'process' rather than the 'single threaded' simplistic view of clean up as you go model.
 
the simplistic view is very 'single threaded' (i.e. clean up as you go) and that adds to the total elapsed time as you could imagine the extreme case of a multi-core cpu where all the other cores are simply idle while that single thread is busy doing all that 'clean up as you go'.
i'm literally ok with 'stop the world' which would introduce stalls so that all that 'garbage collection' can do all that 'mark and sweep' and even compacting memory management. the end result is often a big reduction of total elapsed time which translate to a faster / more productive program execution (sometimes significantly faster)
 
however, i do agree with bitrex about that raw pointers are sometimes still a necessary evil. i've meddled on arduino embedded programming and on the mcu's sometimes 20k (note not 2 megs or 2 gig) it is just 20k ram is all you have.
i still use c++ to keep codes organised, but then memory management becomes totally 'manual' - clean up as you go. here, it is not application efficiency, it is *memory efficiency* and *real time-ness* that matters more
 
2) the other reason it is *hard* to do GC in C++ as GC is not *insisted* upon in C++, not mandated in the spec, and the language is not based on garbage collection (e.g. like java, c#, which without GC those languages simply fail)
 
but this throws open the different means of memory management including smart pointers (e.g. shared_ptr), garbage collection e.g. boehm GC etc
and the *garbage collection / memory management* process is *very hard* on large complex apps. there are many *buggy* implementations of GC and memory management as memory management / garbage collection is now simply an 'add-on' to c++ rather than mandated
jacobnavia <jacob@jacob.remcomp.fr>: Jul 18 07:14PM +0200

Le 17/07/2018 à 19:47, Richard a écrit :
> This is like the 40th time
> that someone has complained about C++ and introduced a new language to
> "solve" the problems that C++ has.
 
Most people do not develop a new language but use a subset of C++. For
instance NASA, in its Curiosity rover software has used following C++
subset:
(https://github.com/CppCon/CppCon2014/blob/master/Presentations/C%2B%2B%20on%20Mars%20-%20Incorporating%20C%2B%2B%20into%20Mars%20Rover%20Flight%20Software/C%2B%2B%20On%20Mars%20-%20Mark%20Maimone%20-%20CppCon%202014.pdf)
<quote>
So we limited our code to "Embedded C++" constructs
Exceptions: none
Templates: none
Iostream: none
Multiple inheritance: none
Operator overloading: almost none (only "new" and
"delete").
Dynamic Allocation: Guarantee no system heap corruption
using a dedicated memory pool and Placement New
<end quote>
legalize+jeeves@mail.xmission.com (Richard): Jul 18 08:21PM

[Please do not mail me a copy of your followup]
 
>On 18/07/18 06:16, Scott Lurndal wrote:
 
>> We have many linux programmers internally, and aside from a couple
>> of interns who used eclipse, everyone else uses vim or emacs.
 
I'm always amazed at the number of C/C++ developers that haven't
upgraded their development environment in 30+ years. By this point, I
would have expected that all the emacs afficionados would have
automated refactoring implemented in elisp, but nope. They have
essentially the same environment I had in 1988.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
jacobnavia <jacob@jacob.remcomp.fr>: Jul 18 09:54PM +0200

Le 18/07/2018 à 11:16, Ian Collins a écrit :
 
> Old clang?
 
Exactly. That was the problem. Thanks Ian.
jacob
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jul 18 06:47PM +0100

On 18/07/2018 08:53, Juha Nieminen wrote:
 
> The advantage of using std::list is that the code becomes simpler,
> and thus the likelihood of bugs is smaller.
 
> Know your tools, and use them efficiently.
 
You can use a custom (pool) allocator with std::list to improve cache
locality and/or reduce number of freestore allocations and this is in fact
exactly what I do in neoGFX's "sprite_plane" class for storing sprites
such as projectiles and doing collision detection and managing sprite death.
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."
Tim Rentsch <txr@alumni.caltech.edu>: Jul 18 11:49AM -0700

>> practice arrays/vectors nearly always do better.
 
> That's completely true, but in this case it may be a micro-optimization,
> even premature optimization, with little to no benefit.
 
The (snipped) suggestion is to consider, and possibly investigate,
an alternate approach. Considering and possibly investigating is
not optimization, either micro-, premature, or otherwise.
 
 
> The advantage of using std::list is that the code becomes simpler,
> and thus the likelihood of bugs is smaller.
 
> Know your tools, and use them efficiently.
 
I don't want to be rude, but you are taking a lecturing tone
with people whose understandings are deeper than your own.
Tim Rentsch <txr@alumni.caltech.edu>: Jul 18 11:16AM -0700

> easily becomes a mess...
 
> I know it's a matter of personal preference (or rules agreed by the team),
> but I'm curious what your preference is, and why.
 
I don't have any hard-and-fast rule. Generally, though, I find
that indenting nested constructs becomes counterproductive when
what is being nested exceeds some length. I don't know what
that length is exactly but for concreteness let me call it 100
lines. Below threshold, especially when what is being nested
fits on a single 50- or 60- line page, indenting is okay. Above
threshold, indenting hurts more than it helps, and it's better
just not to indent at all.
 
Related comment: any nesting construction where what is being
nested exceeds some relatively small amount (50 lines, say)
deserves a comment on its end marker indicating what is being
closed. I recommend this practice whether or not the nested
portion is indented.
Tim Rentsch <txr@alumni.caltech.edu>: Jul 18 10:55AM -0700

>> the requirements.
 
> Maybe we should say in many cases, the TDD tests are the only form
> of requirements...
 
This statement confuses several significantly distinct notions,
which in turn confuses the issue.
 
The /requirements/ of a desired program are all those things
that need to be true in order for the program to be useful in
accomplishing its intended purpose. These things may be called
the actual or true requirements.
 
A /statement of requirements/ is what results from an effort to
capture those things in a verbal (usually written) form. A key
difference is that we know what is included in a statement of
requirements, but often don't know what is included in the
actual requirements, because customers often aren't sure or
don't understand what is really needed.
 
An effort to establish that a statement of requirements matches
the actual requirements is called validation (in particular, in
the software world it is called software validation). An effort
to establish that a program's behavior matches its statement of
requirements is called software verification. Informally, the
phrases "build the right thing" and "build the thing right" are
sometimes used for validation and verification, respectively.
 
A set of tests written (under any methodology) to help establish
program behavior, under certain circumstances, generally falls
into the category of verification. Some of those tests -- in
particular, those that check end-to-end externally visible
program behavior -- might correspond to parts of a statement of
requirements. In contrast, internal tests might be useful in
helping verify a program's behavior, but they never belong in a
statement of requirements, because the customer doesn't care
about how a program operates internally (or if they do, it means
those predicates are not really internal conditions).
 
Of course, a customer might agree, whether explicitly or not,
that passing some set of tests (perhaps in addition to some
other criteria) means the program is satisfactory as far as they
are concerned. Any set of tests might be part of an acceptance
measure. But being part of an acceptance measure doesn't mean a
specific tested condition belongs in a statement of requirements
necessarily. Moreover, even if a particular condition is agreed
to be part of a statement of requirements, that doesn't change
the actual requirements, which are not affected (even if not
always knowable) by what the statement of requirements says.
Bottom line, if after delivery a program never gets used to
accomplish what the customer wanted to accomplish with it, the
program has not met its requirements. It may be that it has met
its contractual obligations, but that doesn't guarantee that it
has met its actual requirements.
woodbrian77@gmail.com: Jul 18 10:03AM -0700

On Wednesday, July 18, 2018 at 10:58:54 AM UTC-5, Paavo Helde wrote:
> > the "landing pads" and tables state->landing pads.
 
> Yes, it trades some disk space for speed, but the size of executables
> does not interest most people nowadays (except some nutwits in this group).
 
Caring about the size of your executables pays off in
terms of runtimes and build times. This talk by Mark
Zeren at Cppnow is a little vindication for the nutwits.
 
https://duckduckgo.com/?q=cppnow+matters&t=h_&ia=videos&iax=videos&iai=vGV5u1nxqd8
 
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
scott@slp53.sl.home (Scott Lurndal): Jul 18 05:06PM

>> does not interest most people nowadays (except some nutwits in this group).
 
>Caring about the size of your executables pays off in
>terms of runtimes and build times.
 
Nonsense.
 
> This talk by Mark
>Zeren at Cppnow is a little vindication for the nutwits.
 
Who is Mark Zeren, and why should I care?
 
 
>https://duckduckgo.com/?q=cppnow+matters&t=h_&ia=videos&iax=videos&iai=vGV5u1nxqd8
 
Sorry, can't do videos and don't do duckduckgo. Post the actual link
to words instead of the search terms.
jameskuyper@alumni.caltech.edu: Jul 18 10:13AM -0700


> >Implicit int was removed in the first C++ standard, in 1998, with the
> >following rationale:
 
> See above.
 
It was removed from the second version of the C standard, in 1999, so that doesn't make much difference.
woodbrian77@gmail.com: Jul 18 10:26AM -0700

On Wednesday, July 18, 2018 at 12:07:04 PM UTC-5, Scott Lurndal wrote:
 
> > This talk by Mark
> >Zeren at Cppnow is a little vindication for the nutwits.
 
> Who is Mark Zeren, and why should I care?
 
He's a developer at VMware:
https://www.linkedin.com/in/markzeren/
 
His talk at 2018 C++Now was titled "-Os matters".
 
 
> >https://duckduckgo.com/?q=cppnow+matters&t=h_&ia=videos&iax=videos&iai=vGV5u1nxqd8
 
> Sorry, can't do videos and don't do duckduckgo. Post the actual link
> to words instead of the search terms.
 
Here's the overview of the talk:

At VMware we include binary size deltas in code reviews
for large, C++, user-space, applications. You might be
thinking "that's the most pointy haired thing I've every
heard of!". Come to this talk and learn how this simple
metric provides surprisingly strong counter pressure to complexity.
 
 
Brian
Ebenezer Enterprises
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)