Posts Tagged “c++”

Calls to system() in Windows

Published on March 22, 2011

I recently ran into a stupid problem using the system() call in C++ on Windows platforms. For some strange reason, calls to system() get passed through the cmd /c command. This has some strange side effects if your paths contain spaces, and you try to use double quotes to allow those paths. From the cmd documentation:

If /C or /K is specified, then the remainder of the command line after the switch is processed as a command line, where the following logic is used to process quote (“) characters:

  1. If all of the following conditions are met, then quote characters on the command line are preserved:
    • no /S switch
    • exactly two quote characters
    • no special characters between the two quote characters, where special is one of: &<>()@^|
    • there are one or more whitespace characters between the two quote characters
    • the string between the two quote characters is the name of an executable file
  2. Otherwise, old behavior is to see if the first character is a quote character and if so, strip the leading character and remove the last quote character on the command line, preserving any text after the last quote character.

As you can see from this documentation, if you have any special characters or spaces in your call to system(), you must wrap the entire command in an extra set of double quotes. Here’s a working example:

string myCommand = "\"\"C:\\Some Path\\Here.exe\" -various -parameters\"";
int retVal = system(myCommand.c_str());
if (retVal != 0)
    // Handle the error

Note that I’ve got a pair of quotes around the entire command, as well as a pair around the path with spaces. This requirement isn’t apparent at first glance, but it’s something to keep in mind if you ever find yourself in this situation.

User Defined Messages in Visual C++

Published on August 27, 2009

Before we get to the meat of this article, here’s a quick introductory story. The next release of Paper Plus will only allow one instance of the application to run at a time. One strange bug I ran into during the testing phase of this new feature, was the case where the application was minimized to the system tray. If a previous instance is already running (and minimized), I wanted the action of trying to start a new instance to restore the old one. For a number of reasons which I won’t go into, I couldn’t get the level of control I needed to restore things properly. So, to get things working, I turned to user defined messages which, happily, solved my problem. Here’s a quick guide to getting custom messages up and running in a Visual C++ application.

Step 1: Define the Message ID

This is straightforward, but you’ll need to make sure your definition appears in the appropriate place. I put mine in stdafx.h, which is included by nearly every file in the project.


Step 2: Add the Message to a Message Map

Next, your custom message needs to be added to the appropriate message map. I added mine to the message map down in my CFrameWnd derived class. Here’s how the entry looks in my case:


Step 3: Implement the Custom Callback

Your callback function declaration must adhere to the appropriate form, as shown below:

LRESULT MyCustomCallback(WPARAM wParam, LPARAM lParam);

Custom message callbacks must always return an LRESULT, and must accept two parameters: a WPARAM and an LPARAM (down under the covers, both are simply pointers of varying types).

Once you’ve got the declaration in place, it’s time for the definition:

LRESULT CMainFrame::MyCustomCallback(WPARAM wParam, LPARAM lParam)
    // Do something clever here
    return 0; // Make sure to return some value

Step 4: Post Your Custom Message

Now that we’ve got our custom message callback installed, we need to post our new message in the appropriate place. I decided to use the SendMessageTimeout function, based on some code I saw which used this function to prevent the application from hanging. Here’s a variant of the code I used:

DWORD_PTR dwResult = 0;
// The hWnd parameter below is a handle to the window this message
// should be posted to. Setting this up is not shown, in order to keep
// this article as short as possible.
SendMessageTimeout(hWnd, WM_MYCUSTOMMESSAGE, 0, 0,
                   SMTO_ABORTIFHUNG, 5000, &dwResult);

And that’s it! Being able to post your own messages can help you out of some sticky situations, and lets you take control of your application in some interesting new ways.

GCC Dynamic Section Sizes Error

Published on March 13, 2009

I ran into a weird problem in one of our build scripts at work today. We compile our tools across a number of platforms and architectures, and I ran across this issue on one of our oldest boxes, running RedHat 9. Here’s the horrible error that I got when linking:

/usr/bin/ld: undefined versioned symbol name std::basic_string<char, std::char_traits<char>, std::allocator<char> >& std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_replace_safe<char const*>(__gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, __gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, char const*, char const*)@@GLIBCPP_3.2
/usr/bin/ld: failed to set dynamic section sizes: Bad value

It seems as if the standard C++ libraries on this system were compiled with gcc 3.2, while the version we’re using to build our tools is 3.2.3. Unfortunately, the 3.2 compiler isn’t installed on the system, and I’m not sure where we would find it for RH9 anyway. Thankfully, I found a workaround for this problem. Our link step originally looked like this:

gcc -shared -fPIC -lstdc++ -lrt -lpthread -o {list_of_object_files}

I found out that by moving the standard libraries to the end of the line, the problem disappeared. Here’s the new link step:

gcc -shared -fPIC -o {list_of_object_files} -lstdc++ -lrt -lpthread

I don’t fully understand why ordering should matter during the link step, but by putting the standard libraries last, we were able to get rid of this error. If you understand the root cause of this, please leave a comment explaining. I’d love to know more about why changing the order makes a difference.

C++ is Broken

Published on July 11, 2005

I do a fair amount of C++ programming these days, thanks to my new career at IBM. C++ is my strongest language, and the first language I picked up when I began programming. As such, it’s fairly special to me. However, the more I time I spend with C++, the more I come to see how broken it is.

For instance, why are strings not a base type? Character arrays simply do not suffice. I am aware of the STL string class (and I make use of it), but adding on this capability after the fact seems cheap. Strings should be a first-class object, and should have all the associated operators directly available (==, +=, etc.). And regular expressions should be directly available for strings, since they are so incredibly useful. There are tons of places in my code where access to regular expressions would make my life profoundly simple. For example, take Perl’s match operator (m//). How many Perl programs out there do not make use of this operator? My guess is that the number is very low. It’s no different in C++; reg-exes could be used all over the place.

Other glaring omissions also crop up. Where is the foreach loop construct? Why use #include instead of packages or modules? Where are the array operators (shift, unshift, pop, push)?

There’s no question that C++ is a robust language. It’s fast, gives the programmer complete control (both a blessing and a curse), and it has an incredible user base (which results in excellent support when you need it). But it’s clearly dated. Will we still hold on to this language in 20 years? Or will something innovative finally come along to push it aside? Let’s hope for the latter.

Copyright © 2004-2019 Jonah Bishop. Hosted by DreamHost.