|
Xarn posted:Using ternary operator to assign to a bit field you say? I think I have a new piece of code to scare people with. Yeah, it’s good for screwing with people who proclaim the “expression has type int &” heresy.
|
# ? Sep 9, 2018 02:20 |
|
|
# ? Jun 6, 2024 19:12 |
|
I tested it and MSVC doesn't handle it either, and the error message is really bad.
|
# ? Sep 9, 2018 06:05 |
|
rjmccall posted:Assigning to a conditional operator is home to a lovely bit of still-unimplemented behavior in Clang, by the way: note that the operands can be any sort of l-value, including a bit-field. I swear this is the last time I am bringing this up -> is it actually part of standard c++? I did some research and I am not sure it is.
|
# ? Sep 9, 2018 20:08 |
|
Xarn posted:I swear this is the last time I am bringing this up -> is it actually part of standard c++? I did some research and I am not sure it is. ”C++ [expr.cond]p5” posted:If the second and third operands are glvalues of the same value category and have the same type, the result is of that type and value category and it is a bit-field if the second or the third operand is a bit-field, or if both are bit-fields.
|
# ? Sep 9, 2018 23:41 |
|
Xarn posted:I swear this is the last time I am bringing this up -> is it actually part of standard c++? I did some research and I am not sure it is. Yes
|
# ? Sep 10, 2018 00:07 |
|
ratbert90 posted:1) That’s C. I'm just imagining the "This is fine" dog but instead of flames it's all C++ horrors. Of course, he still melts in the end.
|
# ? Sep 10, 2018 15:21 |
|
Thermopyle posted:That reminds me of the GPS fleet tracker I use on my one company vehicle for my one employee. (not a web dev or technology company)
|
# ? Sep 10, 2018 15:33 |
|
It works™
|
# ? Sep 12, 2018 14:06 |
|
https://www.youtube.com/watch?v=eyH4aXlB1Js
|
# ? Sep 12, 2018 18:31 |
|
Xarn posted:Using ternary operator to assign to a bit field you say? I think I have a new piece of code to scare people with.
|
# ? Sep 12, 2018 20:42 |
|
Munkeymon posted:I'm just imagining the "This is fine" dog but instead of flames it's all C++ horrors. Of course, he still melts in the end. Except a Ternary is just a compact if else statement, so it really is just fine.
|
# ? Sep 14, 2018 11:57 |
|
ratbert90 posted:Except a Ternary is just a compact if else statement, so it really is just fine. i thought it was an expression. (ie it has a value)
|
# ? Sep 14, 2018 12:56 |
|
ratbert90 posted:Except a Ternary is just a compact if else statement, so it really is just fine. A compact with THE DEVIL!
|
# ? Sep 14, 2018 13:08 |
|
Shinku ABOOKEN posted:i thought it was an expression. (ie it has a value) Yeah, you can't put an if else left of the equals sign.
|
# ? Sep 14, 2018 13:11 |
|
Uhhhhh but how would I do pluralization without ternaries? Ever thing about THAT?
|
# ? Sep 14, 2018 13:35 |
|
ratbert90 posted:Except a Ternary is just a compact if else statement, so it really is just fine. Er... What?
|
# ? Sep 14, 2018 13:36 |
|
a hot gujju bhabhi posted:Er... What? Doesn’t: return (a == 1) ? 20 : 30 Evaluate to: code:
If it doesn’t, I have a good decades worth of code to go fix...
|
# ? Sep 14, 2018 13:47 |
|
ratbert90 posted:Doesn’t: They're not equivalent. Anything can happen in an if else block. code:
A ternary has to Ola fucked around with this message at 14:02 on Sep 14, 2018 |
# ? Sep 14, 2018 13:59 |
|
Ola posted:They're not equivalent. Anything can happen in an if else block. Right? A ternary is a if else A if else isn’t necessarily a ternary.
|
# ? Sep 14, 2018 14:03 |
|
Ola posted:They're not equivalent. Anything can happen in an if else block. The point is not that they’re the same thing, it’s that the ternary operator is always trivially replaceable with an if/else
|
# ? Sep 14, 2018 14:04 |
|
ratbert90 posted:Except a Ternary is just a compact if else statement, so it really is just fine. Played around a bit on codepad and I guess it's not that bad because it does at least make sure the types are sane. It's the assignment of a number to a char in the original example that's probably throwing me because I'm now used to languages where char isn't a funny way to say byte
|
# ? Sep 14, 2018 14:23 |
|
Munkeymon posted:Played around a bit on codepad and I guess it's not that bad because it does at least make sure the types are sane. It's the assignment of a number to a char in the original example that's probably throwing me because I'm now used to languages where char isn't a funny way to say byte Which is funny because when I go to a higher level language, I have to get used to char not being a byte. Edit; The original value has 3 ints? code:
This is equivalent to: code:
FlapYoJacks fucked around with this message at 14:38 on Sep 14, 2018 |
# ? Sep 14, 2018 14:32 |
|
Oh dang I forgot about the tweet that started the whole thing and was looking at b0lt's example Still one of those things I'd reject in a review because You're Being Too Dang Clever.
|
# ? Sep 14, 2018 14:45 |
|
ratbert90 posted:Right? Right. A ternary always evaluates to something, an if/else is just a conditional and two paths of code. If you return something there, it's the parent function that is returning, not the if/else block. You can also use a method call to assign, if it's a reference: code:
|
# ? Sep 14, 2018 14:58 |
|
Phrasing it like "a ternary evaluates to an if-statement" makes it sound like it's a macro or syntactic sugar. Their semantics overlap but they aren't equivalent. Maybe this is a time to bust out the word isomorphic.
|
# ? Sep 14, 2018 15:07 |
|
For extra compactness it should be possible to write something along the lines ofcode:
code:
|
# ? Sep 14, 2018 15:21 |
|
That code seems like a problem in its own right
|
# ? Sep 14, 2018 15:27 |
|
Also, we're talking about the conditional operator, which is a ternary operator, but not all ternary operators are the conditional operator. (But I can't think of another ternary operator that I use ever.)
|
# ? Sep 14, 2018 15:27 |
|
If you wanted a horrific conditional operator, there's this:code:
|
# ? Sep 14, 2018 16:03 |
|
Ola posted:Why? I don't know. Is it good? I...don't know. Why? These kinds of lvalue expressions are basically what makes the typical iterator range copy look like this code:
operator++ (post) increments the variable, then returns the original value, which is then passed to operator*, which returns a reference so it can be used as an lvalue, and its copy (or move) assignment operator can be invoked (which also returns an lvalue, so assignments can be chained). Is it good? Yeah it's pretty good. Consider an index operator where you want to be able to modify the thing at the index, so all you have to do is return a different reference based on the input to the operator function. I don't see why being able to assign to a ternary expression that returns an lvalue is particularly baffling
|
# ? Sep 14, 2018 16:32 |
It's been a while since I looked into it, so this might have changed in C++17 or something, but IIRC there are places where you can use a ternary but can not trivially replace it with an if-else because the syntax demands it evaluates to an expression. For example I believe you can use constexpr ternaries in template parameters, but not if-else.
|
|
# ? Sep 14, 2018 17:44 |
|
Mooey Cow posted:
I didn't mean to sound like I was passing judgement on C++. I'm very new to it, and it was baffling to me to see an expression on the left hand side of an assignment. I think I might fall into a trap where I try to shoehorn it in somewhere.
|
# ? Sep 14, 2018 17:57 |
|
1337JiveTurkey posted:For extra compactness it should be possible to write something along the lines of I'll allow it on the grounds that it is amusingly symmetrical, which pleases me.
|
# ? Sep 14, 2018 21:40 |
|
That is kinda useful. I can't wait to break a few brains with that one.
|
# ? Sep 14, 2018 21:50 |
|
Just found out that if you want to declare a jagged array in C#, and you want to explicitly size the outer dimension of the array, you have to do it the wrong way around. I don't know what's going on there. i.e. you have to write "var myArray = new Thing[10][];" instead of "var myArray = new Thing[][10];"
|
# ? Sep 14, 2018 22:49 |
|
That looks right to me? It matches the order in which you'd index into the array. "I have an array of 10 elements, each of which has variable size" should be written as arr[10][]. arr[][10] should be for when you say "I have a variable number of arrays each of which has length 10."
|
# ? Sep 14, 2018 23:08 |
|
TooMuchAbstraction posted:That looks right to me? It matches the order in which you'd index into the array. "I have an array of 10 elements, each of which has variable size" should be written as arr[10][]. arr[][10] should be for when you say "I have a variable number of arrays each of which has length 10." if int[10] is an array of 10 ints, then int[][10] should be an array of 10 int[]s
|
# ? Sep 14, 2018 23:16 |
|
TooMuchAbstraction posted:That looks right to me? It matches the order in which you'd index into the array. "I have an array of 10 elements, each of which has variable size" should be written as arr[10][]. arr[][10] should be for when you say "I have a variable number of arrays each of which has length 10." When you stick a "[]" on the end of the variable type, that means 'I want an array of the thing to the left of the "[]"'. When you stick a "[n]" on the end, that means 'I want an array, length n, of the thing to the left of the "[n]"'. Going from Thing to Thing[] to Thing[][n] is an iterative process; I start with a Thing, then I say actually what I want is an array of Things, then I say actually what I really want is an array, length n, of arrays of Things. It's built up by repeatedly sticking "[]" or "[n]" on the right-hand end of the type. That's why the outer dimension ought to be the one with the "n" - it's the dimension added last of all - and it comes as a surprise to me that the language doesn't have it work like that. Yes, a logical consequence of the arrangement I advocate for is that the order at declaration would have to be the opposite of the order when indexing. It doesn't matter.
|
# ? Sep 14, 2018 23:18 |
|
redleader posted:I'll allow it on the grounds that it is amusingly symmetrical, which pleases me. Really the biggest justification I can see for it is based on Bill Lear's old airplane design adage "If it looks good, it will fly good."
|
# ? Sep 14, 2018 23:37 |
|
|
# ? Jun 6, 2024 19:12 |
|
This is a fundamental tension with nested arrays: 1. It's really nice to just have a simple type-structuring rule like "an array has a bound and an element type" instead of embracing the extra complexity of directly supporting multi-dimensional arrays. 2. It's really nice to use the postfix square-bracket syntax for accessing an array element. 3. Assuming you've settled on using the square-bracket expression syntax, it's really nice to use the same syntax for writing the bound of an array type. It's a natural analogy that reads well and has no problems for non-nested arrays, which are massively more common. 4. In the expression syntax, array[i] accesses the ith element of array. 4a. Therefore, basic decomposition suggests that array[i][j] accesses the jth element of the ith element of array. The major index is written first. 5. In the type syntax, SomeType[N] is an N-bounded array of SomeType. 5a. The obvious recursive grammar rule for this is that SomeType can be any type, including an array type. But this leads to int[M][N] meaning an M-bounded array of N-bounded arrays of int. The major bound is written last, which is backwards from the expression syntax. 5b. This is why C has a crazy definition-follows-use rule where you can have arbitrary nested type-structure that has to be read inside-out, so int (*fn())[N] is a nullary function returning a pointer to an N-array of int. This gives us what we want: in int[M][N], the major bound is written first. 5c. Java and C# don't have arbitrary nested type-structure; they just have arrays. Furthermore, IIRC arrays are always unbounded outside of new expressions, meaning that types always look like int[][], meaning that the parse order is irrelevant. The languages therefore just have a special rule for new expressions which reverses the bounds, so that the major index is written first. The only reasonable alternatives are to either (a) abandon (1) and provide multi-dimensional arrays, thus heavily discouraging nested arrays (but not technically eliminating the problem), or (b) abandon (3) and use a syntax that places the bound to the left, so that you get e.g. [M x [N x int]]. rjmccall fucked around with this message at 23:41 on Sep 14, 2018 |
# ? Sep 14, 2018 23:38 |