<string>,memory access violation 
Author Message
 <string>,memory access violation

It's bizarre that either works, because you never allocate space in the
output string - it's internal character pointer should be pointing at null.

instead you want

wchar_t strIn[] = L"this is a test";
wstring strOut = strIn; //this allocates and copies
transform(strOut.begin(),strOut.end(),strOut.begin(),towupper);
//this transforms in place - overwriting strOut as it goes

Ken


Quote:
> This code compiles. When I run it, I get an access violation on program
> exit.
> --------------------------------------------------------------------------
>  wchar_t strIn[] = L"this is a test";
>  wstring strOut;
>  transform(&strIn[0],&strIn[wcslen(strIn)],strOut.begin(),towupper);
> ------------------------------------------------------------------------
> This runs OK:
> --------------------------------------------------------------------
>  wstring strIn( L"this is a test"); // instead of wchar_t[]
>  wstring strOut;
>  transform(strIn.begin(),strIn.end(),strOut.begin(),towupper);
>  -------------------------------------------------------------------

> Alex




Tue, 20 May 2003 03:00:00 GMT  
 <string>,memory access violation
This code compiles. When I run it, I get an access violation on program
exit.
--------------------------------------------------------------------------
 wchar_t strIn[] = L"this is a test";
 wstring strOut;
 transform(&strIn[0],&strIn[wcslen(strIn)],strOut.begin(),towupper);
------------------------------------------------------------------------
This runs OK:
--------------------------------------------------------------------
 wstring strIn( L"this is a test"); // instead of wchar_t[]
 wstring strOut;
 transform(strIn.begin(),strIn.end(),strOut.begin(),towupper);
 -------------------------------------------------------------------

Alex



Wed, 21 May 2003 07:49:06 GMT  
 <string>,memory access violation
This works on MSVC 6.0 SP4 with Dinkumware STL out-of-the box:

wchar_t strIn[] = L"this is a test";
wstring strOut;
transform(&strIn[0],&strIn[wcslen(strIn)],inserter(strOut,
strOut.begin()),towupper);

Though I'm a little confused why. Documentation says
insert_iterator::operator=() evaluates iter = container.insert(iter, val)
(where iter is the true iterator over container). If this were the case the
snippet shoud have reversed the sequence as well as capitalizing it. This
did not happen, so I looked at the sources:

 insert_iterator<_C>& operator=(
  const value_type& _V)
  {iter = container.insert(iter, _V);
  ++iter;
  return (*this); }

See, after assignment the code does iter++ thus moving the iterator to the
position after the element just inserted, so the next element will be
inserted after the first.

Unfortunately, I don't have a copy of the standard, so my question is: what
is the standard behavior of insert_iterator::operator=()?
--
With best wishes,
    Igor Tandetnik


Quote:
> This code compiles. When I run it, I get an access violation on program
> exit.
> --------------------------------------------------------------------------
>  wchar_t strIn[] = L"this is a test";
>  wstring strOut;
>  transform(&strIn[0],&strIn[wcslen(strIn)],strOut.begin(),towupper);
> ------------------------------------------------------------------------
> This runs OK:
> --------------------------------------------------------------------
>  wstring strIn( L"this is a test"); // instead of wchar_t[]
>  wstring strOut;
>  transform(strIn.begin(),strIn.end(),strOut.begin(),towupper);
>  -------------------------------------------------------------------

> Alex




Thu, 22 May 2003 03:00:00 GMT  
 <string>,memory access violation

Quote:

>This works on MSVC 6.0 SP4 with Dinkumware STL out-of-the box:

>wchar_t strIn[] = L"this is a test";
>wstring strOut;
>transform(&strIn[0],&strIn[wcslen(strIn)],inserter(strOut,
>strOut.begin()),towupper);

>Though I'm a little confused why. Documentation says
>insert_iterator::operator=() evaluates iter = container.insert(iter, val)
>(where iter is the true iterator over container).

>If this were the case the
>snippet shoud have reversed the sequence as well as capitalizing it. This
>did not happen, so I looked at the sources:

> insert_iterator<_C>& operator=(
>  const value_type& _V)
>  {iter = container.insert(iter, _V);
>  ++iter;
>  return (*this); }

>See, after assignment the code does iter++ thus moving the iterator to the
>position after the element just inserted, so the next element will be
>inserted after the first.

>Unfortunately, I don't have a copy of the standard, so my question is: what
>is the standard behavior of insert_iterator::operator=()?

It's standard. container::insert returns an iterator to the newly
inserted element, and incrementing keeps iter pointing at the element
it originally pointed to.

--
Doug Harrison [VC++ MVP]
Eluent Software, LLC
http://www.eluent.com
Tools for Visual C++ and Windows



Thu, 22 May 2003 03:00:00 GMT  
 <string>,memory access violation
Thank you for the answer. So, to make that straight, are you saying that the
MSDN documentation is wrong and the code is right? Does the standard say
that insert_iterator()::operator=() inserts new element and positions the
iterator right after the newly inserted element? Or does it say that the
iterator must point to the element it originally pointed to? In the latter
case the code is wrong when acting on set or map.
--
With best wishes,
    Igor Tandetnik



Quote:

> >This works on MSVC 6.0 SP4 with Dinkumware STL out-of-the box:

> >wchar_t strIn[] = L"this is a test";
> >wstring strOut;
> >transform(&strIn[0],&strIn[wcslen(strIn)],inserter(strOut,
> >strOut.begin()),towupper);

> >Though I'm a little confused why. Documentation says
> >insert_iterator::operator=() evaluates iter = container.insert(iter, val)
> >(where iter is the true iterator over container).

> >If this were the case the
> >snippet shoud have reversed the sequence as well as capitalizing it. This
> >did not happen, so I looked at the sources:

> > insert_iterator<_C>& operator=(
> >  const value_type& _V)
> >  {iter = container.insert(iter, _V);
> >  ++iter;
> >  return (*this); }

> >See, after assignment the code does iter++ thus moving the iterator to
the
> >position after the element just inserted, so the next element will be
> >inserted after the first.

> >Unfortunately, I don't have a copy of the standard, so my question is:
what
> >is the standard behavior of insert_iterator::operator=()?

> It's standard. container::insert returns an iterator to the newly
> inserted element, and incrementing keeps iter pointing at the element
> it originally pointed to.

> --
> Doug Harrison [VC++ MVP]
> Eluent Software, LLC
> http://www.eluent.com
> Tools for Visual C++ and Windows



Fri, 23 May 2003 03:00:00 GMT  
 <string>,memory access violation

Quote:

>Thank you for the answer. So, to make that straight, are you saying that the
>MSDN documentation is wrong and the code is right? Does the standard say
>that insert_iterator()::operator=() inserts new element and positions the
>iterator right after the newly inserted element?

The standard says the semantics are what you observed in the actual
implementation, so the code is right.

Quote:
>Or does it say that the
>iterator must point to the element it originally pointed to? In the latter
>case the code is wrong when acting on set or map.

Well, yes. For associative containers, insert's iterator argument is
just a hint, but if you're using that form of insert, hopefully you
have the right iterator, and the value you're inserting should come
just before it, in which case, the semantics are like I
(simplistically) described. Otherwise, it'll still work, but it may be
a little bit slower than using insert(t).

--
Doug Harrison [VC++ MVP]
Eluent Software, LLC
http://www.eluent.com
Tools for Visual C++ and Windows



Fri, 23 May 2003 03:00:00 GMT  
 <string>,memory access violation

Quote:


> >Or does it say that the
> >iterator must point to the element it originally pointed to? In the latter
> >case the code is wrong when acting on set or map.

> Well, yes. For associative containers, insert's iterator argument is
> just a hint, but if you're using that form of insert, hopefully you
> have the right iterator, and the value you're inserting should come
> just before it

Correct according to the standard, but it's not what the VC++ library
does.  VC++ library has O(1) complexity only for insert-after-hint.
I think the most updated Dinkumware library may have fixed this so
that both are O(1).
Quote:
>, in which case, the semantics are like I
> (simplistically) described. Otherwise, it'll still work, but it may be
> a little bit slower than using insert(t).



Sat, 24 May 2003 03:00:00 GMT  
 <string>,memory access violation
Previously, Craig Powers wrote in microsoft.public.vc.stl:

Quote:


> > >Or does it say that the
> > >iterator must point to the element it originally pointed to? In the latter
> > >case the code is wrong when acting on set or map.

> > Well, yes. For associative containers, insert's iterator argument is
> > just a hint, but if you're using that form of insert, hopefully you
> > have the right iterator, and the value you're inserting should come
> > just before it

> Correct according to the standard, but it's not what the VC++ library
> does.  VC++ library has O(1) complexity only for insert-after-hint.
> I think the most updated Dinkumware library may have fixed this so
> that both are O(1).

Actually I think the standard says insert after hint. But logically, it should be insert before hint (otherwise how would you hint to insert at the start, before begin()). So VC++ has it right, but added the before/after thing to follow both the standard and the logical version of "hint".

Someone tried to fix it, but since libraries have started checking before and after, the change was rejected:

http://www.comeaucomputing.com/iso/lwg-closed.html#192

Tom



Sat, 24 May 2003 03:00:00 GMT  
 <string>,memory access violation

Quote:

> Previously, Craig Powers wrote in microsoft.public.vc.stl:

> > > Well, yes. For associative containers, insert's iterator argument is
> > > just a hint, but if you're using that form of insert, hopefully you
> > > have the right iterator, and the value you're inserting should come
> > > just before it

> > Correct according to the standard, but it's not what the VC++ library
> > does.  VC++ library has O(1) complexity only for insert-after-hint.
> > I think the most updated Dinkumware library may have fixed this so
> > that both are O(1).

> Actually I think the standard says insert after hint. But logically,
> it should be insert before hint (otherwise how would you hint to
> insert at the start, before begin()). So VC++ has it right, but
> added the before/after thing to follow both the standard and the
> logical version of "hint".

Oops, my mistake!  Sorry, Doug!  So Doug was correct, but that is not
guaranteed by the standard and the behavior that is guaranteed by the
standard is not provided by the VC++ library.

Quote:
> Someone tried to fix it, but since libraries have started checking
> before and after, the change was rejected:

That's an odd reason to reject it.  If libraries are in fact checking
both before and after, I don't see that the proposed resolution would
require any change.  AFAICS, the last STLPort that I was using would
meet the proposed complexity requirements, as well as the current
complexity requirements.

I was aware that the way that VC++ (and some but not all of the other
libraries) do it is widely considered the only sensible way of doing
it and that the complexity requirement in the standard was considered
to be a mistake.



Sat, 24 May 2003 03:00:00 GMT  
 <string>,memory access violation

Quote:

>Previously, Craig Powers wrote in microsoft.public.vc.stl:
>> Correct according to the standard, but it's not what the VC++ library
>> does.  VC++ library has O(1) complexity only for insert-after-hint.
>> I think the most updated Dinkumware library may have fixed this so
>> that both are O(1).

>Actually I think the standard says insert after hint. But logically, it should be insert before hint (otherwise how would you hint to insert at the start, before begin()). So VC++ has it right, but added the before/after thing to follow both the standard and the logical version of "hint".

>Someone tried to fix it, but since libraries have started checking before and after, the change was rejected:

>http://www.comeaucomputing.com/iso/lwg-closed.html#192

>Tom

Thanks for the clarifications.

--
Doug Harrison [VC++ MVP]
Eluent Software, LLC
http://www.eluent.com
Tools for Visual C++ and Windows



Sat, 24 May 2003 03:00:00 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. Access Violation with map<string,xxx>

2. <<<<<<<Parsing help, please>>>>>>>>

3. Access Violation in <xlocale>

4. File Format conversion, ascii freeform -->.csv <-->.wk1<-->dbf<-->?HELP

5. <<<>>>Need C code advice with functions and sorting.<<<>>>

6. <><><>HELP<><><> PCMCIA Motorola Montana 33.6

7. >>>Windows Service<<<

8. Accessing Video Memory <HELP>

9. >> An Access Violation Occurred While Trying to copy the file <<

10. Warnings using STL Map<string,string>

11. conflict using string from <string> and strstr fucntion from <string.h>

12. proposal: <basic.h>, <pascal.h>, <fortran.h>, <cobol.h>

 

 
Powered by phpBB® Forum Software