mackrune wrote:

> Prints: 'bello world'
> Is this code guaranteed not to work in the standard? I ask
> because it does (work) in VC6 (at least in release build).


It is undefined behaviour.

VC 6 allows you to overwrite the const string, but e.g. gcc
does not. gcc gives you a nonconst copy of the original
string. (At least it was so when I tested it :-) )

The problem is, you can never be sure...

odie

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3dafb936$0$12948$3b214f66@aconews.univie.ac.at>,
 on Fri, 18 Oct 2002 18:03:13 CST,
 Christoph Rabel <odie@hal9000.vc-graz.ac.at> wrote:

> mackrune wrote:
>
> > Prints: 'bello world'
> > Is this code guaranteed not to work in the standard? I ask because
> > it does (work) in VC6 (at least in release build).
>
>
>
> It is undefined behaviour.
>
> VC 6 allows you to overwrite the const string,

The behaviour is, as you say, clearly undefined. However, in the
specific case of VC 6, the /actual/ runtime behaviour depends on the
options you pass to the compiler. If you enable "read-only string
pooling" (/GF), then you'll probably get an application error.
(Naturally, since the behaviour is undefined it may also be dependant
on latitude, prevailing wind direction, or what your next door
neighbour had for breakfast).

> The problem is, you can never be sure...

What you /can/ be sure of is that the behaviour is undefined, and
undefined behaviour is a /very/ bad thing to rely on.

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

#include <iostream>
#include <string>
using namespace std;

template<typename T> T* NoMoreConst(const T* ptr)
{
 return (T*)(int)(ptr);
}

int main()
{
 string str1 = string("hello ") + "world";
 char* sz1 = NoMoreConst(str1.c_str());
 *sz1='b';
 cout << str1;

 return 0;
}

Prints: 'bello world'
Is this code guaranteed not to work in the standard? I ask because it does
(work) in VC6 (at least in release build).

mackrune


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""mackrune"" <rune420_removethis_@start.no> wrote in message news:aonbjg$obn$1@troll.powertech.no...

> Prints: 'bello world'
> Is this code guaranteed not to work in the standard? I ask because it does
> (work) in VC6 (at least in release build).

No, it's undefined behavior.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

mackrune wrote:
> #include <iostream>
> #include <string>
> using namespace std;
>
> template<typename T> T* NoMoreConst(const T* ptr)
> {
>  return (T*)(int)(ptr);
> }
>
> int main()
> {
>  string str1 = string("hello ") + "world";
>  char* sz1 = NoMoreConst(str1.c_str());
>  *sz1='b';
>  cout << str1;
>
>  return 0;
> }
>
> Prints: 'bello world'
> Is this code guaranteed not to work in the standard? I ask because it does
> (work) in VC6 (at least in release build).

The standard NEVER prohibits code from working, no matter how badly it
is written. Diagnosible violations of the standard's requirements
require a diagnostic message, but after the diagnostic message is
displayed, the implementation is free to continue on handling the code.
If the code is so bad that the behavior is undefined, then the
implementation is free to do absolutely anything it wants to do with the
code, including interpreting it exactly as you intended, rather than the
way you actually wrote it. I wouldn't recommend counting on that,
however. :-)

This particular code violates the rule in 21.3.6p2 which says that "The
program shall not alter any of the values stored in the array" that is
pointed at by the return value of c_str().

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]