Tuesday, January 10, 2017

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

Bo Persson <bop@gmb.dk>: Jan 10 09:57PM +0100

On 2017-01-10 21:25, Real Troll wrote:
>> https://msdn.microsoft.com/en-us/magazine/mt694085.aspx
 
>> Lynn
 
> Any ideas when is the next Visual C++ coming out?
 
Soon-ish. It's at the Release Candidate level.
 
https://www.visualstudio.com/vs/visual-studio-2017-rc/
 
 
Bo Persson
legalize+jeeves@mail.xmission.com (Richard): Jan 10 10:24PM

[Please do not mail me a copy of your followup]
 
David Brown <david.brown@hesbynett.no> spake the secret code
>enough of the details to give a technical opinion. But it would have
>been nice to see more cooperation between MSVC developers and clang
>developers -
 
Gabriel Dos Reis is a long-time gcc contributor and is the main person
behind modules at Microsoft. I guarantee you that he collaborates
with clang/gcc developers regarding modules.
 
>[...] clang has had an experimental module implementation for
>some time now,
 
If you look more deeply into what's been implemented in clang you find
that it's somewhere between an advanced precompiled header and a
module. It's less than full-blown modules and it's more than a
precompiled header.
 
>and I believe MSVC wanting to go their own way has been a
>big reason for C++17 not having modules.
 
What Gabriel Dos Reis has proposed is a direct result of experience
using the modules implementation in clang, not something that stabs
out in a completely different direction just for the sake of being
different.
 
>If the MS idea is technically
>significantly better, that's fair enough - but not if it is just them
>trying to be "first" at something in the C++ world.
 
Sorry, but this is just supposition on your part and doesn't seem to
be based on any of the actual information from either folks on the
clang team who have described their work with modules or from Gabriel
Dos Reis who has described Microsoft's work with modules.
 
AFAIK, what the clang team did never resulted in a formal proposal to
the standards committe. Maybe there was some working paper proposal
but a little googling didn't turn it up. Gabriel Dos Reis (and
collaborators) created a proposal to the standards committe that was
most definitely informed by the experiments dont with clang. I
suggest you take a look at the proposal. This is one version, there
may be a newer version: <https://isocpp.org/files/papers/N4047.pdf>.
For earlier discussions of a module system, see the references in the
above paper.
 
I'm unaware of any attempt, experimental or otherwise, to support modules
in gcc.
--
"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>
David Brown <david.brown@hesbynett.no>: Jan 10 10:43PM +0100

On 10/01/17 21:05, Lynn McGuire wrote:
> "Visual C++ - Microsoft Pushes C++ into the Future"
> https://msdn.microsoft.com/en-us/magazine/mt694085.aspx
 
> Lynn
 
Modules are a great idea, at least in principle - I haven't followed
enough of the details to give a technical opinion. But it would have
been nice to see more cooperation between MSVC developers and clang
developers - clang has had an experimental module implementation for
some time now, and I believe MSVC wanting to go their own way has been a
big reason for C++17 not having modules. If the MS idea is technically
significantly better, that's fair enough - but not if it is just them
trying to be "first" at something in the C++ world.
 
Still, it's nice to see MSVC are catching up with C++14.
David Brown <david.brown@hesbynett.no>: Jan 11 12:28AM +0100

On 10/01/17 23:24, Richard wrote:
> may be a newer version: <https://isocpp.org/files/papers/N4047.pdf>.
> For earlier discussions of a module system, see the references in the
> above paper.
 
Thank you for the information. I am glad to be corrected here - the C++
world gets better when everyone is working together. I guess I am just
a little disappointed that there are no modules in C++17, and I felt it
was unhelpful to have two competing (as I saw it) module systems. But
it was unfair of me to suggest that this was anything other than
people's desire to make a good technical solution rather than a fast fix.
 
> I'm unaware of any attempt, experimental or otherwise, to support modules
> in gcc.
 
I presume they are waiting until a solution is finalised (rather than
having yet another experimental version).
David Brown <david.brown@hesbynett.no>: Jan 10 10:27PM +0100

On 10/01/17 18:59, Alf P. Steinbach wrote:
 
 
> I installed MingW g++ (STL's Nuwen distro) to try this but it doesn't
> like the syntax, so I have no compiler that likes it. Possibly the dang
> compiler. Or clang, as some people misread the name.
 
<https://gcc.godbolt.org/#> is always useful for testing.
David Brown <david.brown@hesbynett.no>: Jan 10 10:36PM +0100

On 10/01/17 16:54, Ben Bacarisse wrote:
 
> Sure. I'm just saying (a) it's not new and (b) it's not really multiple
> values. Even old ANSI C can return a struct, though it was fiddly to
> set up due to limitations on initialisers.
 
All true, of course.
 
> I'm not sure it really helps
> anyone to suggest this is a way to do some new thing called "returning
> multiple values".
 
As Alf says, it is a new way to make it significantly easier to return
multiple values. And although it is returning a single multi-value type
(a tuple), that is the way many languages handle "return multiple values".
 
Python supports multiple return values in functions:
 
def f() : return 1, 2
 
But you can still write:
 
x = f()
type(x)
# <type 'tuple'>
 
So the idiom above is a function returning multiple values in C++ in
exactly the same way as in Python. The new structured bindings makes it
easier to use.
 
> tell. But there have been lots of names used all over the place in the
> build-up to the proposal and, presumably, C++17 is not yet published so
> the name is probably still up for grabs.
 
I guess they will be called "decomposition declarations" in standardese,
and "structure bindings" in the common tongue.
 
From <http://en.cppreference.com/w/cpp/language/auto> we have: "A
decomposition declaration, informally known as structured binding."
Ben Bacarisse <ben.usenet@bsb.me.uk>: Jan 10 11:22PM

>> multiple values".
 
> As Alf says, it is a new way to make it significantly easier to return
> multiple values.
 
I'd say that the new syntax makes it easier to use the parts of the
return value. It is no easier to return the value than it was before.
 
I think it's unhelpful to conflate returning a tuple (which is not new)
with the new syntax for destructuring a value (which might not be the
return from any function). But if you don't mind putting them all into
the concept of "returning multiple values" I will hold my tongue.
 
The phrase is fine in casual conversation, but I thought the post was
slightly misleading as an instructional one about the technique.
 
> values".
 
> Python supports multiple return values in functions:
 
> def f() : return 1, 2
 
It supports returning a tuple. If you go this route, you will find
almost no language unable to return multiple values. What then do we
call Common Lisp's multiple return values?
 
> # <type 'tuple'>
 
> So the idiom above is a function returning multiple values in C++ in
> exactly the same way as in Python.
 
Or the idiom above is a function returning a single value in C++ in
exactly the same was as in Python. I'm not sure why Pyhton's tuples
should persuade me when C++'s don't! I agree that they are the same.
 
> The new structured bindings makes it easier to use.
 
Undoubtedly. It's a hugely useful feature. Languages like ML have had
type inference and structure pattern matching (they tend to go together)
for decades and I miss them when they're not there.
 
(For completeness, in Python you can write x,y = f() to pull the tuple
apart.)
 
<snip>
--
Ben.
Christian Gollwitzer <auriocus@gmx.de>: Jan 10 10:15PM +0100

Am 07.01.17 um 21:25 schrieb Michael Moroney:
> guarantee all changes are even compatible with each other, but it is a
> huge headstart when the goal is to produce new code with changes X, Y and
> Z in it.
 
 
Sounds good.
 
> Another nice feature is it doesn't run on Windows.
 
what, git and GNU textutils don't run on Windows?
 
Christian (has never felt the urge to reimplement diff algorithms)
Vir Campestris <vir.campestris@invalid.invalid>: Jan 10 09:21PM

> At this Minnesota workplace, no swearing and no jerks allowed
 
I thought in American a jerk (as in "jerk off") was pretty rude too...
not so in English, where it's related to jolt.
 
Andy
red floyd <dont.bother@its.invalid>: Jan 10 01:46PM -0800


> At this Minnesota workplace, no swearing and no jerks allowed
 
> http://www.twincities.com/2017/01/10/at-this-minnesota-workplace-no-swearing-and-no-jerks-allowed/
 
> "Ultimately, it's about mutual respect."
 
Fuck off. This isn't a "workplace". Who died and made you God?
David Brown <david.brown@hesbynett.no>: Jan 10 10:48PM +0100

On 10/01/17 22:21, Vir Campestris wrote:
>> At this Minnesota workplace, no swearing and no jerks allowed
 
> I thought in American a jerk (as in "jerk off") was pretty rude too...
> not so in English, where it's related to jolt.
 
"jerk" is the same thing as "jolt" - it is the derivative of
acceleration with time.
"Chris M. Thomasson" <invalid@invalid.invalid>: Jan 09 06:13PM -0800

On 1/8/2017 6:37 PM, Ramine wrote:
[...]
> When you use Semaphores , and when you release and you have attained the
> maximum count to be released, the signal(or the release) will be lost
> and this is no good,
 
Ummm, semaphores have been around for a long time, and work fine at
their job.
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)