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

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.

I agree. But, what if just a simple conditional operator was added,
borrowing a bit from excel syntax and adding a leading '!'

std::basic_string=!if(type.internal_len > 16; type.ptr; type.internal)

Possible? Probably. Feasible, you (or rather the de{*filter*} guys) tell
me.

Quote:
>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.

Amen! But please don't add it as default for any types!

But speaking of autoexp.dat, does VC7 honor per-project autoexp.dat's?
That's one thing I wanted for a long time. Also it would be nice if
macrocpp.dat was 1) documented and 2) allowed per-project. Any plans
for any of this (or is it perhaps already supported and I'm just
ignorant)?

/Mike



Tue, 03 Aug 2004 05:58:42 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  
 
 [ 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