|
Voted Worst Mom posted:Which language doesn't allow you to write C# and probably many other languages don't let you use literals or operators with no side effects as statements.
|
#
?
Sep 15, 2016 17:27
|
|
|
|
| # ? May 16, 2024 07:48 |
|
|
SupSuper posted:You can set throwOnError=true, but yeah the fact it isn't the default has caught me off-guard a few times. I'm not 100% sure I'd ever get this thing started if it threw on every error. Also pretty peeved that cshtml isn't compiled by default. Oh and I once tried to work on a WPF project that had effectively become exactly as fragile WRT model consistency as HTML. Worked fine as long as everything was manually type-checked, but JFC was it a pain in the dick.
|
|
#
?
Sep 15, 2016 20:00
|
|
|
xzzy posted:I've never made it to quux. quux is a coding horror because it's a pain to type. Don't make me work for my nonsense placeholders. I usually go foo bar baz bort bart blarg blip...
|
|
#
?
Sep 15, 2016 20:49
|
|
|
x y z for atoms, xs ys zs for collections, f g h for functions, a b c for types
|
|
#
?
Sep 15, 2016 22:31
|
|
|
xtal posted:By return value do you mean expression? Because that makes perfect sense Anything that is supposed to be handled by somebody. Yeah, sure, if you look at the assembly level, the computer doesn't care if you do anything with its return value, but it's still a really bizarre thing that C and friends do. Voted Worst Mom posted:Which language doesn't allow you to write Pascal. Incidentally, a language which uses ":=" for assignment, which is much more visually distinct from "=" than "==". fleshweasel posted:C# and probably many other languages don't let you use literals or operators with no side effects as statements. That's good to know!
|
|
#
?
Sep 16, 2016 00:36
|
|
|
has anybody ever found a valid use for the comma operator in C
|
|
#
?
Sep 16, 2016 01:08
|
|
|
Suspicious Dish posted:has anybody ever found a valid use for the comma operator in C while(thing_that_modifies_var(var), var > some_int)
|
|
#
?
Sep 16, 2016 01:10
|
|
|
Suspicious Dish posted:has anybody ever found a valid use for the comma operator in C The closest I've come is a defensive habit in manually reference counted objc. In objc calling methods (actually sending messages but whatever) on nil is a no op but calling methods on a released object is a terrible idea. I would write: Objective-C code:So if I accidentally tried to use thinger later then nothing would happen. I would absolutely not criticize anyone who split that on to two lines, but using comma felt harder to gently caress up.
|
|
#
?
Sep 16, 2016 02:02
|
|
|
Suspicious Dish posted:has anybody ever found a valid use for the comma operator in C getting fancy with for-loops, but even then that's a sign that maybe you should try something else
|
|
#
?
Sep 16, 2016 03:38
|
|
|
I thought it was a different construction in a for loop, because I thought comma-operator style i = 1, j = 2 would be parsed as i = (1, j = 2), return the RHS, and set both to 2.
|
|
#
?
Sep 16, 2016 03:42
|
|
|
No, comma parses outside of assignment. The for loop is a legitimate use of the operator, although obviously the language should have just made that a special piece of grammar instead.
|
|
#
?
Sep 16, 2016 04:59
|
|
|
Bigger question, has anyone ever found a good reason to overload the comma operator in C++?
|
|
#
?
Sep 16, 2016 06:08
|
|
|
vOv posted:Bigger question, has anyone ever found a good reason to overload the comma operator in C++? "Good" might be a stretch, but both Boost::Assign and Boost::Phoenix have found somewhat-reasonable uses for overloading it. edit: Not that I've ever used either of those libraries, I just remember that from the last time this came up.
|
|
#
?
Sep 16, 2016 06:17
|
|
|
TooMuchAbstraction posted:The real horror is that you forgot that quux comes after baz. Heretics! It's "foo, bar, baz, zip, qux, quux, quuux, ..."
|
|
#
?
Sep 16, 2016 06:21
|
|
|
Zopotantor posted:Heretics! It's "foo, bar, baz, zip, qux, quux, quuux, ..." I thought it was "fett, boba, binks, luke, luuke, luuuke, ..."
|
|
#
?
Sep 16, 2016 06:23
|
|
|
VikingofRock posted:I thought it was "fett, boba, binks, luke, luuke, luuuke, ..." I think I'll adopt this from now on simply because it doesn't carry the taint of ESR.
|
|
#
?
Sep 16, 2016 06:28
|
|
|
pseudorandom name posted:taint of ESR. Well, it's time to start drinking that mental image away.
|
|
#
?
Sep 16, 2016 06:37
|
|
|
It's not proper but I prefer bodily functions and related terms such as fart, poop, butt, rear end, etcetera since they can serve as predicates and nouns to represent function and argument names respectively.
|
|
#
?
Sep 16, 2016 07:14
|
|
|
hoge, fuga, piyo, hogera, hogehoge
|
|
#
?
Sep 16, 2016 08:20
|
|
|
VikingofRock posted:"Good" might be a stretch, but both Boost::Assign and Boost::Phoenix have found somewhat-reasonable uses for overloading it.
|
|
#
?
Sep 16, 2016 11:56
|
|
|
SupSuper posted:For every 1 reasonable use there's probably 100 other unreasonable uses hidden away in Boost. Hey boost that thing looks cool, can I borrow it? The next day boost shows up and moves all their stuff into your living room.
|
|
#
?
Sep 16, 2016 12:09
|
|
|
x87 strikes again https://randomascii.wordpress.com/2016/09/16/everything-old-is-new-again-and-a-compiler-bug/ Also if anyone isn't reading Dawson's blog, you should start now.
|
|
#
?
Sep 16, 2016 13:43
|
|
|
Huh, I thought x87 was dead, or does chrome keep it around for _really_ old machines?
|
|
#
?
Sep 16, 2016 15:02
|
|
|
Beef posted:Huh, I thought x87 was dead, or does chrome keep it around for _really_ old machines? Per the blog, it was in third party code. I expect if you compile code for 32-bit and don't do anything special with the compiler flags it still defaults to targeting something really old like 486 or OG Pentium, so it'll generate x87 instructions.
|
|
#
?
Sep 16, 2016 15:10
|
|
|
Beef posted:Huh, I thought x87 was dead, or does chrome keep it around for _really_ old machines? It only comes up with an extra option for LTCG and whole program optimization. It's a mismatch between a function return using an sse register and the caller expecting an x87 register so Microsoft appears to be doing some crazy register optimizations. The third party code just turned on reporting of x87 exceptions. The bug exists in normal builds, but the exception doesn't cause a crash.
|
|
#
?
Sep 16, 2016 15:16
|
|
|
Suspicious Dish posted:has anybody ever found a valid use for the comma operator in C It's basically the same as `(>>) :: m a -> m b -> m b` right? Useful for when you want to jam a side effect into an expression that returns something else.
|
|
#
?
Sep 16, 2016 15:38
|
|
|
feedmegin posted:Per the blog, it was in third party code. I expect if you compile code for 32-bit and don't do anything special with the compiler flags it still defaults to targeting something really old like 486 or OG Pentium, so it'll generate x87 instructions. Almost. Absent an ABI break, ABI details like calling conventions have to be stable; you can't just change them when there are new processor features, because code compiled before still has to be callable from (and be able to call) code compiled after. So the 32-bit Windows calling convention is still exactly the same as it was twenty-five years ago, and back then they decided that the right way to return floating-point values was on the x87 floating-point operand stack. And it will stay that way forever unless Microsoft drops support for every existing Windows binary. (New architectures are necessarily ABI breaks, so the 64-bit calling conventions are not obliged to interoperate with old code; therefore they can return floating-point values in the SSE registers, which are guaranteed to exist on x86-64.) Now, the compiler doesn't always have to follow the calling convention; it can use ad hoc specialized calling conventions if it knows all the possible call sites. That's what's happening here, except that it is apparently wrong about knowing all the possible call sites. That might be a compiler bug (the compiler is forgetting about some interesting way that the function might be used), or it might be a project configuration bug (compiling a plugin with whole-program optimization sounds like bullshit to me), or it might be a project source bug (maybe this function is discovered in a fundamentally unreasonable way, and the code ought to mark it more clearly as externally used).
|
|
#
?
Sep 16, 2016 19:57
|
|
|
vOv posted:Bigger question, has anyone ever found a good reason to overload the comma operator in C++? I'm not sure if it's a good reason, but the Eigen linear algebra library uses it for initializing vectors and matrices of arbitrary size. I.e. C++ code:
|
|
#
?
Sep 16, 2016 23:07
|
|
|
Absurd Alhazred posted:I'm not sure if it's a good reason, but the Eigen linear algebra library uses it for initializing vectors and matrices of arbitrary size. I.e. This seems really silly when you could instead just do C++ code:
|
|
#
?
Sep 16, 2016 23:58
|
|
|
Ralith posted:This seems really silly when you could instead just do I suspect it predates C++11 initializer lists.
|
|
#
?
Sep 17, 2016 00:18
|
|
|
eth0.n posted:I suspect it predates C++11 initializer lists.
|
|
#
?
Sep 17, 2016 22:44
|
|
|
Xarn posted:x87 strikes again Can confirm, I just read a few of the floating point posts and they're really interesting. Pro click.
|
|
#
?
Sep 17, 2016 23:23
|
|
|
Ralith posted:It's got a fixed number of arguments, that could just as well be a regular constructor. Besides, the question's not really about Eigen in particular. It's a typedef to a Matrix template which can support an arbitrary number of rows and columns, either static sized, or dynamically resizable. Implementing that as a constructor would not be feasible pre-C++11. Even if it did individual implementations of most-common matrix types, it would still be worth including the "<<" syntax for the static-sized ones for consistency with the dynamic-sized ones. Besides, the real horrors of operator overloading are &&, ||, and unary &. operator&() is a pain mostly because it creates a need for std::addressof(), even though it's obscure enough hardly anyone actually overloads unary &. On the other hand, && and || seem like they should be overloaded just as casually as +, but then doing so breaks short-circuit evaluation. This one I've actually seen in the wild, from quite experienced C++ coders...
|
|
#
?
Sep 17, 2016 23:28
|
|
|
Ralith posted:This seems really silly when you could instead just do Surely you mean C++ code:
|
|
#
?
Sep 18, 2016 19:58
|
|
|
xtal posted:Surely you mean
|
|
#
?
Sep 19, 2016 00:06
|
|
|
Ralith posted:How's that work? Commas are whitespace so commas and spaces are redundant. A map in Clojure is {key value key value}.
|
|
#
?
Sep 19, 2016 01:02
|
|
|
xtal posted:Commas are whitespace so commas and spaces are redundant. A map in Clojure is {key value key value}. Since when are commas whitespace?
|
|
#
?
Sep 19, 2016 01:43
|
|
|
xtal posted:Commas are whitespace so commas and spaces are redundant. A map in Clojure is {key value key value}. Huh? Aren't we taking about C++? Standard for Programming Language C++ posted:8.5.4 List-initialization [dcl.init.list]
|
|
#
?
Sep 19, 2016 01:57
|
|
|
xtal posted:Commas are whitespace so commas and spaces are redundant. A map in Clojure is {key value key value}. Nice. In APLs, whitespace is also used as a list separator. K treats newlines and semicolons identically. The general form of a list is (x;y;z) (etc.), so a matrix is typically written as simply code:
|
|
#
?
Sep 19, 2016 03:53
|
|
|
|
| # ? May 16, 2024 07:48 |
|
|
xtal posted:Commas are whitespace so commas and spaces are redundant. A map in Clojure is {key value key value}.  I like Lisp and Haskell syntax more than most people, but in C++ you work with what you've got.
|
|
#
?
Sep 19, 2016 04:19
|
|