Are you using that compiler on both boxes? even if you are, are there different library versions on the different boxes? I, for one, am still not clear on what you see on one box that you don't see on another.
But here's an example session (having nothing to do with SlickEdit) of GCC and GDB using your second example snippet of code. This on on a windows box using MinGW/GCC 4.6.1.
The code:
#include <iostream>
#include <string>
using namespace std;
int main()
{
string s = "Hello World.";
string d = s;
cout << s << endl;
cout << d << endl;
}
The GDB session:
C:\temp>gdb test.exe
GNU gdb (GDB) 7.2
Reading symbols from C:\temp/test.exe...done.
(gdb) start
Temporary breakpoint 1 at 0x40134e: file C:\temp\test.cpp, line 7.
Starting program: C:\temp/test.exe
[New Thread 6216.0x708]
Temporary breakpoint 1, main () at C:\temp\test.cpp:7
7 {
(gdb) n
8 string s = "Hello World.";
(gdb) n
9 string d = s;
(gdb) print s
$1 = {static npos = 4294967295,
_M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0xa3180c "Hello World."}}
(gdb) n
10 cout << s << endl;
(gdb) print d
$2 = {static npos = 4294967295,
_M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0xa3180c "Hello World."}}
(gdb)
Note that GDB doesn't show any data fields for the `std::string` objects except the C-style string data pointed to by `_M_p`. That's because the `<string>` header is using some trickery that hides the other data in memory that resides before the string data. When member functions need to access that data other fields, they call an inline function, `_M_rep()` that adjusts the `_M_p` pointer to get at the other data (which includes such things as `_M_length`, `_M_capacity`, and `_M_refcount`). If this is what's causing your problem, take a look at the `<c++/4.6.1/bits/basic_string.h>` header (or wherever basic_string.h might live on your system) for details on what's going on.