Can I be sure than a const reference is updated when modified by another entity?

I have a class Foo having the rights to read an instance of class Bar, but doesn't have the rights to modify it. In the same time, the instance of Bar could be modified by other elements.

For the moment, I implement it by this way:

class Foo

{

  private:

    const Bar& bar; // Foo can't modify it

  public:

    Foo(const Bar& bar_) : bar(bar_) {}

    void doSomthing() { this->bar.printData(); }

};

And it could be used like this:

Bar bar;

Foo foo(bar);

bar.update(); // This modify the instance of Bar

foo.doSomthing(); // This use the reference to (modified) bar

My question is: With this implementation, can I be sure than the compiler doesn't use a non updated copy of bar even if the reference is declared as const ?

If no, how can I do that ?

Note: I don't use C++11 for compatibility reason

edited Jan 10 at 7:50

asked Jan 2 at 8:50

Caduchon

2,47111656

3

Short answer yes. Your code is fine and works as you expect.

– Jarod42
Jan 2 at 9:01

3

I would expect any sane compiler to produce the correct code here. Out of curiosity, where does your doubt stem from?

– StoryTeller
Jan 2 at 9:10

@StoryTeller: because if I said to the compiler that somthing is constant, it could be logical that the compiler decide to create a copy in a closer memory than RAM (like the cache of the processor) whithout having to check if it was updated.

– Caduchon
Jan 2 at 10:04

But you didn't tell it that. The object is not declared const.

– StoryTeller
Jan 2 at 10:05

2

@Caduchon Here, const means logically const, not physically const. The compiler has no way to know what logically const means, so it can't make any assumptions. For example, a logically-const object might count how many times it is compared. That doesn't change its logical value. There is no safe assumption the compiler can make about logically-const objects.

– David Schwartz
Jan 2 at 10:12

|
show 2 more comments

I have a class Foo having the rights to read an instance of class Bar, but doesn't have the rights to modify it. In the same time, the instance of Bar could be modified by other elements.

For the moment, I implement it by this way:

class Foo

{

  private:

    const Bar& bar; // Foo can't modify it

  public:

    Foo(const Bar& bar_) : bar(bar_) {}

    void doSomthing() { this->bar.printData(); }

};

And it could be used like this:

Bar bar;

Foo foo(bar);

bar.update(); // This modify the instance of Bar

foo.doSomthing(); // This use the reference to (modified) bar

My question is: With this implementation, can I be sure than the compiler doesn't use a non updated copy of bar even if the reference is declared as const ?

If no, how can I do that ?

Note: I don't use C++11 for compatibility reason

edited Jan 10 at 7:50

asked Jan 2 at 8:50

Caduchon

2,47111656

3

Short answer yes. Your code is fine and works as you expect.

– Jarod42
Jan 2 at 9:01

3

I would expect any sane compiler to produce the correct code here. Out of curiosity, where does your doubt stem from?

– StoryTeller
Jan 2 at 9:10

@StoryTeller: because if I said to the compiler that somthing is constant, it could be logical that the compiler decide to create a copy in a closer memory than RAM (like the cache of the processor) whithout having to check if it was updated.

– Caduchon
Jan 2 at 10:04

But you didn't tell it that. The object is not declared const.

– StoryTeller
Jan 2 at 10:05

2

@Caduchon Here, const means logically const, not physically const. The compiler has no way to know what logically const means, so it can't make any assumptions. For example, a logically-const object might count how many times it is compared. That doesn't change its logical value. There is no safe assumption the compiler can make about logically-const objects.

– David Schwartz
Jan 2 at 10:12

|
show 2 more comments

I have a class Foo having the rights to read an instance of class Bar, but doesn't have the rights to modify it. In the same time, the instance of Bar could be modified by other elements.

For the moment, I implement it by this way:

class Foo

{

  private:

    const Bar& bar; // Foo can't modify it

  public:

    Foo(const Bar& bar_) : bar(bar_) {}

    void doSomthing() { this->bar.printData(); }

};

And it could be used like this:

Bar bar;

Foo foo(bar);

bar.update(); // This modify the instance of Bar

foo.doSomthing(); // This use the reference to (modified) bar

My question is: With this implementation, can I be sure than the compiler doesn't use a non updated copy of bar even if the reference is declared as const ?

If no, how can I do that ?

Note: I don't use C++11 for compatibility reason

edited Jan 10 at 7:50

asked Jan 2 at 8:50

Caduchon

2,47111656

I have a class Foo having the rights to read an instance of class Bar, but doesn't have the rights to modify it. In the same time, the instance of Bar could be modified by other elements.

For the moment, I implement it by this way:

class Foo

{

  private:

    const Bar& bar; // Foo can't modify it

  public:

    Foo(const Bar& bar_) : bar(bar_) {}

    void doSomthing() { this->bar.printData(); }

};

And it could be used like this:

Bar bar;

Foo foo(bar);

bar.update(); // This modify the instance of Bar

foo.doSomthing(); // This use the reference to (modified) bar

My question is: With this implementation, can I be sure than the compiler doesn't use a non updated copy of bar even if the reference is declared as const ?

If no, how can I do that ?

Note: I don't use C++11 for compatibility reason

c++ reference const pass-by-reference const-correctness

edited Jan 10 at 7:50

asked Jan 2 at 8:50

Caduchon

2,47111656

edited Jan 10 at 7:50

asked Jan 2 at 8:50

Caduchon

2,47111656

edited Jan 10 at 7:50

asked Jan 2 at 8:50

Caduchon

2,47111656

asked Jan 2 at 8:50

Caduchon

2,47111656

asked Jan 2 at 8:50

Caduchon

2,47111656

3

Short answer yes. Your code is fine and works as you expect.

– Jarod42
Jan 2 at 9:01

3

I would expect any sane compiler to produce the correct code here. Out of curiosity, where does your doubt stem from?

– StoryTeller
Jan 2 at 9:10

@StoryTeller: because if I said to the compiler that somthing is constant, it could be logical that the compiler decide to create a copy in a closer memory than RAM (like the cache of the processor) whithout having to check if it was updated.

– Caduchon
Jan 2 at 10:04

But you didn't tell it that. The object is not declared const.

– StoryTeller
Jan 2 at 10:05

2

@Caduchon Here, const means logically const, not physically const. The compiler has no way to know what logically const means, so it can't make any assumptions. For example, a logically-const object might count how many times it is compared. That doesn't change its logical value. There is no safe assumption the compiler can make about logically-const objects.

– David Schwartz
Jan 2 at 10:12

|
show 2 more comments

3

Short answer yes. Your code is fine and works as you expect.

– Jarod42
Jan 2 at 9:01

3

I would expect any sane compiler to produce the correct code here. Out of curiosity, where does your doubt stem from?

– StoryTeller
Jan 2 at 9:10

@StoryTeller: because if I said to the compiler that somthing is constant, it could be logical that the compiler decide to create a copy in a closer memory than RAM (like the cache of the processor) whithout having to check if it was updated.

– Caduchon
Jan 2 at 10:04

But you didn't tell it that. The object is not declared const.

– StoryTeller
Jan 2 at 10:05

2

@Caduchon Here, const means logically const, not physically const. The compiler has no way to know what logically const means, so it can't make any assumptions. For example, a logically-const object might count how many times it is compared. That doesn't change its logical value. There is no safe assumption the compiler can make about logically-const objects.

– David Schwartz
Jan 2 at 10:12

Short answer yes. Your code is fine and works as you expect.

– Jarod42
Jan 2 at 9:01

I would expect any sane compiler to produce the correct code here. Out of curiosity, where does your doubt stem from?

– StoryTeller
Jan 2 at 9:10

@StoryTeller: because if I said to the compiler that somthing is constant, it could be logical that the compiler decide to create a copy in a closer memory than RAM (like the cache of the processor) whithout having to check if it was updated.

– Caduchon
Jan 2 at 10:04

But you didn't tell it that. The object is not declared const.

– StoryTeller
Jan 2 at 10:05

@Caduchon Here, const means logically const, not physically const. The compiler has no way to know what logically const means, so it can't make any assumptions. For example, a logically-const object might count how many times it is compared. That doesn't change its logical value. There is no safe assumption the compiler can make about logically-const objects.

– David Schwartz
Jan 2 at 10:12

|
show 2 more comments

2 Answers
2

active

oldest

votes

Yes, you can be sure. References are internally implemented in the compiler as pointers, and both bar.update(); and Foo::bar are acting on the same memory location.

That's, of course, as long as there are no data race concerns, at which point the usual problems of synchronization arise.

answered Jan 2 at 9:09

aybassiouny

423212

add a comment |

-1

The best pre c++11 standard text I could find quickly was this draft from 2005, wich should be close enough to C++03.

It says in 3.10:13 [basic.lval]

The referent of a const-qualified expression shall not be modified (through that expression), except that if it is of class type and has a mutable component, that component can be modified.

The emphasis is mine and highlights that it is to be expected that the referent can be modified though other expressions (if they themselves allow it).

answered Jan 2 at 9:32

Tobi

1,021521

add a comment |

Your Answer

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54003479%2fcan-i-be-sure-than-a-const-reference-is-updated-when-modified-by-another-entity%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

2 Answers
2

active

oldest

votes

2 Answers
2

active

oldest

votes

Yes, you can be sure. References are internally implemented in the compiler as pointers, and both bar.update(); and Foo::bar are acting on the same memory location.

That's, of course, as long as there are no data race concerns, at which point the usual problems of synchronization arise.

answered Jan 2 at 9:09

aybassiouny

423212

add a comment |

Yes, you can be sure. References are internally implemented in the compiler as pointers, and both bar.update(); and Foo::bar are acting on the same memory location.

That's, of course, as long as there are no data race concerns, at which point the usual problems of synchronization arise.

answered Jan 2 at 9:09

aybassiouny

423212

add a comment |

Yes, you can be sure. References are internally implemented in the compiler as pointers, and both bar.update(); and Foo::bar are acting on the same memory location.

That's, of course, as long as there are no data race concerns, at which point the usual problems of synchronization arise.

answered Jan 2 at 9:09

aybassiouny

423212

Yes, you can be sure. References are internally implemented in the compiler as pointers, and both bar.update(); and Foo::bar are acting on the same memory location.

That's, of course, as long as there are no data race concerns, at which point the usual problems of synchronization arise.

answered Jan 2 at 9:09

aybassiouny

423212

answered Jan 2 at 9:09

aybassiouny

423212

answered Jan 2 at 9:09

aybassiouny

423212

answered Jan 2 at 9:09

aybassiouny

423212

add a comment |

-1

The best pre c++11 standard text I could find quickly was this draft from 2005, wich should be close enough to C++03.

It says in 3.10:13 [basic.lval]

The referent of a const-qualified expression shall not be modified (through that expression), except that if it is of class type and has a mutable component, that component can be modified.

The emphasis is mine and highlights that it is to be expected that the referent can be modified though other expressions (if they themselves allow it).

answered Jan 2 at 9:32

Tobi

1,021521

add a comment |

-1

The best pre c++11 standard text I could find quickly was this draft from 2005, wich should be close enough to C++03.

It says in 3.10:13 [basic.lval]

The referent of a const-qualified expression shall not be modified (through that expression), except that if it is of class type and has a mutable component, that component can be modified.

The emphasis is mine and highlights that it is to be expected that the referent can be modified though other expressions (if they themselves allow it).

answered Jan 2 at 9:32

Tobi

1,021521

add a comment |

-1

The best pre c++11 standard text I could find quickly was this draft from 2005, wich should be close enough to C++03.

It says in 3.10:13 [basic.lval]

The referent of a const-qualified expression shall not be modified (through that expression), except that if it is of class type and has a mutable component, that component can be modified.

The emphasis is mine and highlights that it is to be expected that the referent can be modified though other expressions (if they themselves allow it).

answered Jan 2 at 9:32

Tobi

1,021521

The best pre c++11 standard text I could find quickly was this draft from 2005, wich should be close enough to C++03.

It says in 3.10:13 [basic.lval]

The referent of a const-qualified expression shall not be modified (through that expression), except that if it is of class type and has a mutable component, that component can be modified.

The emphasis is mine and highlights that it is to be expected that the referent can be modified though other expressions (if they themselves allow it).

answered Jan 2 at 9:32

Tobi

1,021521

answered Jan 2 at 9:32

Tobi

1,021521

answered Jan 2 at 9:32

Tobi

1,021521

answered Jan 2 at 9:32

Tobi

1,021521

add a comment |

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

Search This Blog

Ufyukyu