|
I like git commit . 
|
#
?
Jun 18, 2013 00:07
|
|
|
|
| # ? May 16, 2024 22:56 |
|
|
Zorn posted:Never program a computer. To be faired, the if statement thing isn't even my fault; I was taught that in an Intro C course offered in the computer engineering track at my university. So I assumed that was right even if it's not You're kind of being a dick, though
|
|
#
?
Jun 18, 2013 11:33
|
|
|
The first thing you learn when you leave the sacred grounds of the computer engineering area of your local university, is throw everything they taught you about programming out the window.
|
|
#
?
Jun 18, 2013 13:07
|
|
|
Yep. I don't know if it's like this at other universities, but at ours, the computer engineering department is always trying to one-up CS by saying "Look, we're hardware AAAAAND software!" and offer duplicate classes for just about everything, except that their core programming sequence is C++ instead of Java. This doesn't change the fact that the students who come out of those classes and take CS electives can't program worth a drat. CEs can't teach proper programming or software design in my experience, and they have the tendency to (try to) prematurely optimize because they're thinking about the hardware too much instead of trusting the compiler.
|
|
#
?
Jun 18, 2013 16:32
|
|
|
Dirk Pitt posted:The first thing you learn when you leave the sacred grounds of the computer engineering area of your local university, is throw everything they taught you about programming out the window. A friend of mine is taking a data structures course in computer engineering, taught using c++. They apparently aren't allowed to use subscript notation (as in a[x]), ever. They must use *(a + x) always. I have no idea why.
|
|
#
?
Jun 18, 2013 16:33
|
|
|
Probably the same reason CS profs love to teach the intro sequence in Haskell.
|
|
#
?
Jun 18, 2013 16:43
|
|
|
HappyHippo posted:A friend of mine is taking a data structures course in computer engineering, taught using c++. They apparently aren't allowed to use subscript notation (as in a[x]), ever. They must use *(a + x) always. I have no idea why. Just a guess, but maybe the professor feels that makes the "offset from memory address" idea of array access more clear for computer engineers?
|
|
#
?
Jun 18, 2013 17:25
|
|
|
HappyHippo posted:A friend of mine is taking a data structures course in computer engineering, taught using c++. They apparently aren't allowed to use subscript notation (as in a[x]), ever. They must use *(a + x) always. I have no idea why. I like to think that this involves some smart rear end student and operator overloading.
|
|
#
?
Jun 18, 2013 17:50
|
|
|
And today I learned that c++ lets you overload the array operator.
|
|
#
?
Jun 18, 2013 18:02
|
|
|
hobbesmaster posted:I like to think that this involves some smart rear end student and operator overloading. You can also overload the dereference operator. I hope the same hypothetical smart rear end thought to do that, too.
|
|
#
?
Jun 18, 2013 18:02
|
|
|
I use git add -p and also git add . (for new files). I should probably do git add -p . for those.
|
|
#
?
Jun 18, 2013 18:04
|
|
|
JawnV6 posted:And today I learned that c++ lets you overload the array operator. That's how you have datastructures like sets and maps and hash tables in the standard library that work with [].
|
|
#
?
Jun 18, 2013 18:18
|
|
|
contrapants posted:You can also overload the dereference operator. I hope the same hypothetical smart rear end thought to do that, too. That's used reasonably all over the place (iterators, shared_ptr, etc.). The real horror is overriding operator && or operator ,.
|
|
#
?
Jun 18, 2013 18:19
|
|
|
There are use-cases for all of the operators that are able to be overloaded. Use them when they make sense and don't use them when they don't.
|
|
#
?
Jun 18, 2013 18:24
|
|
|
The comma operator? I wanna hear this.
|
|
#
?
Jun 18, 2013 18:46
|
|
|
GrumpyDoctor posted:The comma operator? I wanna hear this. Boost.Phoenix uses them as expression/statement separators. They are also used in several libraries (I.E. Eigen) as a means to do initialization of objects. These are both relatively popular libraries with criticisms [of these particular aspects] being primarily philosophical.
|
|
#
?
Jun 18, 2013 18:52
|
|
|
Has anybody ever been able to use the non-overloaded comma operator?
|
|
#
?
Jun 18, 2013 18:53
|
|
|
Suspicious Dish posted:Has anybody ever been able to use the non-overloaded comma operator? The only time I think I've ever used the actual comma operator is as a part of for, either for initializing multiple objects, or for the step operation when I want more than one thing to be done. Edit: Also inside of weird macros where I want the expanded result to be an expression.
|
|
#
?
Jun 18, 2013 19:00
|
|
|
Suspicious Dish posted:Has anybody ever been able to use the non-overloaded comma operator?
|
|
#
?
Jun 18, 2013 19:03
|
|
|
Flobbster posted:CEs can't teach proper programming or software design in my experience, and they have the tendency to (try to) prematurely optimize because they're thinking about the hardware too much instead of trusting the compiler.
|
|
#
?
Jun 18, 2013 21:42
|
|
|
Presto posted:Speaking as a CE, compilers over the years have given me plenty of reasons not to trust them. We have a problem right now at work where some code that has worked perfectly everywhere for years now fails when built at one particular site with one particular version of g++. But if you turn off the optimization flag it works OK. "The compiler has a bug where it generates faulty code in this case" does not lead to "The compiler can't be trusted ever so I should try to optimize my code by hand instead of letting the compiler apply decades of experience and heuristics". I've had to deal with my share of gcc bugs myself, but there's no excuse for the poor quality code I've seen in code from CEs (not you specifically, of course) where it was obvious that they thought they needed to do the compiler's job for it. vvv also this Flobbster fucked around with this message at 22:25 on Jun 18, 2013 |
|
#
?
Jun 18, 2013 22:02
|
|
|
Presto posted:Speaking as a CE, compilers over the years have given me plenty of reasons not to trust them. We have a problem right now at work where some code that has worked perfectly everywhere for years now fails when built at one particular site with one particular version of g++. But if you turn off the optimization flag it works OK.  There is another reason why your code might fail mysteriously under different optimizations.
|
|
#
?
Jun 18, 2013 22:04
|
|
|
Presto posted:Speaking as a CE, compilers over the years have given me plenty of reasons not to trust them. We have a problem right now at work where some code that has worked perfectly everywhere for years now fails when built at one particular site with one particular version of g++. But if you turn off the optimization flag it works OK. Sounds like you have some ~undefined behavior~
|
|
#
?
Jun 18, 2013 22:22
|
|
|
b0lt posted:Sounds like you have some ~fun-defined behavior~ I prefer to think of it like this 
|
|
#
?
Jun 18, 2013 23:45
|
|
|
For real, if your code doesn't work and the first explanation you think of is "the compiler/operating system/CPU has a bug", you're almost certainly wrong, at least for mainstream compilers (embedded compilers are a whole 'nother story). Even if you are right, the correct response is to come up with a minimal test case that reproduces the bug (you'll often find the bug in your code in the process of creating this) and reporting it - "the compiler compiles this wrong" is rare enough that compiler developers are pretty good at working on a fix when it does happen. I say this as someone who's seen their fair share of compiler, OS and CPU bugs.
|
|
#
?
Jun 19, 2013 00:48
|
|
|
b0lt posted:Sounds like you have some ~undefined behavior~ The good news is that it's 3rd-party code, so if it's broken I take no responsibility.  But I'm still pretty sure it's g++ loving up again. I've had problems with the optimizer before in an older version where it decided a comparison was not needed when it quite obviously was. (And no, it wasn't ~undefined behavior~.)
|
|
#
?
Jun 19, 2013 01:19
|
|
|
Presto posted:The good news is that it's 3rd-party code, so if it's broken I take no responsibility. It's not unheard of for an optimization to screw up, though if it's eliminating a comparison I have to ask -- was the code dealing with threads? There are some "bad" idioms dealing with threads that are still probably commonly used but that inadvertently rely on undefined behavior (specifically people relying on volatile to do more than what the standard actually says). A comparison not being performed when a programmer expects that it would could definitely be a symptom of this.
|
|
#
?
Jun 19, 2013 01:31
|
|
|
I would be very surprised if the optimizer thought that it could remove a comparison when it couldn't - the only time I can think of when it would do that is if the value of something was changing, yet the compiler thought it was constant (at last in that section). So bad threading or an aliasing violation, both of which are firmly in Undefined Behavior Land.
|
|
#
?
Jun 19, 2013 02:17
|
|
|
Oh, and another option is that if you dereference something before checking that it's null, the optimizer can and will remove the null check. Even if the dereference itself is removed by a later optimization pass, it's still fine to remove the null check, because you were in Undefined Behavior Land as soon as that null pointer deference would have happened in the program-as-written.
|
|
#
?
Jun 19, 2013 03:44
|
|
|
Or signed overflow.
|
|
#
?
Jun 19, 2013 03:46
|
|
|
Or somebody forgot to return and the optimization changed what happened to be on the stack.
|
|
#
?
Jun 19, 2013 04:15
|
|
|
That Turkey Story posted:It's not unheard of for an optimization to screw up, though if it's eliminating a comparison I have to ask -- was the code dealing with threads? There are some "bad" idioms dealing with threads that are still probably commonly used but that inadvertently rely on undefined behavior (specifically people relying on volatile to do more than what the standard actually says). A comparison not being performed when a programmer expects that it would could definitely be a symptom of this. Nope, this was something very simple in a single-threaded app. It was 1. compute new_sum; 2. if (new_sum != old_sum) { do stuff } else { never mind } The 'if' was getting totally ignored. If you put any additional reference to new_sum in the code, like printing it out, then it worked correctly again. I ended up making new_sum volatile. I think the next gcc revision fixed it (this was somewhere early in the 4.x series I believe) and later the code got rewritten anyway. I've been unlucky with this kind of stuff throughout my career. One time we had code on a DSP that was failing inexplicably, and we chased our tails for a good while until one of the developers figured out a reproducible case, which got sent to our vendor, who pared the case down further to a couple machine instructions and sent it to the chip manufacturer, who said, "Oh yeah, that's a bug in the processor". This is why I'm old and bitter and distrust all software and hardware. 
|
|
#
?
Jun 19, 2013 18:59
|
|
|
Sounds like undefined behavior somewhere in the code that generates new_sum. Compiler vendors often make their optimizers less aggressive if lots of people complain that their code uses undefined behavior and the optimization makes it do something they don't want. It doesn't actually solve the problem, and that undefined behavior is still there waiting to break something else later, but I guess it shuts up the complainers.
|
|
#
?
Jun 20, 2013 00:36
|
|
|
It's kindof pointless to speculate. Compiler bugs do happen, as do hardware bugs. The fact that it disappeared in a later release doesn't tell you anything about whether it was a compiler bug; the number of things that regularly change between compiler releases and which can perturb whether a bug is exposed is pretty drat high. All we know is that it was somehow dependent on being kept live in memory vs. a register.
|
|
#
?
Jun 20, 2013 01:17
|
|
|
We can still post about stupid code here right? This is a rather common "pattern" in one of the homebrew programs we use. code:
|
|
#
?
Jun 20, 2013 03:27
|
|
|
Except in list context, where it will return an empty list instead.
|
|
#
?
Jun 20, 2013 11:48
|
|
|
True, but drat near everything in that codebase uses list/hash references so it's always called in scalar context.
|
|
#
?
Jun 20, 2013 14:27
|
|
|
Dirk Pitt posted:The first thing you learn when you leave the sacred grounds of the computer engineering area of your local university, is throw everything they taught you about programming out the window.
|
|
#
?
Jun 20, 2013 16:15
|
|
|
Probably the same reason people continually run into CS majors and autodidacts that haven't learned. Good grief, there are people out there who use linked lists "for performance", people who push object oriented design patterns for Bash scripting, etc. Lunacy is an equal-opportunity employer.
|
|
#
?
Jun 20, 2013 16:22
|
|
|
|
| # ? May 16, 2024 22:56 |
|
|
Otto Skorzeny posted:Probably the same reason people continually run into CS majors and autodidacts that haven't learned. Good grief, there are people out there who use linked lists "for performance", people who push object oriented design patterns for Bash scripting, etc. Lunacy is an equal-opportunity employer. No, people with my background are superior to all others because they're like me. Deus Rex fucked around with this message at 22:09 on Jun 20, 2013 |
|
#
?
Jun 20, 2013 22:07
|
|
