Oppinion on 'least priviledge', 'const correctness', etc.

Discussion in 'Java' started by Alexander, Jul 20, 2010.

  1. Alexander

    Alexander Guest

    Wherever I find something on the topic, these are considered positive.
    Why? I only find it time-consuming. Could you respond (preferably on
    comp.programming) why it can be considered as such, but motivated,
    that is without responses like "it's good software engineering
    practice", "it's just better", etc... I'm a learner, and I think now
    is the best time to shape out practices and priorities.
    Alexander, Jul 20, 2010
    #1
    1. Advertising

  2. Alexander

    Jorgen Grahn Guest

    Const correctness (was Re: Oppinion on 'least priviledge', 'constcorrectness', etc.)

    ["Followup-To:" header set to comp.lang.c++. Neither the Java nor the
    comp.programming people want to read about const correctness, I'm sure.]

    On Tue, 2010-07-20, Alexander wrote:
    > Wherever I find something on the topic, these are considered positive.


    Only these two, or do you include a number of other things under
    "etc", unknown to us?

    > Why? I only find it time-consuming. Could you respond (preferably on
    > comp.programming) why it can be considered as such, but motivated,
    > that is without responses like "it's good software engineering
    > practice", "it's just better", etc...


    Const specifically: a language feature I really like.

    I guess you can say that it adds another dimension to the type system.
    It's good for the same reasons that the rest of the static typing is
    good. E.g. that we can have have Foo* and Bar*, not just void*.

    You make more information about your intentions explicit, in the code,
    for the benefit for the reader. And the compiler can check it.

    > I'm a learner, and I think now
    > is the best time to shape out practices and priorities.


    Yes. For const, you don't really have a choice -- if you refuse to use
    it, you'll be in constant conflict with other programmers working on
    the code.

    There are still, I think, old C programmers who reject const, but I
    never heard of a C++ programmer who did.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Jul 20, 2010
    #2
    1. Advertising

  3. Alexander

    Öö Tiib Guest

    On 20 juuli, 16:00, Alexander <> wrote:
    > Wherever I find something on the topic, these are considered positive.
    > Why? I only find it time-consuming.


    I have heard them named as "principle of minimal privilege" and "const
    correctness".

    Illustrative example: Imagine that you play classical click-around,
    find-items, combine-and-use-them-to-proceed adventure game. You need
    to use 5 items for winning it but the game throws at you 80 red
    herring items too. Some of the items may lead you to wrong, useless
    places or into inescapable situations (that game does not indicate any
    way). Fun to click and try to combine them all and to use everywhere
    and then to reload earlier saves and to retry? No. Most like it be
    better if game does not give red herrings to them at all or gave lot
    less than possible. So "more" is not always "better".

    Same is with access restrictions in computer science. Anyone writing
    module or class interfaces should take good care about it being
    sufficient and complete for its purpose. It is done for protecting the
    users of interface from need to know about various red herrings and
    wrong places. Best is to give to user *only* such information and
    resources and access that they need for legitimate usage purposes.
    Also it is important to give them *everything* that they need for
    legitimate usage purposes, otherwise they start to ask questions like
    "is this game winnable at all". ;)

    Of course it is initially time consuming for interface designer to
    carefully arrange that access but it saves lot of time of the innocent
    users of the interface. Also it gets easier when you have habit to do
    it. If you write it all by yourself you may initially think that you
    are the user yourself (and so not innocent) and so it does not apply
    and habit is not needed. Wrong. Let me display why you are wrong there
    too.

    Why you write it at all? Usually it is done for fame and/or big bucks.
    What is goal-reaching indicator? Popularity and/or commercial success.
    Have you faced (however limited) popularity or commercial success? It
    is terrible thing. The list of bugs and feature requests may grow to
    hundreds or thousands despite how good effort you put up. You will see
    it is hard, when you are lucky enough.

    Lets say you manage alone? During maintenance your product grows over
    100 000 lines of code easily in less than 5 years heroic maintenance.
    100 000 lines is about the spot where you start to forget things why
    you wrote that or that. Finally you are player yourself with full of
    red herrings puzzle. You need to maintain it and hate it at same time.
    You can not possibly manage alone.

    Now comes last point. Writing interfaces lousily is bad habit. Others
    do not like it. It is very hard to find allies. Very precious few can
    navigate in 100 000 lines of one-man spaghetti. None of these precious
    few lacks better offers or opportunities than to join you. Also it is
    very hard for you to get rid of your bad habits (you have worked by
    them for 5 years say).

    > Could you respond (preferably on
    > comp.programming) why it can be considered as such, but motivated,
    > that is without responses like "it's good software engineering
    > practice", "it's just better", etc... I'm a learner, and I think now
    > is the best time to shape out practices and priorities.


    Why you cross posted to several groups? Post into every group
    individually if you need different opinions. There are lot more
    languages. Each is different. For example java does not have language
    elements dedicated for const correctness at all i think. However ...
    general reasons why principle of minimal privileges is good to follow
    are lot older than C++ or java. I think most good developers have
    habit to limit access to their modules internals in one way or other.
    Öö Tiib, Jul 20, 2010
    #3
  4. Alexander

    Lew Guest

    Öö Tiib wrote:
    > Why you cross posted to several groups? Post into every group
    > individually if you need different opinions. There are lot more
    >


    Wrong. You describe multi-posting, one of the cardinal sins of
    Usenet. Cross-posting is much better.

    Do not multi-post. Ever.

    Cross-post only when you must, to the least number of relevant groups.

    > languages. Each is different. For example java [sic] does not have language
    > elements dedicated for const correctness at all i [sic] think. However ....


    Wrong again, sort of. Java has 'final' which is sort of similar to
    'const'.

    --
    Lew
    Lew, Jul 20, 2010
    #4
  5. Alexander

    Lew Guest

    Re: Const correctness (was Re: Oppinion on 'least priviledge', 'constcorrectness', etc.)

    On Jul 20, 10:18 am, Jorgen Grahn <> wrote:
    > ["Followup-To:" header set to comp.lang.c++.  Neither the Java nor the
    > comp.programming people want to read about const correctness, I'm sure.]
    >


    Don't be so sure. Java has 'final', which isn't exactly the same as
    'const' but is similar and applies similarly to the "principle of
    least privilege" and the safety thereof.

    Both 'const' and 'final' express the intention to prevent change to a
    variable's value.

    --
    Lew
    Lew, Jul 20, 2010
    #5
  6. Alexander

    Öö Tiib Guest

    On 20 juuli, 20:28, Lew <> wrote:
    > Öö Tiib wrote:
    > > Why you cross posted to several groups? Post into every group
    > > individually if you need different opinions. There are lot more

    >
    > Wrong.  You describe multi-posting, one of the cardinal sins of
    > Usenet.  Cross-posting is much better.
    >
    > Do not multi-post.  Ever.
    >
    > Cross-post only when you must, to the least number of relevant groups.


    OK. Thanks for correcting. I do neither anyway unless replying.
    comp.lang.c++ and comp.lang.c++.moderated keep me usually entertained
    enough.

    > > languages. Each is different. For example java [sic] does not have language
    > > elements dedicated for const correctness at all i [sic] think. However ....

    >
    > Wrong again, sort of.  Java has 'final' which is sort of similar to
    > 'const'.


    I have not seen much usage of it nor heard much talk about 'final-
    correctness' in friendly java teams. C devs talk about const a lot
    more. Perhaps that 'final' sort of misses some useful perks of
    'const'.
    Öö Tiib, Jul 20, 2010
    #6
  7. Re: Const correctness (was Re: Oppinion on 'least priviledge', 'constcorrectness', etc.)

    On Jul 20, 10:54 am, Peter Duniho <>
    wrote:
    > I'm a big fan of language constructs that constrain the code in certain
    > ways, from data/implementation hiding/encapsulation to things like
    > "const", "final", "readonly" (C#), etc. that help convey and,
    > especially, enforce intent.  But these kinds of things really need to be
    > done in a way that doesn't allow the programmer to just wish the
    > restrictions away any time they like.  Otherwise, it's too tempting to
    > do just that when the alternative is to spend hours or days updating the
    > code to use the restriction properly.


    Unfortunately (or fortunately ?), this is C++, and the motto is we'll
    give you tools to help you not shoot yourself in the foot, perhaps
    even make them the default, but if you're dead set on shooting
    yourself in the foot, C++ will allow you to do so.
    Joshua Maurice, Jul 20, 2010
    #7
  8. Alexander

    Jonathan Lee Guest

    On Jul 20, 2:04 pm, Öö Tiib <> wrote:
    > On 20 juuli, 20:28, Lew <> wrote:
    > > Wrong again, sort of.  Java has 'final' which is sort of similar to
    > > 'const'.

    >
    > I have not seen much usage of it nor heard much talk about 'final-
    > correctness' in friendly java teams. C devs talk about const a lot
    > more. Perhaps that 'final' sort of misses some useful perks of
    > 'const'.


    I've never heard of an equivalent of "const correctness" in Java,
    but I also don't use it very much. Though, a quick Google search
    seems to support the idea that "final" is really nothing like
    const-correctness:

    http://en.wikipedia.org/wiki/Final_(Java)
    http://stackoverflow.com/questions/1370042/why-is-const-correctness-specific-to-c
    http://mannu.livejournal.com/131085.html
    http://en.wikipedia.org/wiki/Const-correctness

    --Jonathan
    Jonathan Lee, Jul 20, 2010
    #8
  9. Alexander

    Öö Tiib Guest

    Re: Const correctness (was Re: Oppinion on 'least priviledge', 'constcorrectness', etc.)

    On 20 juuli, 20:54, Peter Duniho <> wrote:
    > Lew wrote:
    >
    > I'm a big fan of language constructs that constrain the code in certain
    > ways, from data/implementation hiding/encapsulation to things like
    > "const", "final", "readonly" (C#), etc. that help convey and,
    > especially, enforce intent.  But these kinds of things really need to be
    > done in a way that doesn't allow the programmer to just wish the
    > restrictions away any time they like.  Otherwise, it's too tempting to
    > do just that when the alternative is to spend hours or days updating the
    > code to use the restriction properly.


    C++ is yes, relatively anarchistic language so teams usually agree
    upon policies that they follow and do not expect software (compiler)
    to tell to human how to program it. There are always ways to
    circumvent the language protection mechanics. If i remember correctly
    then calling private member functions in C# is even easier than in C+
    +. If something evil gets too annoyingly tempting then build
    gallons ... few public executions later it is less tempting.
    Öö Tiib, Jul 20, 2010
    #9
  10. Alexander

    Daniel Pitts Guest

    Re: Const correctness (was Re: Oppinion on 'least priviledge', 'constcorrectness', etc.)

    On 7/20/2010 10:33 AM, Lew wrote:
    > On Jul 20, 10:18 am, Jorgen Grahn<> wrote:
    >> ["Followup-To:" header set to comp.lang.c++. Neither the Java nor the
    >> comp.programming people want to read about const correctness, I'm sure.]
    >>

    >
    > Don't be so sure. Java has 'final', which isn't exactly the same as
    > 'const' but is similar and applies similarly to the "principle of
    > least privilege" and the safety thereof.
    >
    > Both 'const' and 'final' express the intention to prevent change to a
    > variable's value.

    Almost. const expresses that a specific object should be unchanged, but
    final (unfortunately) only refers to primitive/reference immutability.
    It is definitely a feature I miss in Java. Especially since immutable
    objects are guaranteed to be thread-safe.

    --
    Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
    Daniel Pitts, Jul 20, 2010
    #10
  11. Jonathan Lee wrote:
    > On Jul 20, 2:04 pm, Öö Tiib <> wrote:
    >> On 20 juuli, 20:28, Lew <> wrote:
    >>> Wrong again, sort of. Java has 'final' which is sort of similar to
    >>> 'const'.

    >> I have not seen much usage of it nor heard much talk about 'final-
    >> correctness' in friendly java teams. C devs talk about const a lot
    >> more. Perhaps that 'final' sort of misses some useful perks of
    >> 'const'.

    >
    > I've never heard of an equivalent of "const correctness" in Java,
    > but I also don't use it very much. Though, a quick Google search
    > seems to support the idea that "final" is really nothing like
    > const-correctness:


    The equivalent in Java to "const-Correctness", culturally, is "Favor
    Immutability". The same sort of conversation taking place here is one
    that follows a request to explain the benefits of "Favor Immutability".

    I'm new here, and I humbly submit the above observation.

    --
    Alan Gutierrez - - http://twitter.com/bigeasy
    Alan Gutierrez, Jul 20, 2010
    #11
  12. Alexander

    Lew Guest

    Lew wrote:
    >>>> Wrong again, sort of. Java has 'final' which is sort of similar to
    >>>> 'const'.


    Öö Tiib wrote:
    >>> I have not seen much usage of it nor heard much talk about 'final-
    >>> correctness' in friendly java [sic] teams. C devs talk about const a lot


    That's because that's not what we call it. Alan gives you the correct term.

    >>> more. Perhaps that 'final' sort of misses some useful perks of
    >>> 'const'.


    Or perhaps Java's 'final' doesn't need those "perks" because of the other
    differences between the languages.

    Jonathan Lee wrote:
    >> I've never heard of an equivalent of "const correctness" in Java,


    Therefore it doesn't exist? Anyway, the claim isn't that there's an exact
    equivalent to "const correctness" but that Java's 'final' has similarities to
    C++'s 'const', and relative to the Java language fills the same ecological niche.

    >> but I also don't use it very much. Though, a quick Google search
    >> seems to support the idea that "final" is really nothing like
    >> const-correctness:


    Again, that's not the claim. The claim is that 'final' is similar for Java to
    what 'const' is in C++, in certain ways.

    Alan Gutierrez wrote:
    > The equivalent in Java to "const-Correctness", culturally, is "Favor
    > Immutability". The same sort of conversation taking place here is one
    > that follows a request to explain the benefits of "Favor Immutability".
    >
    > I'm new here, and I humbly submit the above observation.


    Everyone here seems to think that Java 'final' is just nothing a-'tall like
    C[++] 'const'. They are, of course, mistaken.

    Both keywords signal to the compiler that the item so marked cannot be altered.

    Since Java supports only pointers and primitives and not value-object
    variables, the semantics of its 'final' are bound to differ from those of
    C++'s 'const'. C++ and Java are different languages. But in terms of
    enforcing "least privilege" (this conversation's avowed topic) and
    immutability, the two constructs serve cognate purposes.

    --
    Lew
    Lew, Jul 21, 2010
    #12
  13. Alexander

    Jonathan Lee Guest

    On Jul 20, 9:00 pm, Lew <> wrote:
    > Jonathan Lee wrote:
    > >> I've never heard of an equivalent of "const correctness" in Java,

    > Therefore it doesn't exist?


    Er.. no. In fact, I even went out of my way to say that I wasn't
    experienced in Java so people wouldn't draw that conclusion.

    >  Anyway, the claim isn't that there's an exact equivalent to
    > "const correctness" but that Java's 'final' has similarities to
    > C++'s 'const', and relative to the Java language fills the same
    > ecological niche.


    The OP was asking about const correctness, not the const keyword.
    As for the "final" and "const" keywords being similar... that's
    interesting, but a distinct topic.

    > Everyone here seems to think that Java 'final' is just nothing a-'tall like
    > C[++] 'const'.  They are, of course, mistaken.


    We don't think that.

    --Jonathan
    Jonathan Lee, Jul 21, 2010
    #13
  14. Alexander

    Esmond Pitt Guest

    Re: Const correctness (was Re: Oppinion on 'least priviledge', 'constcorrectness', etc.)

    On 21/07/2010 3:33 AM, Lew wrote:
    > Don't be so sure. Java has 'final', which isn't exactly the same as
    > 'const' but is similar


    It's not really all that similar. As Jorgen says, C++ 'const' becomes
    part of the type system, and it's so type-safe that if you add/remove
    const to/from a method argument declaration the program will stop
    linking. Java doesn't have that property at all. Callers don't benefit
    from 'final' parameters in any way, only the author of the method ...
    which is why I've always found 'final' method parameters pretty
    pointless unless there's an inner class.
    Esmond Pitt, Jul 21, 2010
    #14
  15. Alexander

    Daniel Guest

    On Jul 20, 2:14 pm, Jonathan Lee <> wrote:
    > On Jul 20, 2:04 pm, Öö Tiib <> wrote:
    >
    > I've never heard of an equivalent of "const correctness" in Java,
    > but I also don't use it very much.


    Neither Java or C++ has any way of marking a function as "pure". In
    Java, the convention is more to use immutable interfaces, so the issue
    doesn't arise as much. In C++, const restricts you to calling a
    subset of member functions on the object, but there are no guarantees
    that that subset doesn't also change state, there are restrictions,
    but only to the first layer of the data.

    -- Daniel
    Daniel, Jul 21, 2010
    #15
  16. Alexander

    Lew Guest

    Re: Const correctness (was Re: Oppinion on 'least priviledge', 'constcorrectness', etc.)

    Lew wrote:
    >> Don't be so sure. Java has 'final', which isn't exactly the same as
    >> 'const' but is similar


    Esmond Pitt wrote:
    > It's not really all that similar. As Jorgen says, C++ 'const' becomes
    > part of the type system, and it's so type-safe that if you add/remove
    > const to/from a method argument declaration the program will stop
    > linking. Java doesn't have that property at all. Callers don't benefit
    > from 'final' parameters in any way, only the author of the method ...
    > which is why I've always found 'final' method parameters pretty
    > pointless unless there's an inner class.


    Java method parameters are pass-by-value, so of course 'final' will work
    differently on them. Java doesn't need to make 'final' part of the method
    signature because changes to the parameters are not visible to the caller
    anyway. The only thing left for 'final' to do is what it does, to make it
    impossible for the called routine to change what the argument points to. So
    of course "callers don't benefit" from them - but the similarity is there
    insofar as it prevents change within the method.

    As for changing the values in structures to which the argument points, that
    isn't prevented in C++ by making a pointer 'const', only by making the thing
    to which it points 'const', something that Java does and for which it uses -
    guess what? - 'final'. It does a similar thing, just in a different way.

    No one is saying that 'final' and 'const' are the same. If you think that's
    my point, you haven't been reading my posts. The languages themselves differ,
    so there's no way they can be the same, like in the case of method arguments.
    But they are similar, insofar as both prevent change to the variable to
    which they're attached.

    I do agree that 'final' for Java method arguments is not the most useful use
    case. It's far more handy for class members and local variables.

    --
    Lew
    Lew, Jul 21, 2010
    #16
  17. Alexander

    Lew Guest

    Daniel wrote:
    > Neither Java or C++ has any way of marking a function as "pure". In
    > Java, the convention is more to use immutable interfaces, so the issue


    Immutable class instances. Interfaces in Java can't enforce immutability.

    > doesn't arise as much. In C++, const restricts you to calling a
    > subset of member functions on the object, but there are no guarantees
    > that that subset doesn't also change state, there are restrictions,
    > but only to the first layer of the data.


    --
    Lew
    Lew, Jul 21, 2010
    #17
  18. Alexander

    Lew Guest

    Re: Const correctness (was Re: Oppinion on 'least priviledge', 'constcorrectness', etc.)

    On 07/21/2010 12:06 AM, Peter Duniho wrote:
    > Java's "final" _could_ have applied to the type, as it does in C++. But
    > it doesn't. This is what everyone is trying to point out to you. The
    > fact that Java doesn't have pass-by-reference in no way makes "const"
    > and "final" equivalent. Even ignoring pass-by-reference in C++, "const"
    > still is a stronger guarantee than "final" in Java.


    I am not saying that they're equivalent. I've pointed out before that I'm not
    saying that they're equivalent. Straw man.

    Lew wrote:
    >> As for changing the values in structures to which the argument points,
    >> that isn't prevented in C++ by making a pointer 'const', only by
    >> making the thing to which it points 'const', something that Java does
    >> and for which it uses - guess what? - 'final'. It does a similar
    >> thing, just in a different way.


    Peter wrote:
    > No, it doesn't. Java doesn't have any way to prevent values in
    > structures to which the argument points from being modified. Not in the
    > parameter declaration, that is.


    That's the point of saying that Java does it "in a different way".

    > You can, of course, make the fields in a class "final", preventing them
    > from being modified. But that would prevent them from being modified
    > _ever_. Applying "const" to a type in a parameter list in C++ only
    > prevents modification _in that method_. The object can still be modified
    > later elsewhere.


    Thank you for elucidating some of the differences.

    I've said that 'final' is "sort of similar" to 'const'. I've never said that
    they're the same. I've disavowed saying that they're the same. Of course
    they're different!

    Lew wrote and Peter cited:
    >> No one is saying that 'final' and 'const' are the same. If you think
    >> that's my point, you haven't been reading my posts. The languages


    See?

    >> themselves differ, so there's no way they can be the same, like in the
    >> case of method arguments. But they are similar, insofar as both
    >> prevent change to the variable to which they're attached.


    > Many of your posts have seemed to be claiming that "const" in C++ is
    > similar enough to "final" so as there to not be any point in discussing


    Seeming is in the eye of the beholder. I've pointed out many times that they
    are only "sort of similar". I've explicitly disavowed saying that they're
    equivalent. I don't know how the hell you read into that that I said they're
    is no point in discussing what's different. I don't disagree with the points
    you make, only with you claiming that I said something different from what I
    actually said, then trying to pin that on me.

    > what's different. C++'s "const" is actually quite a bit different from
    > "final" in Java, sharing only one small aspect of its behavior with
    > Java's "final".


    OK.

    --
    Lew
    Lew, Jul 21, 2010
    #18
  19. Alexander

    Öö Tiib Guest

    On 21 juuli, 04:00, Lew <> wrote:
    > Öö Tiib wrote:
    > >>> I have not seen much usage of it nor heard much talk about 'final-
    > >>> correctness' in friendly java [sic] teams. C devs talk about const a lot

    >
    > That's because that's not what we call it.  Alan gives you the correct term.


    Seems that "Favor Immutability" is not that popular idiom. Google for
    "Const Correctness" 39,000 results, "Favor Immutability" 1,080. It is
    more about how to create immutable classes, while in C++ you do not
    need to (but may) make special classes for constant instances.

    > >>> more. Perhaps that 'final' sort of misses some useful perks of
    > >>> 'const'.

    >
    > Or perhaps Java's 'final' doesn't need those "perks" because of the other
    > differences between the languages.


    Huh? But these are tools, language features. Not mandatory to use
    always but most like them since these really help. Perhaps that
    'final' is simply considered enough by authors of java. There are fine
    languages like Python with even less features supporting
    immutability.

    > >> but I also don't use it very much. Though, a quick Google search
    > >> seems to support the idea that "final" is really nothing like
    > >> const-correctness:

    >
    > Again, that's not the claim.  The claim is that 'final' is similar for Java to
    > what 'const' is in C++, in certain ways.


    Ok. Making primitive immutable with 'final' is yes in certain ways
    same. It is mostly perhaps used for naming single constant values, not
    write protection? You can also make a pointer immutable with 'final'.
    That is sometimes done in C++ too but usually one uses a reference for
    it ('const' is not needed at all).

    There similarities end. 'final' about member function means that it
    can not be further overridden and 'final' about class means that it
    can not be derived from. These are entirely different purposes than
    'const' has. It feels like 'final' is for some sort of global and meta-
    immutability when 'const' is more for selectively write-protecting
    (possibly mutable) data.

    > Everyone here seems to think that Java 'final' is just nothing a-'tall like
    > C[++] 'const'.  They are, of course, mistaken.


    'const' yes, feels more oriented for not giving (and taking) unneeded
    privileges locally. Major feature of 'const' is to declare that code
    will not modify the object pointed to by a pointer through that
    pointer. Other feature is to declare that function does not modify its
    parameter and third is to show that member function does not modify
    the object. How you do any of these with 'final'?

    > Both keywords signal to the compiler that the item so marked cannot be altered.
    >
    > Since Java supports only pointers and primitives and not value-object
    > variables, the semantics of its 'final' are bound to differ from those of
    > C++'s 'const'.  C++ and Java are different languages.  But in terms of
    > enforcing "least privilege" (this conversation's avowed topic) and
    > immutability, the two constructs serve cognate purposes.


    I am not saying that different feature set makes one language better
    than other, just that 'final's purpose feels different and such
    comparison feels stretched out, nothing to do. You can have immutable
    view of mutable data by writing special interface in java, but the
    cost is higher than with 'const' and what it all has to do with
    'final'?
    Öö Tiib, Jul 21, 2010
    #19
  20. Re: Const correctness (was Re: Oppinion on 'least priviledge', 'constcorrectness', etc.)

    On 20 Jul., Christian Hackl wrote:
    > Maybe I'm just lucky, but I cannot even remember the last time I
    > actually had to use const_cast because of some broken (or legacy) C++ or
    > C API. How often do you really encounter this problem?


    Quite seldom. Most often these are in-house projects where the co-
    workers offers a header for some wrapper Dll that has been written in
    MatLab or IDL, and the generated headers file are not const-correct.
    Since they don't know C++ I most often correct those headers by hand.

    The Win32 API is not always const-correct (see VerQueryValue,
    CreatePenIndirect, or TOOLTIPTEXT).

    MS MFC uses some macros like RUNTIME_CLASS which contain const_casts.
    If I cannot use such macros because my classes are inside a namespace
    or are generated from a template, I have to replace the macro by hand,
    which introduces const-casts in my code.

    I generate some wrapper classes for COM components from the raw .idl
    file, and import the type library that is generated from the .idl
    file. Since type libraries "eat away" all const-modifiers, I'll have
    to const-cast a lot in my wrapper classes (so that at least C++ users
    have a const-correct API).

    In some measurement and automation APIs you'll find non-const correct
    functions (for example Roper Scientific's PVCAM API).

    Those are only the examples that I found when I searched for
    const_cast through all my projects. There may be a lot more cases
    where I just used a plain C-cast.

    Regards,
    Stuart
    Stuart Redmann, Jul 21, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. NWx
    Replies:
    4
    Views:
    2,960
    Kevin Spencer
    Feb 19, 2004
  2. Helmut Jarausch

    BaseHTTPServer and priviledge separation?

    Helmut Jarausch, Jun 25, 2005, in forum: Python
    Replies:
    1
    Views:
    309
    Lee Harr
    Jun 25, 2005
  3. Javier
    Replies:
    2
    Views:
    559
    James Kanze
    Sep 4, 2007
  4. fungus
    Replies:
    13
    Views:
    886
    fungus
    Oct 31, 2008
  5. Alexander
    Replies:
    41
    Views:
    1,003
    Jorgen Grahn
    Jul 25, 2010
Loading...

Share This Page