BUG: autoexp.dat is wrong for std:basic_string 
Author Message
 BUG: autoexp.dat is wrong for std:basic_string

Hello,

The configuration for std::basic_string for the UNICDE Version is wrong! But
there is not solution to display the correct value in the de{*filter*} for
string less than 8 characters !!!

Version: VS.NET

Problem:
A variable of type std::string will not be display correctly in the
auto/local/watch-Window if the string is less than 8 characters and the
program is compiled with UNICODE!

Solution:
I found nothing...

Greetings
  Jochen



Mon, 02 Aug 2004 17:20:22 GMT  
 BUG: autoexp.dat is wrong for std:basic_string


Fri, 19 Jun 1992 00:00:00 GMT  
 BUG: autoexp.dat is wrong for std:basic_string

Quote:
> I mentioned this to the de{*filter*} team a long time ago, I'm not sure
> why it didn't concern them more (maybe other bugs were more pressing.)
> Now it might be too late to change, but I did bring it up again.

MS is going to have a whole lot of confused people out there if std::string
does not always display correctly in the de{*filter*}. I spent a couple of hours
trying to figure out why my strings weren't assigning correctly and it turns
out they were - it just wasn't displaying correct results.

I can understand that it's a difficult problem to display a helpful value in
the de{*filter*} with complex data types, but std::string is part of the
standard, and MS ships it with their compiler. It should work!



Tue, 03 Aug 2004 06:47:20 GMT  
 BUG: autoexp.dat is wrong for std:basic_string

Quote:
> > I mentioned this to the de{*filter*} team a long time ago, I'm not sure
> > why it didn't concern them more (maybe other bugs were more pressing.)
> > Now it might be too late to change, but I did bring it up again.

> MS is going to have a whole lot of confused people out there if
std::string
> does not always display correctly in the de{*filter*}. I spent a couple of
hours
> trying to figure out why my strings weren't assigning correctly and it
turns
> out they were - it just wasn't displaying correct results.

> I can understand that it's a difficult problem to display a helpful value
in
> the de{*filter*} with complex data types, but std::string is part of the
> standard, and MS ships it with their compiler. It should work!

I failed to edit my original post, I just did a cut and paste job w/o
reading it.

That first paragraph is a little out of date.  The de{*filter*} team is
definitely addressing this issue.

Jason Shirk
VC++ Compiler Team



Tue, 03 Aug 2004 09:12:39 GMT  
 BUG: autoexp.dat is wrong for std:basic_string

Quote:
>That first paragraph is a little out of date.  The de{*filter*} team is
>definitely addressing this issue.

For .... SP1? :)
... or V8 :(

Dave
--
MVP VC++ FAQ: http://www.*-*-*.com/
My address is altered to discourage junk mail.
Please post responses to the newsgroup thread,
there's no need for follow-up email copies.



Tue, 03 Aug 2004 15:56:03 GMT  
 BUG: autoexp.dat is wrong for std:basic_string

Quote:
> >That first paragraph is a little out of date.  The de{*filter*} team is
> >definitely addressing this issue.

> For .... SP1? :)
> ... or V8 :(

Expect it this year.  That's as specific as I can get, sorry.

Jason Shirk
VC++ Compiler Team



Wed, 04 Aug 2004 03:50:14 GMT  
 BUG: autoexp.dat is wrong for std:basic_string


Quote:
> This is a known issue.
...
> Better yet, you could write an addin that does exactly what you need
> (search for EEAddIn in the online help.) In fact, I've done just
> that, the code is attached.

> Compile this file with:

> cl /LD /EHsc /O2 EEStdString.cpp

I was looking through the code and had a few questions.  What is
"GetRawBytes?"  It's not documented anywhere I can find, nor is it in any
header I have -- granted I'm using VC6 at the moment, but still.  Also, why
use SEH?  Can that call throw an SE?  It seems like using SEH forces you to
do a few things that are technically illegal (char* c_str = str->c_str(),
for example).  It's a very welcome solution, I just question its
reliability.

Sean



Wed, 04 Aug 2004 04:02:15 GMT  
 BUG: autoexp.dat is wrong for std:basic_string

Quote:
>> For .... SP1? :)
>> ... or V8 :(

>Expect it this year.  That's as specific as I can get, sorry.

OK thanks Jason. I'll assume that's the much talked about but unseen
VC7.1 time frame then :)

Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq
My address is altered to discourage junk mail.
Please post responses to the newsgroup thread,
there's no need for follow-up email copies.



Wed, 04 Aug 2004 05:23:23 GMT  
 BUG: autoexp.dat is wrong for std:basic_string

Quote:

> I was looking through the code and had a few questions.  What is
> "GetRawBytes?"  It's not documented anywhere I can find, nor is it in any
> header I have -- granted I'm using VC6 at the moment, but still.  Also,
why
> use SEH?  Can that call throw an SE?  It seems like using SEH forces you
to
> do a few things that are technically illegal (char* c_str = str->c_str(),
> for example).  It's a very welcome solution, I just question its
> reliability.

I do think it's reliable.  The de{*filter*} team was planning on using it pretty
much as is, FWIW.

Keep in mind, the extension dll is running in the process of the de{*filter*},
not in the process being debugged.  The address space is not shared, so the
raw memory must be copied from the debuggee to the de{*filter*} (my extension
dll).

GetRawBytes is just a helper function that is defined in the example code.
It uses the tagDEBUGHELPER structure, which is documented in VC7, to call
back into the de{*filter*}.

I use SEH to make sure I don't cause the de{*filter*} any trouble.  I want to
ensure no exception, SE or C++ will get passed to the de{*filter*}.

I could have put the C++ specific parts in another function that didn't have
SEH, but I don't think that is necessary.

Only one aspect is technically illegal: I'm not calling the copy ctor.  In
essence, I'm calling placement new to make a copy, but calling memcpy
instead of the copy ctor.  But that's really a non-issue because it's
copying the string between processes.  The debugee couldn't possibly need to
know about the copy.

Jason Shirk
VC++ Compiler Team



Wed, 04 Aug 2004 07:24:10 GMT  
 BUG: autoexp.dat is wrong for std:basic_string


Quote:


> > I was looking through the code and had a few questions.  What is
> > "GetRawBytes?"  It's not documented anywhere I can find, nor is it in
any
> > header I have -- granted I'm using VC6 at the moment, but still.  Also,
> why
> > use SEH?  Can that call throw an SE?  It seems like using SEH forces you
> to
> > do a few things that are technically illegal (char* c_str =
str->c_str(),
> > for example).  It's a very welcome solution, I just question its
> > reliability.

...
> GetRawBytes is just a helper function that is defined in the example code.
> It uses the tagDEBUGHELPER structure, which is documented in VC7, to call
> back into the de{*filter*}.

Oops I feel dumb.  Somehow I didn't notice that the function was defined in
the file I was looking at :p.

Quote:
> Only one aspect is technically illegal: I'm not calling the copy ctor.  In
> essence, I'm calling placement new to make a copy, but calling memcpy
> instead of the copy ctor.  But that's really a non-issue because it's
> copying the string between processes.  The debugee couldn't possibly need
to
> know about the copy.

True.  I went back over the standard and was wrong about c_str() -- it's
valid until a non-const member function is called.  I had thought that the
returned pointer data was much more ephemeral.

Thanks for the reply!



Wed, 04 Aug 2004 08:27:51 GMT  
 BUG: autoexp.dat is wrong for std:basic_string
This works great!

Let me add a couple of things that confused me and may help others implement
the addin-

Note the compile commandline.  Don't create a project. Just copy the
EEStdString.cpp file to an empty directory,
go to the start menu and select the VisStud Net => VisStud Tools =>
VisStudNet Command Prompt command to open a shell,
cd to the directory where you put the cpp file, then execute the command
line shown.

The addin will not appear in the list seen via Addin Manager in the tools
menu. Don't worry. It's loaded when needed.

You do not need to register the addin dll. Regsrv32 will fail to register it
anyway.

I'd suggest commenting out the existing line in autoexp.dat instead of
deleting it. just in case you cannot get this to work.



Quote:
> This is a known issue.

> Many people have suggested using function evaluation in the
> autoexp.dat entry (in other words, use c_str().  I wouldn't recommend
> it however, the performance is worse and weird things can happen.

> That's not to say I don't find funceval (as it's known here) a very
> useful feature.  I just prefer to use it explicitly so when something
> goes wrong, I know it was my fault.

> I posted a solution (which I can't find in google anymore for some
> reason), so here it is again:

> I mentioned this to the de{*filter*} team a long time ago, I'm not sure
> why it didn't concern them more (maybe other bugs were more pressing.)
> Now it might be too late to change, but I did bring it up again.

> Fortunately, you can fix it yourself. It's the autoexp.dat entry that
> is causing the trouble ("C:\Program Files\Microsoft Visual Studio
> .NET\Common7\Packages\De{*filter*}\autoexp.dat" on my machine.)

> You'll see a line that looks like:

> std::basic_string<char,std::char_traits<char>,std::allocator<char>
> >=<_Bx._Buf>

> Get rid of it if you don't like it what it's doing. You'll have to
> expand your strings to see the value, but you already do that for many
> other datatypes already.

> Better yet, you could write an addin that does exactly what you need
> (search for EEAddIn in the online help.) In fact, I've done just
> that, the code is attached.

> Compile this file with:

> cl /LD /EHsc /O2 EEStdString.cpp

> Put the resulting DLL in your path, add

> std::basic_string<char,std::char_traits<char>,std::allocator<char>

> to your autoexp.dat, and you are set. I've left std::wstring as an
> exercise for the reader, and all usual disclaimers apply.

> Jason Shirk
> VC++ Compiler Team



Wed, 11 Aug 2004 04:13:50 GMT  
 
 [ 11 post ] 

 Relevant Pages 

1. BUG: autoexp.dat is wrong for std:basic_string

2. autoexp.dat is wrong for std::basic_string REPOST CODE?

3. BUG with: AutoExp.dat in VC.NET

4. autoexp.dat and function calls

5. autoexp.dat and VC7

6. AutoExp.dat with Interfaces

7. HOWTO: Enhancing AUTOEXP.DAT - Creating Custom Type Evaluator Routines

8. Inheritance in autoexp.dat

9. autoexp.dat there but ignore?

10. Problem with AutoExp.Dat

11. AutoExp.dat and NoStepInto

12. Info on autoexp.dat

 

 
Powered by phpBB® Forum Software