stdstring - Developer IT

Managed c++ std::string not accessible in unmanaged c++

- by Radhesham

In unmanaged c++ dll i have a function which takes constant std::string as argument Prototype : void read ( const std::string &imageSpec_ ) I call this function from managed c++ dll by passing a std::string. When i debug the unmanaged c++ code the parameter imageSpec_ shows the value correctly but does not allow me to copy that value in other variable. imageSpec_.copy( sFilename, 4052 ); It shows length of imageSpec_ as 0(zero). If i try copying like std::string sTempFileName(imageSpec_); this statement string new string is a empty string. But for std::string sTempFileName(imageSpec_.c_str()); this statement string gets copied correctly. i.e. with charpointer string is copied correctly. Copying this way will need a major change in unmanaged c++ code. I am building unmanaged code in Visual studio 6.0 and managed c++ in Visual studio 2008. Is there any specific setting or code change in managed c++ that will solve the issue?

Read the article

convert string to argv in c++

- by aaronstacy

I have an std::string containing a command to be executed with execv, what is the best "C++" way to convert it to the "char *argv[]" that is required by the second parameter of execv()? To clarify: std::string cmd = "mycommand arg1 arg2"; char *cmd_argv[]; StrToArgv(cmd, cmd_argv); // how do I write this function? execv(cmd_argv[0], cmd_argv);

Read the article

Avoiding improper std::string initialization with NULL const char* using g++

- by pachanga

A there any g++ options which can detect improper initialization of std::string with NULL const char*? I was in the process of turning some int fields into std::string ones, i.e: struct Foo { int id; Foo() : id(0) {} }; ...turned into: struct Foo { std::string id; Foo() : id(0) {} //oooops! }; I completely overlooked bad 'id' initialization with 0 and g++ gave me no warnings at all. This error was detected in the run time(std::string constructor threw an exception) but I'd really like to detect such stuff in the compile time. Is there any way?

Read the article

unformatted input to a std::string instead of c-string from binary file.

- by posop

ok i have this program working using c-strings. I am wondering if it is possible to read in blocks of unformatted text to a std::string? I toyed arround with if >> but this reads in line by line. I've been breaking my code and banging my head against the wall trying to use std::string, so I thought it was time to enlist the experts. Here's a working program you need to supply a file "a.txt" with some content to make it run. i tried to fool around with: in.read (const_cast<char *>(memblock.c_str()), read_size); but it was acting odd. I had to do std::cout << memblock.c_str() to get it to print. and memblock.clear() did not clear out the string. anyway, if you can think of a way to use STL I would greatly appreciate it. Here's my program using c-strings // What this program does now: copies a file to a new location byte by byte // What this program is going to do: get small blocks of a file and encrypt them #include <fstream> #include <iostream> #include <string> int main (int argc, char * argv[]) { int read_size = 16; int infile_size; std::ifstream in; std::ofstream out; char * memblock; int completed = 0; memblock = new char [read_size]; in.open ("a.txt", std::ios::in | std::ios::binary | std::ios::ate); if (in.is_open()) infile_size = in.tellg(); out.open("b.txt", std::ios::out | std::ios::trunc | std::ios::binary); in.seekg (0, std::ios::beg);// get to beginning of file while(!in.eof()) { completed = completed + read_size; if(completed < infile_size) { in.read (memblock, read_size); out.write (memblock, read_size); } // end if else // last run { delete[] memblock; memblock = new char [infile_size % read_size]; in.read (memblock, infile_size % read_size + 1); out.write (memblock, infile_size % read_size ); } // end else } // end while } // main if you see anything that would make this code better please feel free to let me know.

Read the article

Char* vs std::string

- by Lockyer

Is there any advantage to using char*'s instead of std::string? I know char*'s are usually defined on the stack, so we know exactly how much memory we'll use, is this actually a good argument for their use? Or is std::string better in every way?

Read the article

C++ Program Always Crashes While doing a std::string assign

- by bbazso

I have been trying to debug a crash in my application that crashes (i.e. asserts a * glibc detected free(): invalid pointer: 0x000000000070f0c0 **) while I'm trying to do a simple assign to a string. Note that I'm compiling on a linux system with gcc 4.2.4 with an optimization level set to -O2. With -O0 the application no longer crashes. E.g. std::string abc; abc = "testString"; but if I changed the code as follows it no longer crashes std::string abc("testString"); So again I scratched my head! But the interesting pattern was that the crash moved later on in the application, AGAIN at another string. I found it weird that the application was continuously crashing on a string assign. A typical crash backtrace would look as follows: #0 0x00007f2c2663bfb5 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00007f2c2663bfb5 in raise () from /lib64/libc.so.6 #1 0x00007f2c2663dbc3 in abort () from /lib64/libc.so.6 #2 0x00000000004d8cb7 in people_streamingserver_sighandler (signum=6) at src/peoplestreamingserver.cpp:487 #3 <signal handler called> #4 0x00007f2c2663bfb5 in raise () from /lib64/libc.so.6 #5 0x00007f2c2663dbc3 in abort () from /lib64/libc.so.6 #6 0x00007f2c26680ce0 in ?? () from /lib64/libc.so.6 #7 0x00007f2c270ca7a0 in std::string::assign (this=0x7f2c21bc8d20, __str=<value optimized out>) at /home/bbazso/ThirdParty/sources/gcc-4.2.4/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:238 #8 0x00007f2c21bd874a in PEOPLESProtocol::GetStreamName (this=<value optimized out>, pRawPath=0x2342fd8 "rtmp://127.0.0.1/mp4:pop.mp4", lStreamName=@0x7f2c21bc8d20) at /opt/trx-HEAD/gcc/4.2.4/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../include/c++/4.2.4/bits/basic_string.h:491 #9 0x00007f2c21bd9daa in PEOPLESProtocol::SignalProtocolCreated (pProtocol=0x233a4e0, customParameters=@0x7f2c21bc8de0) at peoplestreamer/src/peoplesprotocol.cpp:240 This was really weird behavior and so I started to poke around further in my application to see if there was some sort of memory corruption (either heap or stack) error that could be occurring that could be causing this weird behavior. I even checked for ptr corruptions and came up empty handed. In addition to visual inspection of the code I also tried the following tools: Valgrind using both memcheck and exp-ptrcheck electric fence libsafe I compiled with -fstack-protector-all in gcc I tried MALLOC_CHECK_ set to 2 I ran my code through lint checks as well as cppcheck (to check for mistakes) And I stepped through the code using gdb So I tried a lot of stuff and still came up empty handed. So I was wondering if it could be something like a linker issue or a library issue of some sort that could be causing this problem. Are there any know issues with the std::string that make is susceptible to crashing in -O2 or maybe it has nothing to do with the optimization level? But the only pattern that I can see thus far in my problem is that it always seems to crash on a string and so I was wondering if anyone knew of any issues that my be causing this type of behavior. Thanks a lot!

Read the article

C++ addition overload ambiguity

- by Nate

I am coming up against a vexing conundrum in my code base. I can't quite tell why my code generates this error, but (for example) std::string does not. class String { public: String(const char*str); friend String operator+ ( const String& lval, const char *rval ); friend String operator+ ( const char *lval, const String& rval ); String operator+ ( const String& rval ); }; The implementation of these is easy enough to imagine on your own. My driver program contains the following: String result, lval("left side "), rval("of string"); char lv[] = "right side ", rv[] = "of string"; result = lv + rval; printf(result); result = (lval + rv); printf(result); Which generates the following error in gcc 4.1.2: driver.cpp:25: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second: String.h:22: note: candidate 1: String operator+(const String&, const char*) String.h:24: note: candidate 2: String String::operator+(const String&) So far so good, right? Sadly, my String(const char *str) constructor is so handy to have as an implicit constructor, that using the explicit keyword to solve this would just cause a different pile of problems. Moreover... std::string doesn't have to resort to this, and I can't figure out why. For example, in basic_string.h, they are declared as follows: template<typename _CharT, typename _Traits, typename _Alloc> basic_string<_CharT, _Traits, _Alloc> operator+(const basic_string<_CharT, _Traits, _Alloc>& __lhs, const basic_string<_CharT, _Traits, _Alloc>& __rhs) template<typename _CharT, typename _Traits, typename _Alloc> basic_string<_CharT,_Traits,_Alloc> operator+(const _CharT* __lhs, const basic_string<_CharT,_Traits,_Alloc>& __rhs); and so on. The basic_string constructor is not declared explicit. How does this not cause the same error I'm getting, and how can I achieve the same behavior??

Read the article

How to initialize an std::string using ""?

- by Mohsin

I'm facing problems with initializing a std::string variable using "" (i.e. an empty string). It's causing strange behavior in code that was previously working. Is the following statement wrong? std::string operationalReason = ""; When I use the following code everything works fine: std::string operationalReason; operationalReason.clear(); I believe that string literals are stored in a separate memory location that is compiler-dependent. Could the problem I'm seeing actually be indicating a corruption of that storage? If so, it would get hidden by my usage of the clear() function. Thanks.

Read the article

How to do case-insensitive compare using std::string?

- by WilliamKF

How do I do a case insensitive string compare using std::string (i.e. strcasecmp())?

Read the article

Can a std::string contain embedded nulls?

- by WilliamKF

For regular C strings, a NULL signifies the end of data. What about std::string, can I have a string with embedded NULLS?

Read the article

Way to get unsigned char into a std::string without reinterpret_cast?

- by WilliamKF

I have an unsigned char array that I need in a std::string, but my current way uses reinterpret_cast which I would like to avoid. Is there a cleaner way to do this? unsigned char my_txt[] = { 0x52, 0x5f, 0x73, 0x68, 0x7e, 0x29, 0x33, 0x74, 0x74, 0x73, 0x72, 0x55 } unsigned int my_txt_len = 12; std::string my_std_string(reinterpret_cast<const char *>(my_txt), my_txt_len);

Read the article

How to do case insensitve comare using std::string?

- by WilliamKF

How do I do a case insensitive string compare using std::string (i.e. strcasecmp())?

Read the article

Visual Studio 2010 compile error with std::string?

- by AJG85

So this is possibly the strangest thing I've seen recently and was curious how this could happen. The compiler gave me an error saying that std::string is undefined when used as a return type but not when used as a parameter in methods of a class! #pragma once #include <string> #include <vector> // forward declarations class CLocalReference; class CResultSetHandle; class MyClass { public: MyClass() {} ~MyClass {} void Retrieve(const CLocalReference& id, CResultSetHandle& rsh, std::string& item); // this is fine const std::string Retrieve(const CLocalReference& id, CResultSetHandle& rsh); // this fails with std::string is undefined?!?! }; Doing a Rebuild All it still happened I had to choose clean solution and then Rebuild All again after for the universe to realign. While it's resolved for the moment I'd still like to know what could have caused this because I'm at a loss as to why when there should be no conflicts especially when I always use fully qualified names for STL.