Access elements in std::string where positon of string is greater than its size The 2019 Stack Overflow Developer Survey Results Are In Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern) The Ask Question Wizard is Live! Data science time! April 2019 and salary with experienceWhat's the best way to trim std::string?How to convert std::string to lower case?How to convert a std::string to const char* or char*?std::wstring VS std::stringDoes std::string find require that pos be less than the string size?Are the days of passing const std::string & as a parameter over?Is a std::string implementation conformant where 's.c_str() + s.size()' is not necessarily the same as '&s[s.size()]'?Why is f(i = -1, i = -1) undefined behavior?In C++11 and beyond does std::string::operator[] do bounds checking?What made i = i++ + 1; legal in C++17?

How to politely respond to generic emails requesting a PhD/job in my lab? Without wasting too much time

How to split my screen on my Macbook Air?

Word for: a synonym with a positive connotation?

What LEGO pieces have "real-world" functionality?

Cooking pasta in a water boiler

How many people can fit inside Mordenkainen's Magnificent Mansion?

What is special about square numbers here?

What aspect of planet Earth must be changed to prevent the industrial revolution?

What information about me do stores get via my credit card?

Match Roman Numerals

What's the point in a preamp?

Was credit for the black hole image misattributed?

Can a 1st-level character have an ability score above 18?

Relations between two reciprocal partial derivatives?

"... to apply for a visa" or "... and applied for a visa"?

Can the DM override racial traits?

Does Parliament hold absolute power in the UK?

Road tyres vs "Street" tyres for charity ride on MTB Tandem

In horse breeding, what is the female equivalent of putting a horse out "to stud"?

First use of “packing” as in carrying a gun

Didn't get enough time to take a Coding Test - what to do now?

Do warforged have souls?

What can I do if neighbor is blocking my solar panels intentionally?

Sort a list of pairs representing an acyclic, partial automorphism



Access elements in std::string where positon of string is greater than its size



The 2019 Stack Overflow Developer Survey Results Are In
Announcing the arrival of Valued Associate #679: Cesar Manara
Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern)
The Ask Question Wizard is Live!
Data science time! April 2019 and salary with experienceWhat's the best way to trim std::string?How to convert std::string to lower case?How to convert a std::string to const char* or char*?std::wstring VS std::stringDoes std::string find require that pos be less than the string size?Are the days of passing const std::string & as a parameter over?Is a std::string implementation conformant where 's.c_str() + s.size()' is not necessarily the same as '&s[s.size()]'?Why is f(i = -1, i = -1) undefined behavior?In C++11 and beyond does std::string::operator[] do bounds checking?What made i = i++ + 1; legal in C++17?



.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;








26















In case of std::string, if we access an element where (element position) == (size of string) the standard says that it returns a reference to an object of type charT with value charT().



const_reference operator[](size_type pos) const;
reference operator[](size_type pos);



Expects: pos <= size().



Returns: *(begin() + pos) if pos < size(). Otherwise, returns a
reference to an object of type charT with value charT(), where
modifying the object to any value other than charT() leads to
undefined behavior.




http://eel.is/c++draft/strings#string.access-1



Unfortunately I couldn't reason about this, it would have been better if it has been Undefined Behavior.



Can somebody explain the rationale behind this?










share|improve this question



















  • 5





    @user463035818 no that's not true. Subscript operator [] does not perform a check. string::at() does and for that reason it throws

    – KostasRim
    Apr 9 at 8:30







  • 7





    Doesn't violating "Expects: pos <= size()" lead to UB straight away? The "Otherwise" refers only to the pos == size case, no?

    – Max Langhof
    Apr 9 at 8:30







  • 7





    exactly I think the crux is "Expects: pos <= size()." if you dont follow the precondition you are in UB land anyhow, so it is just about accesing the "end" of the string

    – user463035818
    Apr 9 at 8:31






  • 7





    @AImx1 Where does the standard say that violating an "Expects" clause is anything other than UB?

    – Max Langhof
    Apr 9 at 8:31






  • 2





    For a C-style string of length X, using the index X will give you the null-terminator. std::string simply tries to emulate that. Going beyond will always lead to UB.

    – Some programmer dude
    Apr 9 at 8:32


















26















In case of std::string, if we access an element where (element position) == (size of string) the standard says that it returns a reference to an object of type charT with value charT().



const_reference operator[](size_type pos) const;
reference operator[](size_type pos);



Expects: pos <= size().



Returns: *(begin() + pos) if pos < size(). Otherwise, returns a
reference to an object of type charT with value charT(), where
modifying the object to any value other than charT() leads to
undefined behavior.




http://eel.is/c++draft/strings#string.access-1



Unfortunately I couldn't reason about this, it would have been better if it has been Undefined Behavior.



Can somebody explain the rationale behind this?










share|improve this question



















  • 5





    @user463035818 no that's not true. Subscript operator [] does not perform a check. string::at() does and for that reason it throws

    – KostasRim
    Apr 9 at 8:30







  • 7





    Doesn't violating "Expects: pos <= size()" lead to UB straight away? The "Otherwise" refers only to the pos == size case, no?

    – Max Langhof
    Apr 9 at 8:30







  • 7





    exactly I think the crux is "Expects: pos <= size()." if you dont follow the precondition you are in UB land anyhow, so it is just about accesing the "end" of the string

    – user463035818
    Apr 9 at 8:31






  • 7





    @AImx1 Where does the standard say that violating an "Expects" clause is anything other than UB?

    – Max Langhof
    Apr 9 at 8:31






  • 2





    For a C-style string of length X, using the index X will give you the null-terminator. std::string simply tries to emulate that. Going beyond will always lead to UB.

    – Some programmer dude
    Apr 9 at 8:32














26












26








26


2






In case of std::string, if we access an element where (element position) == (size of string) the standard says that it returns a reference to an object of type charT with value charT().



const_reference operator[](size_type pos) const;
reference operator[](size_type pos);



Expects: pos <= size().



Returns: *(begin() + pos) if pos < size(). Otherwise, returns a
reference to an object of type charT with value charT(), where
modifying the object to any value other than charT() leads to
undefined behavior.




http://eel.is/c++draft/strings#string.access-1



Unfortunately I couldn't reason about this, it would have been better if it has been Undefined Behavior.



Can somebody explain the rationale behind this?










share|improve this question
















In case of std::string, if we access an element where (element position) == (size of string) the standard says that it returns a reference to an object of type charT with value charT().



const_reference operator[](size_type pos) const;
reference operator[](size_type pos);



Expects: pos <= size().



Returns: *(begin() + pos) if pos < size(). Otherwise, returns a
reference to an object of type charT with value charT(), where
modifying the object to any value other than charT() leads to
undefined behavior.




http://eel.is/c++draft/strings#string.access-1



Unfortunately I couldn't reason about this, it would have been better if it has been Undefined Behavior.



Can somebody explain the rationale behind this?







c++ string c++11 language-lawyer






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Apr 9 at 23:17









Mooing Duck

47.4k1173132




47.4k1173132










asked Apr 9 at 8:18









AImx1AImx1

508319




508319







  • 5





    @user463035818 no that's not true. Subscript operator [] does not perform a check. string::at() does and for that reason it throws

    – KostasRim
    Apr 9 at 8:30







  • 7





    Doesn't violating "Expects: pos <= size()" lead to UB straight away? The "Otherwise" refers only to the pos == size case, no?

    – Max Langhof
    Apr 9 at 8:30







  • 7





    exactly I think the crux is "Expects: pos <= size()." if you dont follow the precondition you are in UB land anyhow, so it is just about accesing the "end" of the string

    – user463035818
    Apr 9 at 8:31






  • 7





    @AImx1 Where does the standard say that violating an "Expects" clause is anything other than UB?

    – Max Langhof
    Apr 9 at 8:31






  • 2





    For a C-style string of length X, using the index X will give you the null-terminator. std::string simply tries to emulate that. Going beyond will always lead to UB.

    – Some programmer dude
    Apr 9 at 8:32













  • 5





    @user463035818 no that's not true. Subscript operator [] does not perform a check. string::at() does and for that reason it throws

    – KostasRim
    Apr 9 at 8:30







  • 7





    Doesn't violating "Expects: pos <= size()" lead to UB straight away? The "Otherwise" refers only to the pos == size case, no?

    – Max Langhof
    Apr 9 at 8:30







  • 7





    exactly I think the crux is "Expects: pos <= size()." if you dont follow the precondition you are in UB land anyhow, so it is just about accesing the "end" of the string

    – user463035818
    Apr 9 at 8:31






  • 7





    @AImx1 Where does the standard say that violating an "Expects" clause is anything other than UB?

    – Max Langhof
    Apr 9 at 8:31






  • 2





    For a C-style string of length X, using the index X will give you the null-terminator. std::string simply tries to emulate that. Going beyond will always lead to UB.

    – Some programmer dude
    Apr 9 at 8:32








5




5





@user463035818 no that's not true. Subscript operator [] does not perform a check. string::at() does and for that reason it throws

– KostasRim
Apr 9 at 8:30






@user463035818 no that's not true. Subscript operator [] does not perform a check. string::at() does and for that reason it throws

– KostasRim
Apr 9 at 8:30





7




7





Doesn't violating "Expects: pos <= size()" lead to UB straight away? The "Otherwise" refers only to the pos == size case, no?

– Max Langhof
Apr 9 at 8:30






Doesn't violating "Expects: pos <= size()" lead to UB straight away? The "Otherwise" refers only to the pos == size case, no?

– Max Langhof
Apr 9 at 8:30





7




7





exactly I think the crux is "Expects: pos <= size()." if you dont follow the precondition you are in UB land anyhow, so it is just about accesing the "end" of the string

– user463035818
Apr 9 at 8:31





exactly I think the crux is "Expects: pos <= size()." if you dont follow the precondition you are in UB land anyhow, so it is just about accesing the "end" of the string

– user463035818
Apr 9 at 8:31




7




7





@AImx1 Where does the standard say that violating an "Expects" clause is anything other than UB?

– Max Langhof
Apr 9 at 8:31





@AImx1 Where does the standard say that violating an "Expects" clause is anything other than UB?

– Max Langhof
Apr 9 at 8:31




2




2





For a C-style string of length X, using the index X will give you the null-terminator. std::string simply tries to emulate that. Going beyond will always lead to UB.

– Some programmer dude
Apr 9 at 8:32






For a C-style string of length X, using the index X will give you the null-terminator. std::string simply tries to emulate that. Going beyond will always lead to UB.

– Some programmer dude
Apr 9 at 8:32













4 Answers
4






active

oldest

votes


















37














You have to consider the full specs.



First of all:




Expects: pos <= size().




If you dont follow the precondition you have undefined behaviour anyhow. Now...




Returns: *(begin() + pos) if pos < size(). Otherwise, returns a
reference to an object of type charT with value charT(), where
modifying the object to any value other than charT() leads to
undefined behavior.




The only (valid) case that "otherwise" refers to is when pos == size(). And that is probably to emulate c string behaviour that have a some_string[size] element that can be accessed. Note that charT() is typically just ''.



PS: One might think that to implement the specification, operator[] would have to check if pos == size. However, if the underlying character array has a charT() at the end of the string, then you get the described behaviour basically for free. Hence, what seems a little different from "usual" access into an array is actually just that.






share|improve this answer

























  • Great explanation. Also a great example how explaining unsupported cases (>size) leads to harder to follow specs. 'otherwise' should have read 'if pos==size'

    – xtofl
    Apr 10 at 5:27


















22














Statement 1 is the precondition for statement 2:




  1. Expects: pos <= size().



  2. Returns: *(begin() + pos) if pos < size().



    Otherwise (so here the only viable possibility is pos == size()), returns a reference to an object of type charT with value charT() (i.e. ''), where modifying the object to any value other than charT() leads to undefined behavior.





str[str.size()] basically points to the null-terminator character. You can read and write it, but you may only write a '' into it.






share|improve this answer
































    15














    The operator expects pos to be less than or equal to size(), so if it is not less, then it is expected to be equal.






    share|improve this answer
































      2














      Additionally to the previous answers please take a look at the libcxx (the llvm implementation) defines std::string::operator[] like:



      template <class _CharT, class _Traits, class _Allocator>
      inline
      typename basic_string<_CharT, _Traits, _Allocator>::const_reference
      basic_string<_CharT, _Traits, _Allocator>::operator[](size_type __pos) const _NOEXCEPT

      _LIBCPP_ASSERT(__pos <= size(), "string index out of bounds");
      return *(data() + __pos);


      template <class _CharT, class _Traits, class _Allocator>
      inline
      typename basic_string<_CharT, _Traits, _Allocator>::reference
      basic_string<_CharT, _Traits, _Allocator>::operator[](size_type __pos) _NOEXCEPT

      _LIBCPP_ASSERT(__pos <= size(), "string index out of bounds");
      return *(__get_pointer() + __pos);



      Take a look at the .at() that properly throws instead.



      template <class _CharT, class _Traits, class _Allocator>
      typename basic_string<_CharT, _Traits, _Allocator>::const_reference
      basic_string<_CharT, _Traits, _Allocator>::at(size_type __n) const

      if (__n >= size())
      this->__throw_out_of_range();
      return (*this)[__n];



      As you can, in the first case, there is a runtime assert(thanks t.niese for pointing out) which is triggered only in debug mode whereas the second will always throw, regardless of the build options of the library.






      share|improve this answer




















      • 3





        That's not a static assert it is a runtime assert. A static_assert is something that is check at compile time, and a static assert is done for both release and debug builds.

        – t.niese
        Apr 9 at 8:52












      • std::string name = "StackOverflow"; std::cout << name[100]; @t.niese If it a run time assert, why does the below code doesn't crash?

        – AImx1
        Apr 9 at 8:57







      • 2





        @AImx1 cause you didn't specify that you want the debug build when building the library?

        – KostasRim
        Apr 9 at 9:00






      • 3





        @AImx1 because the standard says that name[100] is undefined behavior, and not that it must throw. _LIBCPP_ASSERT is a debugging assert that has to be explicitly enabled and is not automatically enable for regular debug builds, and it is run-time dependent llvm: DebugMode

        – t.niese
        Apr 9 at 9:02












      • Also, putting aside the _LIBCPP_ASSERT, what this code snippet really shows is there is no test like if (__pos >= size()) return _CharT(), which is what would be needed for the behaviour the original question was expecting. Without a test like this, the only way _CharT() could be returned is if it is stored in the buffer pointed to by data(). Obviously this can't the case for all possible values of __pos, unless the buffer takes up all the memory on your computer!

        – Arthur Tacca
        Apr 9 at 14:45












      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


















      StackExchange.ready(
      function ()
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55588104%2faccess-elements-in-stdstring-where-positon-of-string-is-greater-than-its-size%23new-answer', 'question_page');

      );

      Post as a guest















      Required, but never shown

























      4 Answers
      4






      active

      oldest

      votes








      4 Answers
      4






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      37














      You have to consider the full specs.



      First of all:




      Expects: pos <= size().




      If you dont follow the precondition you have undefined behaviour anyhow. Now...




      Returns: *(begin() + pos) if pos < size(). Otherwise, returns a
      reference to an object of type charT with value charT(), where
      modifying the object to any value other than charT() leads to
      undefined behavior.




      The only (valid) case that "otherwise" refers to is when pos == size(). And that is probably to emulate c string behaviour that have a some_string[size] element that can be accessed. Note that charT() is typically just ''.



      PS: One might think that to implement the specification, operator[] would have to check if pos == size. However, if the underlying character array has a charT() at the end of the string, then you get the described behaviour basically for free. Hence, what seems a little different from "usual" access into an array is actually just that.






      share|improve this answer

























      • Great explanation. Also a great example how explaining unsupported cases (>size) leads to harder to follow specs. 'otherwise' should have read 'if pos==size'

        – xtofl
        Apr 10 at 5:27















      37














      You have to consider the full specs.



      First of all:




      Expects: pos <= size().




      If you dont follow the precondition you have undefined behaviour anyhow. Now...




      Returns: *(begin() + pos) if pos < size(). Otherwise, returns a
      reference to an object of type charT with value charT(), where
      modifying the object to any value other than charT() leads to
      undefined behavior.




      The only (valid) case that "otherwise" refers to is when pos == size(). And that is probably to emulate c string behaviour that have a some_string[size] element that can be accessed. Note that charT() is typically just ''.



      PS: One might think that to implement the specification, operator[] would have to check if pos == size. However, if the underlying character array has a charT() at the end of the string, then you get the described behaviour basically for free. Hence, what seems a little different from "usual" access into an array is actually just that.






      share|improve this answer

























      • Great explanation. Also a great example how explaining unsupported cases (>size) leads to harder to follow specs. 'otherwise' should have read 'if pos==size'

        – xtofl
        Apr 10 at 5:27













      37












      37








      37







      You have to consider the full specs.



      First of all:




      Expects: pos <= size().




      If you dont follow the precondition you have undefined behaviour anyhow. Now...




      Returns: *(begin() + pos) if pos < size(). Otherwise, returns a
      reference to an object of type charT with value charT(), where
      modifying the object to any value other than charT() leads to
      undefined behavior.




      The only (valid) case that "otherwise" refers to is when pos == size(). And that is probably to emulate c string behaviour that have a some_string[size] element that can be accessed. Note that charT() is typically just ''.



      PS: One might think that to implement the specification, operator[] would have to check if pos == size. However, if the underlying character array has a charT() at the end of the string, then you get the described behaviour basically for free. Hence, what seems a little different from "usual" access into an array is actually just that.






      share|improve this answer















      You have to consider the full specs.



      First of all:




      Expects: pos <= size().




      If you dont follow the precondition you have undefined behaviour anyhow. Now...




      Returns: *(begin() + pos) if pos < size(). Otherwise, returns a
      reference to an object of type charT with value charT(), where
      modifying the object to any value other than charT() leads to
      undefined behavior.




      The only (valid) case that "otherwise" refers to is when pos == size(). And that is probably to emulate c string behaviour that have a some_string[size] element that can be accessed. Note that charT() is typically just ''.



      PS: One might think that to implement the specification, operator[] would have to check if pos == size. However, if the underlying character array has a charT() at the end of the string, then you get the described behaviour basically for free. Hence, what seems a little different from "usual" access into an array is actually just that.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Apr 9 at 8:49

























      answered Apr 9 at 8:35









      user463035818user463035818

      19.1k42971




      19.1k42971












      • Great explanation. Also a great example how explaining unsupported cases (>size) leads to harder to follow specs. 'otherwise' should have read 'if pos==size'

        – xtofl
        Apr 10 at 5:27

















      • Great explanation. Also a great example how explaining unsupported cases (>size) leads to harder to follow specs. 'otherwise' should have read 'if pos==size'

        – xtofl
        Apr 10 at 5:27
















      Great explanation. Also a great example how explaining unsupported cases (>size) leads to harder to follow specs. 'otherwise' should have read 'if pos==size'

      – xtofl
      Apr 10 at 5:27





      Great explanation. Also a great example how explaining unsupported cases (>size) leads to harder to follow specs. 'otherwise' should have read 'if pos==size'

      – xtofl
      Apr 10 at 5:27













      22














      Statement 1 is the precondition for statement 2:




      1. Expects: pos <= size().



      2. Returns: *(begin() + pos) if pos < size().



        Otherwise (so here the only viable possibility is pos == size()), returns a reference to an object of type charT with value charT() (i.e. ''), where modifying the object to any value other than charT() leads to undefined behavior.





      str[str.size()] basically points to the null-terminator character. You can read and write it, but you may only write a '' into it.






      share|improve this answer





























        22














        Statement 1 is the precondition for statement 2:




        1. Expects: pos <= size().



        2. Returns: *(begin() + pos) if pos < size().



          Otherwise (so here the only viable possibility is pos == size()), returns a reference to an object of type charT with value charT() (i.e. ''), where modifying the object to any value other than charT() leads to undefined behavior.





        str[str.size()] basically points to the null-terminator character. You can read and write it, but you may only write a '' into it.






        share|improve this answer



























          22












          22








          22







          Statement 1 is the precondition for statement 2:




          1. Expects: pos <= size().



          2. Returns: *(begin() + pos) if pos < size().



            Otherwise (so here the only viable possibility is pos == size()), returns a reference to an object of type charT with value charT() (i.e. ''), where modifying the object to any value other than charT() leads to undefined behavior.





          str[str.size()] basically points to the null-terminator character. You can read and write it, but you may only write a '' into it.






          share|improve this answer















          Statement 1 is the precondition for statement 2:




          1. Expects: pos <= size().



          2. Returns: *(begin() + pos) if pos < size().



            Otherwise (so here the only viable possibility is pos == size()), returns a reference to an object of type charT with value charT() (i.e. ''), where modifying the object to any value other than charT() leads to undefined behavior.





          str[str.size()] basically points to the null-terminator character. You can read and write it, but you may only write a '' into it.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Apr 9 at 23:20









          Mooing Duck

          47.4k1173132




          47.4k1173132










          answered Apr 9 at 8:36









          rustyxrustyx

          33.5k8100144




          33.5k8100144





















              15














              The operator expects pos to be less than or equal to size(), so if it is not less, then it is expected to be equal.






              share|improve this answer





























                15














                The operator expects pos to be less than or equal to size(), so if it is not less, then it is expected to be equal.






                share|improve this answer



























                  15












                  15








                  15







                  The operator expects pos to be less than or equal to size(), so if it is not less, then it is expected to be equal.






                  share|improve this answer















                  The operator expects pos to be less than or equal to size(), so if it is not less, then it is expected to be equal.







                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited Apr 9 at 9:33









                  Raimund Krämer

                  710425




                  710425










                  answered Apr 9 at 8:34









                  YolaYola

                  11.5k64774




                  11.5k64774





















                      2














                      Additionally to the previous answers please take a look at the libcxx (the llvm implementation) defines std::string::operator[] like:



                      template <class _CharT, class _Traits, class _Allocator>
                      inline
                      typename basic_string<_CharT, _Traits, _Allocator>::const_reference
                      basic_string<_CharT, _Traits, _Allocator>::operator[](size_type __pos) const _NOEXCEPT

                      _LIBCPP_ASSERT(__pos <= size(), "string index out of bounds");
                      return *(data() + __pos);


                      template <class _CharT, class _Traits, class _Allocator>
                      inline
                      typename basic_string<_CharT, _Traits, _Allocator>::reference
                      basic_string<_CharT, _Traits, _Allocator>::operator[](size_type __pos) _NOEXCEPT

                      _LIBCPP_ASSERT(__pos <= size(), "string index out of bounds");
                      return *(__get_pointer() + __pos);



                      Take a look at the .at() that properly throws instead.



                      template <class _CharT, class _Traits, class _Allocator>
                      typename basic_string<_CharT, _Traits, _Allocator>::const_reference
                      basic_string<_CharT, _Traits, _Allocator>::at(size_type __n) const

                      if (__n >= size())
                      this->__throw_out_of_range();
                      return (*this)[__n];



                      As you can, in the first case, there is a runtime assert(thanks t.niese for pointing out) which is triggered only in debug mode whereas the second will always throw, regardless of the build options of the library.






                      share|improve this answer




















                      • 3





                        That's not a static assert it is a runtime assert. A static_assert is something that is check at compile time, and a static assert is done for both release and debug builds.

                        – t.niese
                        Apr 9 at 8:52












                      • std::string name = "StackOverflow"; std::cout << name[100]; @t.niese If it a run time assert, why does the below code doesn't crash?

                        – AImx1
                        Apr 9 at 8:57







                      • 2





                        @AImx1 cause you didn't specify that you want the debug build when building the library?

                        – KostasRim
                        Apr 9 at 9:00






                      • 3





                        @AImx1 because the standard says that name[100] is undefined behavior, and not that it must throw. _LIBCPP_ASSERT is a debugging assert that has to be explicitly enabled and is not automatically enable for regular debug builds, and it is run-time dependent llvm: DebugMode

                        – t.niese
                        Apr 9 at 9:02












                      • Also, putting aside the _LIBCPP_ASSERT, what this code snippet really shows is there is no test like if (__pos >= size()) return _CharT(), which is what would be needed for the behaviour the original question was expecting. Without a test like this, the only way _CharT() could be returned is if it is stored in the buffer pointed to by data(). Obviously this can't the case for all possible values of __pos, unless the buffer takes up all the memory on your computer!

                        – Arthur Tacca
                        Apr 9 at 14:45
















                      2














                      Additionally to the previous answers please take a look at the libcxx (the llvm implementation) defines std::string::operator[] like:



                      template <class _CharT, class _Traits, class _Allocator>
                      inline
                      typename basic_string<_CharT, _Traits, _Allocator>::const_reference
                      basic_string<_CharT, _Traits, _Allocator>::operator[](size_type __pos) const _NOEXCEPT

                      _LIBCPP_ASSERT(__pos <= size(), "string index out of bounds");
                      return *(data() + __pos);


                      template <class _CharT, class _Traits, class _Allocator>
                      inline
                      typename basic_string<_CharT, _Traits, _Allocator>::reference
                      basic_string<_CharT, _Traits, _Allocator>::operator[](size_type __pos) _NOEXCEPT

                      _LIBCPP_ASSERT(__pos <= size(), "string index out of bounds");
                      return *(__get_pointer() + __pos);



                      Take a look at the .at() that properly throws instead.



                      template <class _CharT, class _Traits, class _Allocator>
                      typename basic_string<_CharT, _Traits, _Allocator>::const_reference
                      basic_string<_CharT, _Traits, _Allocator>::at(size_type __n) const

                      if (__n >= size())
                      this->__throw_out_of_range();
                      return (*this)[__n];



                      As you can, in the first case, there is a runtime assert(thanks t.niese for pointing out) which is triggered only in debug mode whereas the second will always throw, regardless of the build options of the library.






                      share|improve this answer




















                      • 3





                        That's not a static assert it is a runtime assert. A static_assert is something that is check at compile time, and a static assert is done for both release and debug builds.

                        – t.niese
                        Apr 9 at 8:52












                      • std::string name = "StackOverflow"; std::cout << name[100]; @t.niese If it a run time assert, why does the below code doesn't crash?

                        – AImx1
                        Apr 9 at 8:57







                      • 2





                        @AImx1 cause you didn't specify that you want the debug build when building the library?

                        – KostasRim
                        Apr 9 at 9:00






                      • 3





                        @AImx1 because the standard says that name[100] is undefined behavior, and not that it must throw. _LIBCPP_ASSERT is a debugging assert that has to be explicitly enabled and is not automatically enable for regular debug builds, and it is run-time dependent llvm: DebugMode

                        – t.niese
                        Apr 9 at 9:02












                      • Also, putting aside the _LIBCPP_ASSERT, what this code snippet really shows is there is no test like if (__pos >= size()) return _CharT(), which is what would be needed for the behaviour the original question was expecting. Without a test like this, the only way _CharT() could be returned is if it is stored in the buffer pointed to by data(). Obviously this can't the case for all possible values of __pos, unless the buffer takes up all the memory on your computer!

                        – Arthur Tacca
                        Apr 9 at 14:45














                      2












                      2








                      2







                      Additionally to the previous answers please take a look at the libcxx (the llvm implementation) defines std::string::operator[] like:



                      template <class _CharT, class _Traits, class _Allocator>
                      inline
                      typename basic_string<_CharT, _Traits, _Allocator>::const_reference
                      basic_string<_CharT, _Traits, _Allocator>::operator[](size_type __pos) const _NOEXCEPT

                      _LIBCPP_ASSERT(__pos <= size(), "string index out of bounds");
                      return *(data() + __pos);


                      template <class _CharT, class _Traits, class _Allocator>
                      inline
                      typename basic_string<_CharT, _Traits, _Allocator>::reference
                      basic_string<_CharT, _Traits, _Allocator>::operator[](size_type __pos) _NOEXCEPT

                      _LIBCPP_ASSERT(__pos <= size(), "string index out of bounds");
                      return *(__get_pointer() + __pos);



                      Take a look at the .at() that properly throws instead.



                      template <class _CharT, class _Traits, class _Allocator>
                      typename basic_string<_CharT, _Traits, _Allocator>::const_reference
                      basic_string<_CharT, _Traits, _Allocator>::at(size_type __n) const

                      if (__n >= size())
                      this->__throw_out_of_range();
                      return (*this)[__n];



                      As you can, in the first case, there is a runtime assert(thanks t.niese for pointing out) which is triggered only in debug mode whereas the second will always throw, regardless of the build options of the library.






                      share|improve this answer















                      Additionally to the previous answers please take a look at the libcxx (the llvm implementation) defines std::string::operator[] like:



                      template <class _CharT, class _Traits, class _Allocator>
                      inline
                      typename basic_string<_CharT, _Traits, _Allocator>::const_reference
                      basic_string<_CharT, _Traits, _Allocator>::operator[](size_type __pos) const _NOEXCEPT

                      _LIBCPP_ASSERT(__pos <= size(), "string index out of bounds");
                      return *(data() + __pos);


                      template <class _CharT, class _Traits, class _Allocator>
                      inline
                      typename basic_string<_CharT, _Traits, _Allocator>::reference
                      basic_string<_CharT, _Traits, _Allocator>::operator[](size_type __pos) _NOEXCEPT

                      _LIBCPP_ASSERT(__pos <= size(), "string index out of bounds");
                      return *(__get_pointer() + __pos);



                      Take a look at the .at() that properly throws instead.



                      template <class _CharT, class _Traits, class _Allocator>
                      typename basic_string<_CharT, _Traits, _Allocator>::const_reference
                      basic_string<_CharT, _Traits, _Allocator>::at(size_type __n) const

                      if (__n >= size())
                      this->__throw_out_of_range();
                      return (*this)[__n];



                      As you can, in the first case, there is a runtime assert(thanks t.niese for pointing out) which is triggered only in debug mode whereas the second will always throw, regardless of the build options of the library.







                      share|improve this answer














                      share|improve this answer



                      share|improve this answer








                      edited Apr 9 at 8:55

























                      answered Apr 9 at 8:47









                      KostasRimKostasRim

                      1,5821926




                      1,5821926







                      • 3





                        That's not a static assert it is a runtime assert. A static_assert is something that is check at compile time, and a static assert is done for both release and debug builds.

                        – t.niese
                        Apr 9 at 8:52












                      • std::string name = "StackOverflow"; std::cout << name[100]; @t.niese If it a run time assert, why does the below code doesn't crash?

                        – AImx1
                        Apr 9 at 8:57







                      • 2





                        @AImx1 cause you didn't specify that you want the debug build when building the library?

                        – KostasRim
                        Apr 9 at 9:00






                      • 3





                        @AImx1 because the standard says that name[100] is undefined behavior, and not that it must throw. _LIBCPP_ASSERT is a debugging assert that has to be explicitly enabled and is not automatically enable for regular debug builds, and it is run-time dependent llvm: DebugMode

                        – t.niese
                        Apr 9 at 9:02












                      • Also, putting aside the _LIBCPP_ASSERT, what this code snippet really shows is there is no test like if (__pos >= size()) return _CharT(), which is what would be needed for the behaviour the original question was expecting. Without a test like this, the only way _CharT() could be returned is if it is stored in the buffer pointed to by data(). Obviously this can't the case for all possible values of __pos, unless the buffer takes up all the memory on your computer!

                        – Arthur Tacca
                        Apr 9 at 14:45













                      • 3





                        That's not a static assert it is a runtime assert. A static_assert is something that is check at compile time, and a static assert is done for both release and debug builds.

                        – t.niese
                        Apr 9 at 8:52












                      • std::string name = "StackOverflow"; std::cout << name[100]; @t.niese If it a run time assert, why does the below code doesn't crash?

                        – AImx1
                        Apr 9 at 8:57







                      • 2





                        @AImx1 cause you didn't specify that you want the debug build when building the library?

                        – KostasRim
                        Apr 9 at 9:00






                      • 3





                        @AImx1 because the standard says that name[100] is undefined behavior, and not that it must throw. _LIBCPP_ASSERT is a debugging assert that has to be explicitly enabled and is not automatically enable for regular debug builds, and it is run-time dependent llvm: DebugMode

                        – t.niese
                        Apr 9 at 9:02












                      • Also, putting aside the _LIBCPP_ASSERT, what this code snippet really shows is there is no test like if (__pos >= size()) return _CharT(), which is what would be needed for the behaviour the original question was expecting. Without a test like this, the only way _CharT() could be returned is if it is stored in the buffer pointed to by data(). Obviously this can't the case for all possible values of __pos, unless the buffer takes up all the memory on your computer!

                        – Arthur Tacca
                        Apr 9 at 14:45








                      3




                      3





                      That's not a static assert it is a runtime assert. A static_assert is something that is check at compile time, and a static assert is done for both release and debug builds.

                      – t.niese
                      Apr 9 at 8:52






                      That's not a static assert it is a runtime assert. A static_assert is something that is check at compile time, and a static assert is done for both release and debug builds.

                      – t.niese
                      Apr 9 at 8:52














                      std::string name = "StackOverflow"; std::cout << name[100]; @t.niese If it a run time assert, why does the below code doesn't crash?

                      – AImx1
                      Apr 9 at 8:57






                      std::string name = "StackOverflow"; std::cout << name[100]; @t.niese If it a run time assert, why does the below code doesn't crash?

                      – AImx1
                      Apr 9 at 8:57





                      2




                      2





                      @AImx1 cause you didn't specify that you want the debug build when building the library?

                      – KostasRim
                      Apr 9 at 9:00





                      @AImx1 cause you didn't specify that you want the debug build when building the library?

                      – KostasRim
                      Apr 9 at 9:00




                      3




                      3





                      @AImx1 because the standard says that name[100] is undefined behavior, and not that it must throw. _LIBCPP_ASSERT is a debugging assert that has to be explicitly enabled and is not automatically enable for regular debug builds, and it is run-time dependent llvm: DebugMode

                      – t.niese
                      Apr 9 at 9:02






                      @AImx1 because the standard says that name[100] is undefined behavior, and not that it must throw. _LIBCPP_ASSERT is a debugging assert that has to be explicitly enabled and is not automatically enable for regular debug builds, and it is run-time dependent llvm: DebugMode

                      – t.niese
                      Apr 9 at 9:02














                      Also, putting aside the _LIBCPP_ASSERT, what this code snippet really shows is there is no test like if (__pos >= size()) return _CharT(), which is what would be needed for the behaviour the original question was expecting. Without a test like this, the only way _CharT() could be returned is if it is stored in the buffer pointed to by data(). Obviously this can't the case for all possible values of __pos, unless the buffer takes up all the memory on your computer!

                      – Arthur Tacca
                      Apr 9 at 14:45






                      Also, putting aside the _LIBCPP_ASSERT, what this code snippet really shows is there is no test like if (__pos >= size()) return _CharT(), which is what would be needed for the behaviour the original question was expecting. Without a test like this, the only way _CharT() could be returned is if it is stored in the buffer pointed to by data(). Obviously this can't the case for all possible values of __pos, unless the buffer takes up all the memory on your computer!

                      – Arthur Tacca
                      Apr 9 at 14:45


















                      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














                      StackExchange.ready(
                      function ()
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55588104%2faccess-elements-in-stdstring-where-positon-of-string-is-greater-than-its-size%23new-answer', 'question_page');

                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      Club Baloncesto Breogán Índice Historia | Pavillón | Nome | O Breogán na cultura popular | Xogadores | Adestradores | Presidentes | Palmarés | Historial | Líderes | Notas | Véxase tamén | Menú de navegacióncbbreogan.galCadroGuía oficial da ACB 2009-10, páxina 201Guía oficial ACB 1992, páxina 183. Editorial DB.É de 6.500 espectadores sentados axeitándose á última normativa"Estudiantes Junior, entre as mellores canteiras"o orixinalHemeroteca El Mundo Deportivo, 16 setembro de 1970, páxina 12Historia do BreogánAlfredo Pérez, o último canoneiroHistoria C.B. BreogánHemeroteca de El Mundo DeportivoJimmy Wright, norteamericano do Breogán deixará Lugo por ameazas de morteResultados de Breogán en 1986-87Resultados de Breogán en 1990-91Ficha de Velimir Perasović en acb.comResultados de Breogán en 1994-95Breogán arrasa al Barça. "El Mundo Deportivo", 27 de setembro de 1999, páxina 58CB Breogán - FC BarcelonaA FEB invita a participar nunha nova Liga EuropeaCharlie Bell na prensa estatalMáximos anotadores 2005Tempada 2005-06 : Tódolos Xogadores da Xornada""Non quero pensar nunha man negra, mais pregúntome que está a pasar""o orixinalRaúl López, orgulloso dos xogadores, presume da boa saúde económica do BreogánJulio González confirma que cesa como presidente del BreogánHomenaxe a Lisardo GómezA tempada do rexurdimento celesteEntrevista a Lisardo GómezEl COB dinamita el Pazo para forzar el quinto (69-73)Cafés Candelas, patrocinador del CB Breogán"Suso Lázare, novo presidente do Breogán"o orixinalCafés Candelas Breogán firma el mayor triunfo de la historiaEl Breogán realizará 17 homenajes por su cincuenta aniversario"O Breogán honra ao seu fundador e primeiro presidente"o orixinalMiguel Giao recibiu a homenaxe do PazoHomenaxe aos primeiros gladiadores celestesO home que nos amosa como ver o Breo co corazónTita Franco será homenaxeada polos #50anosdeBreoJulio Vila recibirá unha homenaxe in memoriam polos #50anosdeBreo"O Breogán homenaxeará aos seus aboados máis veteráns"Pechada ovación a «Capi» Sanmartín e Ricardo «Corazón de González»Homenaxe por décadas de informaciónPaco García volve ao Pazo con motivo do 50 aniversario"Resultados y clasificaciones""O Cafés Candelas Breogán, campión da Copa Princesa""O Cafés Candelas Breogán, equipo ACB"C.B. Breogán"Proxecto social"o orixinal"Centros asociados"o orixinalFicha en imdb.comMario Camus trata la recuperación del amor en 'La vieja música', su última película"Páxina web oficial""Club Baloncesto Breogán""C. B. Breogán S.A.D."eehttp://www.fegaba.com

                      Vilaño, A Laracha Índice Patrimonio | Lugares e parroquias | Véxase tamén | Menú de navegación43°14′52″N 8°36′03″O / 43.24775, -8.60070

                      Cegueira Índice Epidemioloxía | Deficiencia visual | Tipos de cegueira | Principais causas de cegueira | Tratamento | Técnicas de adaptación e axudas | Vida dos cegos | Primeiros auxilios | Crenzas respecto das persoas cegas | Crenzas das persoas cegas | O neno deficiente visual | Aspectos psicolóxicos da cegueira | Notas | Véxase tamén | Menú de navegación54.054.154.436928256blindnessDicionario da Real Academia GalegaPortal das Palabras"International Standards: Visual Standards — Aspects and Ranges of Vision Loss with Emphasis on Population Surveys.""Visual impairment and blindness""Presentan un plan para previr a cegueira"o orixinalACCDV Associació Catalana de Cecs i Disminuïts Visuals - PMFTrachoma"Effect of gene therapy on visual function in Leber's congenital amaurosis"1844137110.1056/NEJMoa0802268Cans guía - os mellores amigos dos cegosArquivadoEscola de cans guía para cegos en Mortágua, PortugalArquivado"Tecnología para ciegos y deficientes visuales. Recopilación de recursos gratuitos en la Red""Colorino""‘COL.diesis’, escuchar los sonidos del color""COL.diesis: Transforming Colour into Melody and Implementing the Result in a Colour Sensor Device"o orixinal"Sistema de desarrollo de sinestesia color-sonido para invidentes utilizando un protocolo de audio""Enseñanza táctil - geometría y color. Juegos didácticos para niños ciegos y videntes""Sistema Constanz"L'ocupació laboral dels cecs a l'Estat espanyol està pràcticament equiparada a la de les persones amb visió, entrevista amb Pedro ZuritaONCE (Organización Nacional de Cegos de España)Prevención da cegueiraDescrición de deficiencias visuais (Disc@pnet)Braillín, un boneco atractivo para calquera neno, con ou sen discapacidade, que permite familiarizarse co sistema de escritura e lectura brailleAxudas Técnicas36838ID00897494007150-90057129528256DOID:1432HP:0000618D001766C10.597.751.941.162C97109C0155020