Originally posted by hoohoo
View Post
Announcement
Collapse
No announcement yet.
C++17 Is Now Official
Collapse
X
-
Originally posted by Hi-Angel View PostWell, in this particular case it does make sense to use explicit return value. That said, I would generally refrain of using "auto" as a return type in favor of templates, because templates are imposing constraints on what exactly one wanted to return. And in case of templates you'd get again return T(1, 2, "thread1"); which doesn't tell you much.
Comment
-
Originally posted by hoohoo View Post
I like templates - because they constrain things, and they express concepts better IMHO than inheritance. They can be obscure too though, through verbosity.Last edited by Hi-Angel; 06 December 2017, 02:18 AM.
- Likes 1
Comment
-
Originally posted by hoohoo View Post- C++11 added lambda expressions... now I regularly find open source software (and sometimes closed source in the work place) where an entire program is implemented in essentially one function using lambdas to differentiate execution paths. Many dozens, to hundreds, of lines in each lambda, it's incredibly hard to read, and neither Slickedit nor Notepad++ can auto-format this kind of code well. It's worse than spaghetti code implemented with goto. In fact lambdas seem to encourage this Javascript style code. Lambdas are intrinsically antithetical to the idea of structured code.
- Likes 1
Comment
-
Originally posted by toojays View PostThe price of the final standard is set by the ISO, who own the copyright. Pretty much all practitioners refer to the final draft, which is free.
Comment
-
Originally posted by Hi-Angel View PostYeah, I agree, templates sometimes can be quite hard to read. I have this decoder in my head though which is called Haskell, it makes work with templates easier. Haskell is a very elegant, both syntax and ideas -wise, language, I recommend learning it. Knowing Haskell might give lots of insights into a better design. I'm even using pseudo-haskell for prototyping a code that I am not sure yet how to write, before making an actual implementation in whatever other language I'm using. And I assure you, my Haskell-foo is far from being good.
Comment
-
Originally posted by Hi-Angel View PostI am simply saying that there's no need to be explicit about the return type, because it is clear anyway.
Ah, well. It works with a constructor too, see, quick'n'dirty example:
Code:struct MyJITThread { int fd; const char* name; MyJITThread(int fdArg, const char* nameArg, int pidArg): pid(pidArg), fd(fdArg), name(nameArg) {} MyJITThread(int fdArg, const char* nameArg, MyJITThread& thr): pid(thr.pid), fd(fdArg), name(nameArg) {} private: int pid; }; int main() { MyJITThread thr1 = {fd: 1, name: "thread1", pid: 2}; MyJITThread thr2 = {fd: 1, name: "thread2", thread: thr1}; }
- Likes 3
Comment
-
Originally posted by discordian View Post
Problem is, that this is NOT C++, but "GNU C++", those named initializers are not part of the standard but a gnu extension. Compile with "-std=c++17 -pedantic" should you believe your compiler more than me.
Comment
-
Originally posted by Hi-Angel View PostE.g. if you're iterating over the vector and changing it at the same time — obviously "iterators are unsafe"
Now don't get me wrong, I really do want to use iterators since they (or many of the new features of C++11+) are really clean and convenient. However if the "guaranteed" safety is not there I can't quite justify it.
Something like Microsoft's "Safe iterators" would be cool but as an actual standard of the language rather than some vendor specific hackup job (or DUMA / mprotect).
(though I still don't like async code. I don't think it is suitable for a lot of use-cases where the execution does need to block until a task is complete. Games and systems level development (i.e what C++ excels at) comes to mind.Last edited by kpedersen; 09 December 2017, 01:03 PM.
Comment
-
Originally posted by kpedersen View Post
I think the problem for me is that in many cases in a large software codebase you cannot "guarantee" that you (or some other developer) is not changing the vector you are iterating through. It might be down a very long code path that happens to clear the entire vector. Yes, the ::at(size_t) solution will still have issues with this, i.e you might end up skipping over certain entries but at least it will not cause "undefined behavior".
This is a generic problem and not one of iterators, commonly you define layers and don't permit touching objects from lower levels so that you CAN "guarantee" calling a function wont affect "its basement" by following a set of rules you can verify for each part of the software.
No language will prevent you from creating a hell of dependencies and side-effects (maybe LISP and Haskell are different).
- Likes 2
Comment
Comment