Skip navigation

Category Archives: C/C++

My first language was Java, and though I’ve been working with C++ for a bit now certain things still trip me up now and again.  While working on a class that tokenizes std::string objects based on std::string delimiters, I came across the use-case of wanting to modify char data returned from a string’s c_str() method.  Since this returns a const char* I tried

char* cstr = myStr.c_str();

but that throws a compiler error because it attempts the quite rightly illegal conversion between a const pointer and a mutable one.  In Java the idiom above re-implemented as below would be legal

final String testS = "final";
String testS2 = testS;
testS2 = "mutable";

This is legal in Java only because Java allocates new memory space for testS2 and copies the content of testS into it behind the scenes.  testS remains immutable while testS2 is mutable.  One simple way to obtain the same result in C/C++ is via strncpy() as follows:

std::string myString = "Hello"

const char* cstr_final = myString.c_str();

char cstr_mut[sizeof(cstr_final)];

std::strncpy(cstr_mut,cstr_final,sizeof(cstr_final);

With that cstr_mut is a fully modifiable clone of the content pointed to by cstr_final 🙂

side note: its obvious from my other posts that I enjoy including pictures– I have to advise against entering the search query “c string” in google image search while at work as it seems that there is an article of particularly risque lingerie by that name  *facepalm*

6793050_f260

Advertisements

If you’ve ever tried to keep an instance of std::stringstream or another stream wrapper class as a member value in one of your own classes, you may have run across this set of friendly compiler errors:

“ios_base.h:779: error: ‘std::ios_base::ios_base(const std::ios_base&)’ is private.

iosfwd:55: error: within this context

iosfwd: In Copy Constructor ‘std::basic_stringstream…

streambuf:794: error” ‘std::basic_streambuf… is private

iosfwd:55: error: within this context

iosfwd: In Copy Constructor ‘std::basic_stringstream…”

This occurs because i/o streams cannot be copied!  You’d think they would bold that on every *stream page in the cplusplus.com/reference but sadly they don’t.  Anyway, if you want to work with streams you need to either pass around references/pointers to them or, preferably, create them on the stack as needed and let them pop off automatically.  More discussion available on StackOverflow here

crossed

For JVM/DVM Java memory usage, the Eclipse Memory Analyzer Tool (MAT)

For native memory debugging (allocations in C/C++ etc.), Valgrind is awesome and supports quite a few platforms!

st-george-dragonThe Chivalrous Valgrind Logo!

As I understand the issue, there can be multiple causes for this error (not building against the correct machine architecture, permissions set incorrectly, etc.) but for me none of these common issues solved the problem.  I was in a bit of a unique situation you see– I had built an application as a static library to be utilized by a different application, and I wanted to return to development of the original application.  This required rolling its settings back to build as an executable rather than a static library.  I did this by changing the artifact extension from static library (.a) to executable, but I noticed the executable icon in eclipse was still a ‘plugin symbol’ (jigsaw puzzle piece) rather than a ‘go symbol’ (circle with an inscribed arrow pointing right).  After much googling to little effect and executing the program from the terminal to verify that it produced the same error [cannot execute binary file and ‘echo $?’ to see the last exit code yields 126], I took another look at the command string eclipse was generating and saw the odd switch ‘-dynamiclib’ appended after the various ‘-framework x’ linker switches I needed.  Looking deeper into my linker settings I noticed that the ‘Shared’ box was checked under ‘Shared Library Settings’. The solution of course was to uncheck this box, which removed -dynamiclib from the command string.

In sum, the missing step was as follows:

1. Go to project->properties->C/C++ Build->Settings->MacOS X C++ Linker->Shared Library Settings and uncheck the ‘Shared (-dynamiclib)’ box.  I don’t know why that was checked to begin with since I was building static libs before, but whatever the case this fixed the problem and made the program fully executable again.