Live data from Hacker News

Returning multiple values from functions in C++

eli.thegreenplace.net

61–67 of 67 posts

Re: Returning multiple values from functions in C++

#61
post #60
post #59

Earlier quoted context omitted.

The user needs to learn more than in Java: 1) Learn to deal with a language which has an infinite number of syntactic abstractions. 2) Learn the typical patterns of syntactic abstractions (WITH- , BIND-, DEF- ...). 3) Learn how to write your own abstractions. Then groups will settle on common (!) Lisp patterns. See for example: https://common-lisp.net/project/alexandria/ There are lots of libraries which provide lang…

Yeah, I use Alexandria by default in every project now. I remember when I first started coding in Lisp, I wrote a ton of obvious functions/macros like the missing hash table traversals that are in Alexandria but are rather bizarrely missing from the Common Lisp spec. Then I found Alexandria and realised I'd written a good fraction of those functions myself! This was pre-quicklisp, so library discoverability wasn't gr…

Common Lisp already provides various hash-table traversals with LOOP: http://www.lispworks.com/documentation/HyperSpec/Body/06_aba...

Re: Returning multiple values from functions in C++

#62
post #61
post #60

Earlier quoted context omitted.

Yeah, I use Alexandria by default in every project now. I remember when I first started coding in Lisp, I wrote a ton of obvious functions/macros like the missing hash table traversals that are in Alexandria but are rather bizarrely missing from the Common Lisp spec. Then I found Alexandria and realised I'd written a good fraction of those functions myself! This was pre-quicklisp, so library discoverability wasn't gr…

Common Lisp already provides various hash-table traversals with LOOP: http://www.lispworks.com/documentation/HyperSpec/Body/06_aba...

That's a good point. I always tend to forget about loop because I don't use it all that much, prefer using the Iterate library. Loop is a whole extra language all on its own.

Re: Returning multiple values from functions in C++

#63
post #39
post #8

Earlier quoted context omitted.

That's not the fault of optional though. It's because with the optional version you're creating (and destroying) a new string each iteration of the loop. Something like this (untested) should be much closer to the non-optional version: #include #include #include using namespace std; using namespace boost; optional getline_(istream &st, string& line) { if(getline(st, line)) return line; return none; } int main() { int…

Which more or less removes any benefit for using optional, unfortunately.

Yes for this case, but that's just because it's a bad example for comparing the performance of optional, because the code is doing things that have very different performance characteristics.

There are plenty of other cases though where it is useful to use optional (e.g. instead of passing/returning a naked pointer which may or may not be null) and in those cases use of optional will have little/no overhead.

Re: Returning multiple values from functions in C++

#64
post #57

Earlier quoted context omitted.

I was talking about the general idea of MVR, AND how I thought is was implemented in lisp. I was wrong. This happens sometimes. And even the new explanation, I STILL don't like MVR. I think that returning a list or other data structure, or just writing two functions, is much clearer, and lends itself better to function chaining. Sure, in CL there's a default, which makes things a little better, but what if you want t…

Why don't you take a bit of time to read about multiple values in Common Lisp? CL-USER 76 > (nth-value 1 (values 'a 'b 'c 'd)) B While you are at it, check out the feature of 'Macros' in Lisp, which allows everyone to write code to shorten this stuff. See my code in this thread for a macro which then allows you to write: (multiple-value-bind-some (NIL b) (foo bar baz) b) One then can name ignored variables as NIL in…

Good point. And very true. Still looks a bit ugly to me, but it's better than nothing, I suppose. And yes, I am aware of macros. For some reason using them in this situation didn't occur to me, so I guess I am an idiot after all.

This is actually one of the cases where syntax-rules would allow you to write something cleaner, I would guess. I like syntax rules, but everybody always seems to complain about it...

Re: Returning multiple values from functions in C++

#65
post #58

For a moment, I thought they had added true multiple value return to C++. I am sooo glad they didn't. The lisp folks added it way back, and it has been an ugly scar on the language ever since. Why do real multi-value returns suck? because they don't compose well, they're awkward as all heck to use, and require wrapping certain function calls in really weird constructs. The PROPER way to do multiple values is to retur…

Which is clearly nonsense. Multiple values have been extremely useful and there are several code bases in Common Lisp which make extensive use of it.

Yes. They are useful. So is goto, so are continuations. MVR isn't the unforgivable sin that those things are, but imo, it makes your codebase uglier.

Re: Returning multiple values from functions in C++

#66
post #58

Earlier quoted context omitted.

Which is clearly nonsense. Multiple values have been extremely useful and there are several code bases in Common Lisp which make extensive use of it.

Yes. They are useful. So is goto, so are continuations. MVR isn't the unforgivable sin that those things are, but imo, it makes your codebase uglier.

Many Lisp programmers think different.

Re: Returning multiple values from functions in C++

#67
post #66

Earlier quoted context omitted.

Yes. They are useful. So is goto, so are continuations. MVR isn't the unforgivable sin that those things are, but imo, it makes your codebase uglier.

Many Lisp programmers think different.

Well, I'm not many lisp programmers. I'm me. I've got an opinion that I think is reasonable, and I'm willing to hear you out. In fact, I already have, and I disagree. This isn't a problem, it's good to hear differing opinions, although you always sound a bit smug about it. But I could just be reading that in.

Point is, I disagree, and your opinion is fine. 'Kay?

Post reply on HN