2,573 reputation
21529
bio website
location
age
visits member for 3 years, 11 months
seen 14 hours ago

Jul
24
comment Is immutability very worthwhile when there is no concurrency?
@Doval: It doesn't disprove that, but it does prove what (doesn't) works in practice doesn't necessarily match what you expect to (not) work in theory.
Jul
24
comment Is immutability very worthwhile when there is no concurrency?
@Giorgio: Could you give me a ballpark number then? How many times faster were you? 10x?
Jul
24
comment Is immutability very worthwhile when there is no concurrency?
@Doval: In theory yeah, but I'm saying in practice much of the code you're using directly or indirectly every day is mutable and it's already scaled, so that argument isn't so convincing.
Jul
24
comment Is immutability very worthwhile when there is no concurrency?
@Doval: I love that you actually tried asymptotic time complexity analysis. Your analysis is wrong though. An O(N) algorithm can (must?) easily become O(N log N) with immutability. It is no longer O(N) like you claim, and a log N factor is not something that you can gloss over like that. (Think of an algorithm like BWT; how can you possibly claim it will stay efficient with immutable arrays?)
Jul
24
comment Is immutability very worthwhile when there is no concurrency?
@Giorgio: Er, I didn't ask if it was "noticeable", I asked if it was "even remotely in the same ballpark". A 20% increase is "noticeable" but not even remotely in the same ballpark.
Jul
24
comment Is immutability very worthwhile when there is no concurrency?
@KChaloux: Use const in C++ and you'll realize the same thing: most variables can be const.
Jul
24
comment Is immutability very worthwhile when there is no concurrency?
@itsbruce: I don't see how it can "not scale"? Like I said, people have been doing this for decades, so obviously, this does scale. It might be a bit more work sometimes, but it's not like people can't do it. And mutability brings about efficiency too.
Jul
24
comment Is immutability very worthwhile when there is no concurrency?
@Doval: Yeah, that's my point. I would turn down a 20% improvement. Why? Because immutability doesn't come for free -- there's a price tag: it makes the code more inefficient. So there has to be a justification for you to pay that cost, and a 20% productivity improvement isn't a justification for me to make my code slower.
Jul
24
comment Is immutability very worthwhile when there is no concurrency?
@Doval: I don't really feel like the kind of productivity gained by moving from assembly to C or C++ is even remotely in the same ballpark as the kind gained from going from mutable to immutable types; do you?
Jul
24
comment Is immutability very worthwhile when there is no concurrency?
@Den: I don't see why you can't have your cake and eat it too. Why not just take C++'s approach? The types are mutable, but you can receive parameters of those types by copy or by a read-only reference. That gives you immutability of the caller's variables without tying your hand behind your back for all instances of that type.
Jul
24
comment Is immutability very worthwhile when there is no concurrency?
"it's very hard to know"... is it really that hard? People have managed to do this for decades now.
Jul
22
comment When I test out the difference in time between shifting and multiplying in C, there is no difference. Why?
@quickly_now: They can be converted into combinations of shifts and additions/subtractions.
Jul
16
comment Is it a good idea to “#define me (*this)”?
@BЈовић: Pages? It's not a question of thinking "long", it's a question of not having to think at all. When this-> is there--and you have a habit of putting it in there whenever it's possible--then you are immediately 100% certain the variable is an instance field. It requires no thinking whatsoever, so it's not distracting. But when that's not the case, then you have to think. Whether that's 5 seconds or 30 seconds is a different issue, the point is it still takes up unnecessary mental resources regardless, without any benefit in terms of development speed either as I mentioned earlier.
Jul
16
comment Is it a good idea to “#define me (*this)”?
Not to mention that using this actually helps you write your code faster because the IDE can display a drop-down listing all the member variables, from which you can easily select a member without typing most of its name at all. So it's not even good from a coding efficiency standpoint.
Jul
16
comment Is it a good idea to “#define me (*this)”?
@BЈовић: How else are you supposed to distinguish between member and local variables? Either you change the naming convention, or you use this->. I don't mean for the compiler's sake, I mean for the sanity of the next poor programmer who has to read your code. If you don't write this-> then you're going to waste the people's valuable time when they go hunting for the scope of the variable. That's at least 5 seconds of thinking that could be turned into 1 second, with 4 more left to spend on more important things. Multiplied by the number of times your code has to be read.
Jul
16
comment Is it a good idea to “#define me (*this)”?
"Using this-> everywhere is just plain stupid" uh, no, it's pretty smart. I could just as well argue not doing so is stupid. It lets you avoid screwing with instance variable names by prefixing them with m_ or _ or whatever just because you're too lazy to type this->, making the code that much more readable.
Jul
15
comment Is it a good idea to “#define me (*this)”?
@LokiAstari: Nothing in the question even remotely hints at the OP wondering whether this-> "is necessary". In fact, the OP says he is using this-> in spite of the fact that it's not necessary. The question is about whether me. should be used instead of this->, which this answer doesn't actually answer.
Jul
14
comment Is it a good idea to “#define me (*this)”?
@JanHudec: Lowercase is for system-specific extensions? Could you post a reference to the part of the C++ standard that indicates this?
Jul
14
comment Is it a good idea to “#define me (*this)”?
"In C++, you almost never have to write this" that's a totally unrelated convention to the question. Some people (like me) prefer to write this to explicitly make it clear that the variable is not local to the method. The question here is about whether the macro me should exist, not whether this is something that should be used.
Jul
10
comment Why is software OS specific?
@MSalters: Not quite -- if you (and Marcin) read my very first comment, you will see I was already aware of that and mentioned it before either of you did. However, that's not what Marcin is saying, even though maybe that's what he thinks he's saying. He's making a stronger claim: that there exists a "POSIX binary format" that Windows can execute, for which I'm asking him to provide a reference, because (correct me if I'm wrong) I'm fairly sure that even the "POSIX" executables in Windows in fact use the PE file format, not some "POSIX binary format" (if such a thing even exists).