3 ms·

The great thing about const is that if you don't like it you can pretty much ignore it. The only time it might be necessary to deal with it is if you are usin

by stoney 16y ago

The great thing about const is that if you don't like it you can pretty much ignore it. The only time it might be necessary to deal with it is if you are using a library that returns const objects. If you do like const (which I do) then you can put it in pretty much everywhere, except if you are dealing with a library that isn't "const correct", but then a bit of type casting will save the day. That's a big advantage of lots of the C++ features - if you don't like them you can often just ignore them.

billswift 16y ago
That's usually considered a drawback of C++; it's a huge, complicated language and everybody tends to use a different subset for their own work.
- ethaneade 16y ago
  The same can be said of English. And in both cases, there are sundry tasks of limited scope where the language is probably not the most natural choice (e.g. operas). However, when one is simultaneously dealing with multiple, disparate domains/constraints simultaneously (e.g. real-time computer vision), such a language might be the least unattractive option thanks to its inclusiveness.
  - jbooth 16y ago
    Except program don't express natural language, and in fact the required context awareness of natural language is exactly what kills many languages and frameworks. I shouldn't have to know all of these things to edit some stranger's code, it should be obvious how it works.
coliveira 16y ago
That's not really true. If you need to work with libraries that use const everywhere you have only two options: * Use const everywhere * Use casts everywhere The same thing happens if you use const and your libraries don't...
jimbokun 16y ago
"If you do like const (which I do) then you can put it in pretty much everywhere" In retrospect, it might have been better to have a keyword for things that can change. This goes equally for Java and "final". Making immutability the default and mutability opt-in makes for fewer bugs and more reliable programs. Arguably, this is what Clojure does where you have functional, immutable constructs by default with ways to declare things that can change (refs, etc.).
- deleted 16y ago
  [deleted]
- ramchip 16y ago
  const by default may not be a bad idea, but immutability of structures/objects in C++ sounds like it would be a huge performance hit to me. I've used an image processing library (CIMG) which lets you do things like `img = img1 * 2 + img2 * 0.5`, instead of editing the image in-place. It's pretty, but with regular 800x600 images the performance was around 2 orders of magnitude below a simple for loop... it made a lot of extra copying and allocation instead of mutating the image. The thing is, this kind of code isn't an exception in the C++ world. C++ is made for problems where performance matters: image processing, compilers, browsers... immutability works for Clojure, but Clojure is a lot slower than C++. It's more of an "enterprise software" language.

by stoney 16y ago

billswift 16y ago

That's usually considered a drawback of C++; it's a huge, complicated language and everybody tends to use a different subset for their own work.

ethaneade 16y ago
The same can be said of English. And in both cases, there are sundry tasks of limited scope where the language is probably not the most natural choice (e.g. operas). However, when one is simultaneously dealing with multiple, disparate domains/constraints simultaneously (e.g. real-time computer vision), such a language might be the least unattractive option thanks to its inclusiveness.
- jbooth 16y ago
  Except program don't express natural language, and in fact the required context awareness of natural language is exactly what kills many languages and frameworks. I shouldn't have to know all of these things to edit some stranger's code, it should be obvious how it works.

coliveira 16y ago

That's not really true. If you need to work with libraries that use const everywhere you have only two options: * Use const everywhere * Use casts everywhere The same thing happens if you use const and your libraries don't...

jimbokun 16y ago

"If you do like const (which I do) then you can put it in pretty much everywhere" In retrospect, it might have been better to have a keyword for things that can change. This goes equally for Java and "final". Making immutability the default and mutability opt-in makes for fewer bugs and more reliable programs. Arguably, this is what Clojure does where you have functional, immutable constructs by default with ways to declare things that can change (refs, etc.).

deleted 16y ago
[deleted]
ramchip 16y ago
const by default may not be a bad idea, but immutability of structures/objects in C++ sounds like it would be a huge performance hit to me. I've used an image processing library (CIMG) which lets you do things like `img = img1 * 2 + img2 * 0.5`, instead of editing the image in-place. It's pretty, but with regular 800x600 images the performance was around 2 orders of magnitude below a simple for loop... it made a lot of extra copying and allocation instead of mutating the image. The thing is, this kind of code isn't an exception in the C++ world. C++ is made for problems where performance matters: image processing, compilers, browsers... immutability works for Clojure, but Clojure is a lot slower than C++. It's more of an "enterprise software" language.