| woodbrian77@gmail.com: Jan 10 12:02PM -0800 On Thursday, January 5, 2017 at 5:43:34 PM UTC-6, Lofty Goat wrote: Please don't swear here. 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." Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net |
| Gareth Owen <gwowen@gmail.com>: Jan 10 08:13PM > At this Minnesota workplace, no swearing and no jerks allowed This is not a workplace. Also, please stop being a jerk. |
| scott@slp53.sl.home (Scott Lurndal): Jan 10 08:34PM >http://www.twincities.com/2017/01/10/at-this-minnesota-workplace-no-swearin= >g-and-no-jerks-allowed/ >=E2=80=9CUltimately, it=E2=80=99s about mutual respect.=E2=80=9D Don't be a jerk, Brian. Mind your own business. |
| 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. |
| Lynn McGuire <lynnmcguire5@gmail.com>: Jan 10 02:05PM -0600 "Visual C++ - Microsoft Pushes C++ into the Future" https://msdn.microsoft.com/en-us/magazine/mt694085.aspx Lynn |
| Real Troll <real.troll@trolls.com>: Jan 10 04:25PM -0400 On 10/01/2017 20:05, Lynn McGuire wrote: > "Visual C++ - Microsoft Pushes C++ into the Future" > https://msdn.microsoft.com/en-us/magazine/mt694085.aspx > Lynn Any ideas when is the next Visual C++ coming out? I have VC++ since version 10 (10, 12, 13, 15) and I love it!! |
| 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 |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jan 10 12:59PM -0800 On Tuesday, January 10, 2017 at 3:22:14 PM UTC-5, Real Troll wrote: > > Lynn > Any ideas when is the next Visual C++ coming out? > I have VC++ since version 10 (10, 12, 13, 15) and I love it!! RC Candidate 2017 is out. Its IDE is slow and clunky at times. I've seen the "Visual Studio is still working. We're sending feedback to Microsoft about this UI action" pop up. And sometimes even simple UI operations are very oddly timed for giving user feedback. Best regards, Rick C. Hodgin |
| 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. |
| "Chris M. Thomasson" <invalid@invalid.invalid>: Jan 09 06:50PM -0800 I am wondering what everybody thinks about the following, fairly crude attempt at a "free-function" input/output parameter "encapsulation method": _______________________________________ #include <cstdio> struct func_foo { struct input { int a; int b; }; struct output { int a; int b; int c; }; static output exec(input const& i) { output o = { i.a + 1, i.b + 2, (i.a + i.b) / 2 }; return o; } }; int main(void) { func_foo::input i = { 1, 2 }; func_foo::output o = func_foo::exec(i); std::printf("o:(a:%u, b:%u, c:%u)\n", o.a, o.b, o.c); return 0; } _______________________________________ So far, this seems fairly clean to me, well, using struct as a quasi namespace aside for a moment... Thanks. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 10 08:02AM +0100 On 10.01.2017 03:50, Chris M. Thomasson wrote: > _______________________________________ > So far, this seems fairly clean to me, well, using struct as a quasi > namespace aside for a moment... It's hard top come up with a good name for `exec` here, but I've landed on `result_for`, because that makes the calling code readable: `func_foo::result_for(i )`. C++11 added support that means the input structure can be specified inline, as in the call `func_foo::exec({1, 2, 3})`. C++17 adds support for returning multiple values from a function, here's an example from ¹a Stack Overflow Q/A: [code] #include <tuple> using namespace std; tuple<int, int> divide(int dividend, int divisor) { return {dividend / divisor, dividend % divisor}; } #include <iostream> int main() { auto [quotient, remainder] = divide(14, 3); cout << quotient << ',' << remainder << endl; } [/code] Cheers!, - Alf Links: ¹ <url: http://stackoverflow.com/a/16516315/464581> |
| Juha Nieminen <nospam@thanks.invalid>: Jan 10 07:15AM > C++17 adds support for returning multiple values from a function Structured bindings have nothing to do with "returning multiple values from a function". |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 10 09:57AM +0100 On 10.01.2017 08:15, Juha Nieminen wrote: >> C++17 adds support for returning multiple values from a function > Structured bindings have nothing to do with "returning multiple values > from a function". Forks have nothing to do with eating. Cheers & hth., - Alf |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Jan 10 12:09PM "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes: <snip> > tuple<int, int> divide(int dividend, int divisor) { > return {dividend / divisor, dividend % divisor}; > } I think this could be explained more clearly. That looks to me like a pre-C++17 function that returns a single value. > #include <iostream> > int main() { > auto [quotient, remainder] = divide(14, 3); I think this is the new part. In C++ this is called a decomposition declaration (though the gcc docs call it a structured declaration). Other languages would call it a de-structuring binding or a pattern match. I.e. the new part is the syntax to decompose a single, structured value. > cout << quotient << ',' << remainder << endl; > } > [/code] <snip> -- Ben. |
| David Brown <david.brown@hesbynett.no>: Jan 10 02:16PM +0100 On 10/01/17 13:09, Ben Bacarisse wrote: >> tuple<int, int> divide(int dividend, int divisor) { >> return {dividend / divisor, dividend % divisor}; >> } Alternatively: auto divide(int dividend, int divisor) { return std::make_tuple(dividend / divisor, dividend % divisor); } > I think this could be explained more clearly. That looks to me like a > pre-C++17 function that returns a single value. It is. But that one value is a tuple of two parts - it is (becoming) the common idiom for returning multiple values from a function. Unless someone figures out a better syntax for later C++ standards, this is as close to multiple return values as we can get. (C and C++ would, IMHO, have been much nicer languages without the "comma operator" - and we would by now have had a simpler multiple return value syntax. But as we say in Norway, "done is done and eaten is eaten".) > declaration (though the gcc docs call it a structured declaration). > Other languages would call it a de-structuring binding or a pattern > match. C++ calls it "structured bindings", as far as I am aware, as does gcc: <https://skebanga.github.io/structured-bindings/> <http://wg21.link/P0144r2> |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Jan 10 03:54PM > the common idiom for returning multiple values from a function. Unless > someone figures out a better syntax for later C++ standards, this is as > close to multiple return values as we can get. 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. I'm not sure it really helps anyone to suggest this is a way to do some new thing called "returning multiple values". <snip> >> Other languages would call it a de-structuring binding or a pattern >> match. > C++ calls it "structured bindings", as far as I am aware, as does gcc: My copy of the C++ draft describes the under the heading "decomposition declaration" and the word "structured" does not appear as far as I can 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. <snip> -- Ben. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 10 06:59PM +0100 On 10.01.2017 16:54, Ben Bacarisse wrote: >> close to multiple return values as we can get. > Sure. I'm just saying (a) it's not new and (b) it's not really multiple > values. What would be? > set up due to limitations on initialisers. I'm not sure it really helps > anyone to suggest this is a way to do some new thing called "returning > multiple values". In practice it is a new thing, as I see it. Before C++17 one would have to use cumbersome `std::tie` to split the composite return value, and so one was reluctant to design with such functions. Now it's a breeze. Consider old // C++11 #include <tuple> using namespace std; auto divide( int const dividend, int const divisor ) -> tuple<int, int> { return make_tuple( dividend / divisor, dividend % divisor ); } #include <iostream> auto main() -> int { int quotient, remainder; tie( quotient, remainder ) = divide(14, 3); cout << quotient << ',' << remainder << endl; } versus new // C++17? #include <tuple> using namespace std; auto divide( int const dividend, int const divisor ) { return make_tuple( dividend / divisor, dividend % divisor ); } #include <iostream> auto main() -> int { auto[quotient, remainder] = divide( 14, 3 ); cout << quotient << ',' << remainder << endl; } 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. Cheers!, - Alf |
| Melzzzzz <mel@zzzzz.com>: Jan 10 07:06PM +0100 On Tue, 10 Jan 2017 18:59:32 +0100 > dang compiler. Or clang, as some people misread the name. > Cheers!, > - Alf gcc6 doesn't support it. gcc7 does. clang 3.9 doesn't support it. 4.0 does. -- press any key to continue or any other to quit... |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Jan 10 07:54PM >> Sure. I'm just saying (a) it's not new and (b) it's not really multiple >> values. > What would be? Well, if the values are not bound together in some single value, then that's clearly multiple return values. For example, Common Lisp has multiple return values, as does (in a much more elaborate way) Prolog. In some others, like Icon, expressions (including function calls) can have both a return value and a success status. > have to use cumbersome `std::tie` to split the composite return value, > and so one was reluctant to design with such functions. Now it's a > breeze. Yes, but it's the "destructuring" decomposition declaration that's new, not the use of an aggregate object as the return value. You can use C++17's auto [v1, v2] = ... syntax even with an expression that returns a plain old struct. <snip> -- Ben. |
| 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." |
| ram@zedat.fu-berlin.de (Stefan Ram): Jan 10 08:04PM >i.a + 1, >i.b + 2, >(i.a + i.b) / 2 One variant might be: static void escape( void * p ) { asm volatile( "" : : "g"(p) : "memory" ); } class averager { int a_; int b_; int c_; public: constexpr averager ( int const x, int const y ): a_{ x + 1 }, b_{ y + 2 }, c_{ ( x + y )/ 2 } {} int a() const { return a_; } int b() const { return b_; } int c() const { return c_; } }; int main() { averager av( 2, 3 ); int a = av.a(); escape( &a ); int b = av.b(); escape( &b ); int c = av.c(); escape( &c ); } But then, I.24: Avoid adjacent unrelated parameters of the same type Reason Adjacent arguments of the same type are easily swapped by mistake. Alternative Define a struct as the parameter type and name the fields for those parameters accordingly , by which your solution actually is better. Well, I think, the guidelines mean that you should use the names, thus, replace input i = { 1, 2 }; by input i; i.horizontal = 1; i.vertical = 2; . (Of course not meaningless names such as »a« or »b«.) |
| 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. |
No comments:
Post a Comment