Thursday, February 2, 2017

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

"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 02 07:19PM +0100

On 02.02.2017 18:49, Bonita Montero wrote:
> Can anyone explain me what the "owner-concept" or "GSL" of C++17 is?
 
Thanks for those pointers.
 
I can't find anything about it but I did find
 
<url: http://honermann.net/blog/?p=3>
"Why Concepts didn't make C++17"
 
dated 6th of March 2016.
 
Has the committee turned again on this, or are perhaps the things you
refer to part of Eric Niebler's ranges proposal?
 
 
Cheers!,
 
- Alf
legalize+jeeves@mail.xmission.com (Richard): Feb 02 08:57PM

[Please do not mail me a copy of your followup]
 
Bonita Montero <Bonita.Montero@gmail.com> spake the secret code
 
>Can anyone explain me what the "owner-concept" or "GSL" of C++17 is?
 
Are you talking about the Guideline Support Library?
<https://github.com/Microsoft/GSL>
 
...and how it relates to who owns the memory addressed by a pointer?
 
<https://github.com/isocpp/CppCoreGuidelines>
<https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#i11-never-transfer-ownership-by-a-raw-pointer-t>
--
"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>
Bo Persson <bop@gmb.dk>: Feb 02 11:08PM +0100

On 2017-02-02 19:19, Alf P. Steinbach wrote:
 
> dated 6th of March 2016.
 
> Has the committee turned again on this, or are perhaps the things you
> refer to part of Eric Niebler's ranges proposal?
 
No recent changes.
 
But as the ranges proposal requires (pun intended?) concepts, that
proposal will be delayed as well.
 
 
Bo Persson
Joseph Hesse <joeh@gmail.com>: Feb 02 02:37PM -0600

/*
I have a class X, instances of which I want to put into a std::set of X.
One way to do this is to make instances of X function objects
returning bool.
 
The code below won't work without the default constructor for X.
 
Why do I have to provide a default constructor? As the objects are
being inserted into the set they can be compared and put in the tree
structure implementing the set.
 
Thank you,
Joe
*/
 
#include <set>
 
class X
{
private:
int a; // only used to make xobj's function objects
public:
X() : a(1) {} // WON'T WORK WITHOUT THIS
X(int b) : a(b) {}
 
// following makes instances of X function objects
bool operator () (const X & x1, const X & x2) const
{ return x1.a < x2.a; }
};
 
int main()
{
std::set<X, X> s; // 2nd X because instances of X are function objects
 
X x1(3), x2(4), x3(5);
 
s.insert(x1);
s.insert(x2);
s.insert(x3);
 
return 0;
}
Bonita Montero <Bonita.Montero@gmail.com>: Feb 02 09:50PM +0100

If you don't want to have a default-constructor use set::emplace().
 
#include <set>
#include <string>
 
using namespace std;
 
struct S
{
S( string s ) { m_s = s; }
string m_s;
};
 
struct S_less
{
bool operator ()( S sA, S sB )
{
return sA.m_s < sB.m_s;
}
};
 
int main()
{
set<S, S_less> ss;
 
ss.emplace( string( "abc" ) );
}
 
--
http://facebook.com/bonita.montero/
Joseph Hesse <joeh@gmail.com>: Feb 02 03:09PM -0600

On 02/02/2017 02:50 PM, Bonita Montero wrote:
> set<S, S_less> ss;
 
> ss.emplace( string( "abc" ) );
> }
 
My code doesn't work if I remove the default constructor for X and
change 'insert' to 'emplace'
Joseph Hesse <joeh@gmail.com>: Feb 02 03:11PM -0600

On 02/02/2017 02:50 PM, Bonita Montero wrote:
> set<S, S_less> ss;
 
> ss.emplace( string( "abc" ) );
> }
 
My code doesn't compile if I remove the default constructor for X and
replace 'insert' with 'emplace'.
Thanks,
Joe
Bonita Montero <Bonita.Montero@gmail.com>: Feb 02 10:14PM +0100

Am 02.02.2017 um 22:09 schrieb Joseph Hesse:
 
> My code doesn't work if I remove the default constructor for X and
> change 'insert' to 'emplace'
 
Then remove the default-constructor ....
 
 
> s.insert(x1);
> s.insert(x2);
> s.insert(x3);
 
... and replace this with:
 
s.emplace( 3 );
s.emplace( 4 );
s.emplace( 5 );
 
--
http://facebook.com/bonita.montero/
Bonita Montero <Bonita.Montero@gmail.com>: Feb 02 10:19PM +0100

Am 02.02.2017 um 22:16 schrieb Stefan Ram:
 
> The implementation wants to have a constructor.
 
... if you want to use set::insert(), but you can also use emplace().
 
--
http://facebook.com/bonita.montero/
ram@zedat.fu-berlin.de (Stefan Ram): Feb 02 09:16PM

>Why do I have to provide a default constructor?
 
The implementation wants to have a constructor.
 
What are the general circumstance under which a constructor
(or any other function) is required to exist?
 
Which hypothesis can you derive from this and how
could you modify your source code to test it?
Christiano <christiano@engineer.com>: Feb 02 07:11PM

I come from the C language. I have the impression that in C ++ the ideal
is "C ++ header only" libraries. See Boost, the most important set of
libraries is a clear example of this.But this is very clearly opposite
to the C world where if someone write body code definitions in headers is
considered someone who is learning, a beginner making mistakes. The
separation between definition and statement is very clear.
 
Books like K & R, Mastering Algorithms, use a separation, which is the
natural way of thinking of C. In fact whenever I used libraries made in C,
I never saw anything that was "header-only".
 
So, what's the point? Why in C ++ is this way?
Daniel <danielaparker@gmail.com>: Feb 02 11:26AM -0800

On Thursday, February 2, 2017 at 2:11:29 PM UTC-5, Christiano wrote:
> I come from the C language. I have the impression that in C ++ the ideal
> is "C ++ header only" libraries.
 
> So, what's the point? Why in C ++ is this way?
 
It's partly for practical reasons. It's easier to use a third party header only
library. With C++, separate libraries have to be built for every version of
every compiler supported, which can be difficult to manage. Particularly if
you're supporting a mix of compilers, compiler versions, and operating systems,
and use travis to test your code, as many open source projects do.
 
Daniel
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 02 08:37PM +0100

On 02.02.2017 20:11, Christiano wrote:
> I come from the C language. I have the impression that in C ++ the ideal
> is "C ++ header only" libraries.
 
It's not an ideal, but it's a possibility, and for template code a
necessity.
 
For non-template code one great advantage is that it simplifies builds
of the client code: there's nothing to do, no choice between umpteen
pre-built variants like debug+DLL+multithreaded runtime, etc.
 
The main disadvantage is also related to building: that essentially
everything needs to be compiled when one re-builds something.
 
Another disadvantage is that there's no boundary between interface and
implementation, no compiler firewall. In particular that means that two
modules whose implementations depend on each others interfaces, can be
difficult to express. One example is that exceptions carry strings, but
strings use exceptions.
 
 
> to the C world where if someone write body code definitions in headers is
> considered someone who is learning, a beginner making mistakes. The
> separation between definition and statement is very clear.
 
Oh, it can be more clear in C++, via public, protected and private
access, and via namespace conventions such as Boost's `detail` and
others' `impl`.
 
 
> natural way of thinking of C. In fact whenever I used libraries made in C,
> I never saw anything that was "header-only".
 
> So, what's the point? Why in C ++ is this way?
 
Originally, in C++98 and C++03, C++ had an `export` feature for separate
compilation of templates. This was difficult to implement, and AFAIK
only two compilers did, namely Comeau, and, accessible via an
undocumented option, Intel. I think both relied on an Edison group back-end.
 
Since lots of compilers simply didn't implement `export` it was removed
in C++11, along with some other unsuccessful features.
 
As a possible replacement there is a module proposal being worked on,
based on a module implementation in clang, and now being fleshed out via
the Visual C++ compiler. IIRC it's Gabriel Dos Reyes (speling?) and one
other guy doing this. I am not at all sure how it connects, if at all,
but hopefully, to separate compilation of templates.
 
 
Cheers!,
 
- Alf
legalize+jeeves@mail.xmission.com (Richard): Feb 02 08:58PM

[Please do not mail me a copy of your followup]
 
Christiano <christiano@engineer.com> spake the secret code
 
>I come from the C language.
 
My best general advice for C programmers:
 
1. Forget what you know about C when reading C++.
2. Treat C++ as a new language and not as a dialect of C.
--
"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>
Daniel <danielaparker@gmail.com>: Feb 02 10:07AM -0800


> consider Moses and Aaron to be villains.
 
A Canaanites would have thought so, much as modern civilized man regards Hitler:
massacres of men and women and children with the intent to kill an entire people
tend to evoke that reaction. But keep in mind that the Pentateuch is generally
considered to have been written much later than the purported events, in the
monarchy period.
 
Daniel
Gareth Owen <gwowen@gmail.com>: Feb 02 07:34PM

>> > of G-d's sovereignty.
 
>> It's nice to see that Brian has a sense of self deprecating humour!
 
> You may wish to cast me as a villain
 
I consider you a buffoon. You're some way below villain.
 
> because you also consider Moses and Aaron to be villains
 
I rarely consider them at all, and when I do
a) I don't consider them villains
b) you really shouldn't flatter yourself with comparisons
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Feb 02 08:13PM

On Thu, 2 Feb 2017 09:41:53 -0800 (PST)
> Pharoah, and G-d freed millions of people who had been slaves
> to a powerful regime. I'm with those who realize they are prone
> to slavery and need G-d as much as the ancient Israelites did.
 
Relax, he wasn't casting you as a villain. It was just making fun of
you for your delusions of grandeur. He was treating you as a joke, not
a villain, if that makes you feel better about yourself.
 
You are also illogical. No one had at any stage mentioned, or thought
of, Moses or Aaron. That is just another instance of your
self-delusion.
 
I suspect you are more prone to insanity than slavery.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 02 08:25PM +0100

On 02.02.2017 17:32, Bonita Montero wrote:
> {
> int *a = (int *)alloca( K * sizeof(int) );
> }
 
Note that
 
• `alloca` is not standard, but is commonly available, and
 
• unfortunately how to check for allocation failure, or even if that's
possible at all, differs between compilers/systems.
 
There have been proposals for variable length arrays in C++, but as far
as I know they've all been discontinued. :( E.g. see <url:
http://stackoverflow.com/a/40656359/464581>.
 
It's sad because it absolutely needs core language support: one can't
implement a reasonable dynamic length stack based array as a library
solution. One IMO unreasonable way, that in principle could be used for
e.g. string encoding conversions, is to allocate a global buffer that is
treated as a stack and passed down the call chain. This was suggested
seriously in comp.std.c++ when VLA were discussed there, but I have
never seen or heard about that possible technique elsewhere.
 
 
> -pointer because the stack-pointer is advanced a variable distance and
> the compiler would not be able to find back to the calling stack-frame
> without this frme-pointer.
 
In a debug build there's usually a frame pointer regardless of whether
`alloca` is used or not. This allows a debugger to walk up the stack in
order to present the current call chain. A modern processor has enough
registers that I wouldn't worry about any lost optimization opportunity.
 
The main problem, as I see it, apart from the low level of abstraction,
is for portable code: that because `alloca` isn't standard, there's no
directly portable way to check if it succeeds.
 
For portable code one would have to write a failure-checking wrapper
with slightly different implementations for different systems, and I'm
not sure if all implementations of `alloca` support such checking. As an
example of failure checking, Microsoft's `alloca` reports failure via an
SEH exception, which is not a C++ exception. One needs to use Windows
specific language extensions to catch that.
 
 
Cheers & hth.,
 
- Alf
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)