operator[] difference of const and non-const

I was reading a tutorial which have a header including operator[], of course an overload of the latter, having a version const and non-const, respectively:

Code:

---

T const & operator[] (iteratorClassName<T> const &) const;
T & operator[] (iteratorClassName<T> const &);

---

This got me wondering what's the real difference between the 2.

... whoah! I'm getting too tired. Anyway I'll do a follow-up poast but my question will remain the same, is there a difference in the code between the 2 beside something no-so-important like one display an error cerr << "wrong use..." and the other make a log clog << "successful...". IMHO, such case would be for where one of the 2 (const or non-const) shouldn't be used.

Is there some cases where the content of the operator[] would be different at is core, a major difference (again between const and non-const) ?
Than
ks and it's ok if you don't understand, don't worry I'll come back to this.

Compare:

Code:

---

void foo(iteratorClassName<int>& bar)
{
        auto n = bar[0];
        n = 5;
        std::cout << bar[0]; // Prints 5
}

void foo(const iteratorClassName<int>& bar)
{
        std::cout << bar[0]; // Prints whatever is stored in bar[0]
}

---

The first operator allows us to get the value at index n.
The second operator allows us to modify the value at index n, but won't work if the object is const (because the operator isn't a const function).

With the first operator, the first function won't compile.
Without the second operator, the second function won't compile.

O_o

->

Without the first operator, the second function won't compile.
Without the second operator, the first function won't compile.

Soma

In addition to Elysia's example, any time an iterator is created as the return value of a function, that iterator is const, because it's a temporary, and must use the const version of the operator.

Quote:

---

Originally Posted by King Mir

any time an iterator is created as the return value of a function, that iterator is const, because it's a temporary, and must use the const version of the operator.

---

I don't think so. If the return type is not qualified as const, I would expect the non-const version of the operator to be invoked.

EDIT:
Oh wait, the iterator in question is the argument. In that case, I don't think it matters: what matters is whether the object itself is const in the given context.

Quote:

---

In addition to Elysia's example, any time an iterator is created as the return value of a function, that iterator is const, because it's a temporary, and must use the const version of the operator.

---

I'm not entirely sure what you are saying, but for the sake of completeness, member functions including operators can be invoked on temporaries in that context, return value from functions, regardless of "constness".

Soma

Code:

---

#include <iostream>

struct STest
{
    void doSomething()
    {
        std::cout << "not a constant method" << '\n';
    }
};

STest GetTester()
{
    return(STest());
}

int main()
{
    GetTester().doSomething();
    return(0);
}

---

Here is a fun example:

Code:

---

#include <iostream>

class foo
{
public:
        const foo& operator [] (int) const { std::cout << "Const operator called.\n"; return *this; }
        foo& operator [] (int) { std::cout << "Non-const operator called.\n"; return *this; }
};

int main()
{
        foo bar1;
        const foo& bar2 = bar1;
        bar1[0];
        bar2[0];
        (bar1[0])[0];
        (bar2[0])[0];
}

---

And output:
Non-const operator called.
Const operator called.
Non-const operator called.
Non-const operator called.
Const operator called.
Const operator called.

Quote:

---

Here is a fun example:

---

That serves only to partially explain how the compiler can be preferential, but it can work with only the `const' method.

Remove the `const' reference stuff and the `const' method and the code will also compile.

You need both examples to get the full picture.

Soma

Example 2:

Code:

---

#include <iostream>

class foo
{
public:
        const foo& operator [] (int) const { std::cout << "Const operator called.\n"; return *this; }
};

int main()
{
        foo bar1;
        const foo& bar2 = bar1;
        bar1[0];
        bar2[0];
        (bar1[0])[0];
        (bar2[0])[0];
}

---

Output:
Const operator called.
Const operator called.
Const operator called.
Const operator called.
Const operator called.
Const operator called.

And example 3 won't compile:

Code:

---

#include <iostream>

class foo
{
public:
        foo& operator [] (int) { std::cout << "Non-const operator called.\n"; return *this; }
};

int main()
{
        foo bar1;
        const foo& bar2 = bar1;
        bar1[0];
        bar2[0]; // <--- error here (object is const)
        (bar1[0])[0];
        (bar2[0])[0]; // <--- error here (object is const)
}

---

^_^

Well, leaving the error in place also works.

And now there is a reasonably complete picture for the "OP" to peruse if he is still interested.

Soma

Elysia is feeling generous today :D

Quote:

---

Originally Posted by Elysia

Here is a fun example:
[code]#include <iostream>

class foo
{
public:
const foo& operator [] (int) const { std::cout << "Const operator called.\n"; return *this; }
foo& operator [] (int) { std::cout << "Non-const operator called.\n"; return *this; }
};

[...]

---

This is exactly my point. The difference between the blocks of the 2 operator[] (const & non-const) are not-so-important.

Are there cases where the difference is important? That the block content are fundamentally different, not just superficial differences? I have a corrected project (by a teacher) where there are 2 version of T & ClassX<T>::operator[] (int) (const & non-const) which have exactly the same block containing

Code:

---

assert(/* validation 1 */);
assert(/* validation 2 */);
// ...

return memberT[parameterInt];

---

I have a hard time thinking of an example but it could be something like.. haha I spent 15-20 minutes trying to come up with an example, I just couldn't do it.

Quote:

---

Originally Posted by laserlight

I don't think so. If the return type is not qualified as const, I would expect the non-const version of the operator to be invoked.

EDIT:
Oh wait, the iterator in question is the argument. In that case, I don't think it matters: what matters is whether the object itself is const in the given context.

---

A temporary binds to a const reference, never a non-const reference. And a function that returns an iterator creates a temporary. It's also possible to create a temporary with a constructor call or cast.

Here's an example.

Code:

---

class Obj{
};

void bar(Obj &){}
//void bar (Obj const &){}

Obj foo(){
  return Obj();
}

int main(){
  bar(foo());//error if no const operator.
  return 0;
}

---

Member function lookup is a little different; you can call a non const method on a temporary.

Quote:

---

Originally Posted by DynV

Are there cases where the difference is important?

---

Yes, but it depends on your design.
One operator is called with the intention that it is allowed to modify your object's state.
The other one is called with the intention that it isn't allowed to modify your object's state.
When taking that into account when designing your class, you may end up with different code for the paths.
I can't think of a spontaneous example, though.

Quote:

---

Originally Posted by King Mir

A temporary binds to a const reference, never a non-const reference.

---

Well, it holds as long as you do not think of rvalue references as references, at least.

Quote:

---

Originally Posted by Elysia

Well, it holds as long as you do not think of rvalue references as references, at least.

---

Yeah, still getting used to those being in the language.

Quote:

---

And a function that returns an iterator creates a temporary.

---

I'm fairly certain that you misunderstood what laserlight said.

The standard containers return different types (conceptually) of iterators by value depending on whether or not the container is constant in the given situation.

Quote:

---

That the block content are fundamentally different, not just superficial differences?

---

O_o

Being "const correct" isn't a superficial difference.

Soma

Quote:

---

Originally Posted by phantomotap

Quote:

---

Originally Posted by DynV

That the block content are fundamentally different, not just superficial differences?

---

O_o

Being "const correct" isn't a superficial difference.

---

This was the important part

Quote:

---

block content

---

perhaps the compiled versions are (much) different but certainly not the blocks as far as what I mentioned in #12.

The const version of the operator is read only. It's a semantic difference. The const operator will be used unless it specifically cannot be used -- like when the object is an lvalue -- and your constant objects will still be able to use the operator without violating their constness. It should be pretty easy, if you know what the subscript operator does, to imagine a bad line of code that changes an object that isn't supposed to be changed. Writing two operators varying in constness will prevent such code from being compiled.

Quote:

---

Originally Posted by whiteflags

It should be pretty easy, if you know what the subscript operator does, to imagine a bad line of code that changes an object that isn't supposed to be changed. Writing two operators varying in constness will prevent such code from being compiled.

---

Sorry but I don't get this. :|

Would someone please just make me an example (or give URLs which someone with no prior knowledge of const & non-const difference would understand), or a few if there's different types, where const & non-const version of operator[] would have different block content. It would be most helpful.

O_o

Dude, just stop trying to fight it!

The code between the braces is irrelevant; the issue of having both overloads is about "const correctness".

The code may or may not be different depending on how the facility is intended to behave, but that's a meaningless focus of your confusion because these differences would still be about making the code "const correct".

Consider the often implementation of the standard containers (as I've already referenced); the two overloads return either completely different or semantically (conceptually) different types. The code in the blocks may still look identical but because the functions are returning different types they behave differently. That is all that matters. The one overload returns an iterator which is itself mutable and which can be used to mutate the contents of the container. The other overload (the `const' one) returns an iterator which is itself mutable but which can not be used to mutate the contents of the container.

You are focusing on a non-issue; having both overloads is about being "const correct". If the code needs to be different to make that possible it certainly can be different. If the code doesn't need to be different to make that possible it certainly does not have to be different.

Soma

Quote:

---

Originally Posted by phantomotap

You are focusing on a non-issue

---

Yeah I'm just like that and I'm still focused on it, just like my OP mentioned:

Quote:

---

Originally Posted by DynV

my question will remain the same, is there a difference in the code between the 2 beside something no-so-important like one display an error [...] and the other make a log

---

I know what you're saying about const correctness, that the const version should be the most important version and only to add the non-const version if needed but I'm still wondering what kind of code could be different ; not the signature part, the block part. Because for now having 2 versions of the same block, in my disarranged mind, only has use if 1 of the 2 should be forbidden, ie:

Code:

---

/* ..*/ operator[](/* ..*/) {
    assert(false);
}

---

I am of the opinion that you should implement both versions, because you need them.

If you didn't have both versions, how wrong would this program be?

Code:

---

#include <vector>
#include <iostream>

int main()
{
    const std::vector<int> foo(10, 42); // create ten 42s
    foo[1] = 40;                        // can't change them!

    std::vector<int> bar(10, 42);
    bar[1] = 40;                  // except when they're not const
}

---

It is extremely likely that both versions of the subscript operator are apparently the same. This is because the subscript operator has a simple meaning.

Quote:

---

Originally Posted by King Mir

A temporary binds to a const reference, never a non-const reference. And a function that returns an iterator creates a temporary.

---

And the parameter of both overloads of operator[] is of const reference type, hence what you are talking about does not matter.

Quote:

---

Originally Posted by King Mir

Member function lookup is a little different; you can call a non const method on a temporary.

---

Exactly.

EDIT:

Quote:

---

Originally Posted by whiteflags

If you didn't have both versions, how wrong would this program be?

---

Also, if your container is designed to be immutable, then you might provide only the const overload. As you should have seen earlier in this thread, it would still work when called with a non-const container.

Quote:

---

Originally Posted by whiteflags

t is extremely likely that both versions of the subscript operator are apparently the same. This is because the subscript operator has a simple meaning.

---

I will assume this is what I was looking for ; that it's extremely unlikely that what my OP suggested (block of const & non-const operator[] be different) happen. So I might was well put that in my mind for when I get very advanced in C++.

Thanks again :)

Although I'm not so happy about you because after watching your signature earlier, I spent 30 minutes listening to chiptune. ;)

Just remember though, that some classes will intentionally only have say the const version.
e.g. if you had a class that wrapped a read-only connection to a database.
So it's not about whether they have the same behaviour or not, it's about saying which of the two pieces of functionality is your class meant to provide. Unfortunately for those classes that intend to expose both, there can be some code duplication. It's usually small though.

Quote:

---

Originally Posted by iMalc

Just remember though, that some classes will intentionally only have say the const version.
e.g. if you had a class that wrapped a read-only connection to a database.

---

That's what I understood from the concept right before creating this thread but the more examples, the merrier. :D

I was about to forget: I did search on the topic before creating a new thread but the search algorithm isn't what I'm used to :confused: ; there was ~1 related topic per result page, as seen in the attached image.

I'm not really sure how you searched. The search algorithm is actually pretty good. But you have to use advance search if you want to control where you search. In my experience, search by default looks for the keywords in the whole post, in all of the open forums. If you want to search by title in the C++ Programming forum or other things like that, go to advanced.

I used advanced, as the search criteria show on top of the image. I also use Search Titles Only, either one of us had luck going for or against, I'm missing something unusual (I'm not a stranger to such search) or the algorithm changed.

The forum software does change rather constantly. The search method that works best for me is in advanced like you've been using. I like to search single content type, too, because that makes sense to me. I haven't really figured out what multiple content type searches are supposed to do, unless you want to search in, like, visitor messages. And who cares about that. Anyway, the default is for multiple content type searches so you will either need to figure out the form on that page, or switch to single content type. From there you only need to figure out the form to search successfully. Maybe you've already done this

If I repeat your search on the single content type tab, I get this: http://cboard.cprogramming.com/searc...earchid=499297 -- four pages of operator overloading threads. If you continue to have significant trouble, you could always pm a moderator.

Quote:

---

Originally Posted by whiteflags

I get this: http://cboard.cprogramming.com/searc...earchid=499297

---

nice link

Quote:

---

vBulletin Message

Sorry - no matches. Please try some different terms.

---

:D

Don't care. Searches can't be permalinked.

Hmm! It was a joke. I hope it wasn't appropriate.