[RESOLVED] First foray into libboost

A few days ago I installed libboost. To get myself started I decided to follow the boost regex example shown here. It looked simple enough and my resultant code looks like this:-

Code:

---

#include <string>
#include <boost/regex.h>

using namespace std;
using namespace boost;

bool validate_card_format(const string s)
{
  static const boost::regex e("(\\d{4}[- ]){3}\\d{4}");
  return regex_match(s, e);
}

---

However, this gives me the following compiler errors:-

Quote:

---

error C2039: 'regex' : is not a member of 'boost'
error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
error C2146: syntax error : missing ';' before identifier 'e'
error C3861: 'e': identifier not found
error C3861: 'regex_match': identifier not found

---

I guess it isn't enough just to #include <boost/regex.h>. What have I missed out :confused:

I don't have my boost here, but shouldn't it be
#include <boost/regex.hpp>?

Thanks Richard, you're right.

In case there are any active Boost users here, maybe someone could give me a bit more advice....

After #including the correct header file I can now run my app, complete with the above regex test. But it only works if I build my app in Release mode. In Debug mode, any attempt to call my sample regex function (validate_card_format) leaves me with an unhandled exception.

I've posted a question on the Boost users forum but in the meantime, does anyone here know if I need to install (or build) Debug versions of the Boost libs as well as the supplied (Release) versions?

I have used boost a bit, but I avoided any part which required a separate library (such as the regex support).

If the compiler you are using has a tr1 implementation, you may want to use the <regex> header from your compiler instead of boost. I use Visual Studio 2008, which has a tr1 implementation of regex.

Note that the include is instead:

Code:

---

#include <regex>

---

and the namespace is std::tr1.

Best regards,
John

Quote:

---

Originally Posted by John E

After #including the correct header file I can now run my app, complete with the above regex test. But it only works if I build my app in Release mode. In Debug mode, any attempt to call my sample regex function (validate_card_format) leaves me with an unhandled exception.

---

Could be caused by a mismatch in the runtime library used by the boost library and your application.
In my company we use separate binaries of the boost libraries for debug and release builds. They are not from the boost website, however, but build with the bjam stuff exactly to solve these kinds of problems.

I've noticed something that might be significant.... I'm building the app (both versions) to include an embedded manifest. However, the Debug version (that's the one that doesn't work) builds 2 x manifest files:- one called test_app.exe.intermediate.manifest and the other called test_app.exe.embed.manifest. However, the Release version (which works) only builds one manifest file, namely:- test_app.exe.intermediate.manifest. In fact, there's nothing else on my system at all that has a file ending in "embed.manifest". I wonder if that's significant :confused:

I would create the debug version of the lib. Using bjam is quite simple and you can build the complete libs in one step. It just takes some time ...

Thanks Richard - but this morning, I think I've tracked the problem down. I've created a couple of very simple projects and typed in the same regex code sample. The Release versions run fine. But the Debug versions fail if the compiler is left at its default setting of "Multi-threaded Debug DLL". If I change that to "Multi-threaded Debug" the app mysteriously starts working.

I've reported this on the Boost mailing list so hopefully, someone might be able to reproduce it.

Quote:

---

Originally Posted by John E

Thanks Richard - but this morning, I think I've tracked the problem down. I've created a couple of very simple projects and typed in the same regex code sample. The Release versions run fine.

---

What is the runtime library that the release version is linking to?

Quote:

---

But the Debug versions fail if the compiler is left at its default setting of "Multi-threaded Debug DLL". If I change that to "Multi-threaded Debug" the app mysteriously starts working.

---

And I bet that the Release version doesn't work either if you had a different runtime specified.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by Paul McKenzie

What is the runtime library that the release version is linking to?

---

In fact Paul I'm using Boost's pre-built binaries that got installed by the Boost installer. Boost somehow chooses the right library automatically, without me needing to explicitly link. If I build with Multi-threaded Debug DLL selected (that's the option that doesn't work) Boost links statically to libboost-regex-vc80-mt-gd-1_40.lib. I found that out experimentally by renaming the libs until it wouldn't link any more. And I'm assured by John Maddock (maintainer of Boost) that this is the correct library. I can also link dynamically to Boost, in which case it links to boost-regex-vc80-mt-gd-1_40.lib (without "lib" at the start). That's the DLL's link lib which doesn't work either. This morning I sent John my sample app and it apparently worked fine at his end :cry:

Having said that, Boost is now up to V1.41 or even 1.42 so he's almost certainly using a newer version.

I had a flash of inspiration.... I decided to find every file on my system with the name libc*.lib and rename it temporarily - except for the ones pertaining to VC++2005. This should at least guarantee that I'm using the right libs. But unfortunately, the same problem persists.

Let's assume for the sake of argument that Boost's libs are okay (which I doubt). Is there any way that Visual Studio could be linking to the wrong C runtime libs? e.g. it's linking to the normal C runtime instead of the Debug runtime? Or maybe it's linking to libcpmtd.lib when it should be using libcmtd.lib??

I'm not specifying any C runtime lib. I'm just leaving it to the linker to select the right one. I don't think it'll be getting this wrong but I can't think of anything else. :confused:

[Edit...] Ah.... things just got interesting! I just renamed ALL the libc libs and tried rebuilding. With Multi-threaded Debug selected the linker complains about not being able to find libcmtd.lib. But with Multi-threaded Debug DLL selected, the app builds perfectly :confused:

[Edit...] Nope, worked that one out.... with Multi-threaded Debug DLL it uses msvcrtd.lib in place of libcmtd.lib

Quote:

---

Originally Posted by John E

I've noticed something that might be significant.... I'm building the app (both versions) to include an embedded manifest. However, the Debug version (that's the one that doesn't work) builds 2 x manifest files:- one called test_app.exe.intermediate.manifest and the other called test_app.exe.embed.manifest. However, the Release version (which works) only builds one manifest file, namely:- test_app.exe.intermediate.manifest. In fact, there's nothing else on my system at all that has a file ending in "embed.manifest". I wonder if that's significant :confused:

---

Quote:

---

Originally Posted by John E

Let's assume for the sake of argument that Boost's libs are okay (which I doubt). Is there any way that Visual Studio could be linking to the wrong C runtime libs? e.g. it's linking to the normal C runtime instead of the Debug runtime? Or maybe it's linking to libcpmtd.lib when it should be using libcmtd.lib??

---

Yes, your application could be linking to a different runtime library than boost, even if both link to the "Debug DLL" version (or whatever). The reason for this is that Microsoft has a very intricate system to support different versions of the same runtime libraries on your system. For example, one application or dll could link to version 8.0.1 and another to 8.0.2.0123. Both versions have exactly the same file name.
Which version is used exactly is specified by the manifest. To check this for a dll or exe, I use a tool called XN resource editor. If you open a dll with it, you can see the exact version under 'XP Theme Manifest' -> 'Version'. The tool doesn't work for .lib files, but you can search for the version number in those with a normal text editor.

Quote:

---

I'm not specifying any C runtime lib. I'm just leaving it to the linker to select the right one. I don't think it'll be getting this wrong but I can't think of anything else. :confused:

---

I'm not sure what the default settings are in VS2005, but it could be that this is affected by Windows updates. To make sure you are using the same runtime library as is used by your boost binaries, you have to specify in the manifest of your project which version should be used.

Thanks D_Drmmr. That tool was very helpful although I've ended up more confused now than I was before! Maybe someone can make some sense of this.

If I build my app without Boost support (Debug or Release mode) it uses CRT 8.0.50608.0. If I add Boost support, the manifest then specifies a second CRT. So I need 8.0.50608.0 and also 8.0.50727.4053, which is the one used by Boost.

Now, if I look in C:\Windows\WinSxs\Manifests I see that I have 3 x CRT versions installed:-

8.0.50727.4053
8.0.50727.42
8.0.50727.762

and 1 x Debug CRT version, namely:-

8.0.50727.42

Note that I don't have 8.0.50608.0, which seems to be the one used by my copy of VS..! Surely it wouldn't have installed itself and not installed the CRT that it needs? Or is it the case that CRTs are backwards compatible (i.e. more recent ones can be used in place of older ones?)

And here's another strange thing... I can run my apps in Release version without needing to do anything special (apart from generating their manifests). However, in the case of the Debug versions, they'll only run if I copy msvcr80d.dll, msvcp80d.dll and msvcm80d.dll into C:\Windows\System32.

This isn't making sense to me yet. Can anyone else understand it?

[Edit...] Here's a thought.... is it possible that 8.0.50727.4053 is actually later than 8.0.50727.42? In other words, my installation includes a recent enough version to run Boost's libs in Release mode but not in Debug mode. That would make a lot of sense - but how then do I go about obtaining the required DebugCRT?

Quote:

---

Originally Posted by John E

Here's a thought.... is it possible that 8.0.50727.4053 is actually later than 8.0.50727.42? In other words, my installation includes a recent enough version to run Boost's libs in Release mode but not in Debug mode.

---

Sorry to answer my own post, but yes - that seems to be exactly the problem.

8.0.50727.42 is dated 23rd Sep 2005
8.0.50727.4053 is dated 12 Aug 2009

So how do I go about updating my DebugCRT to obtain the more recent version? When I first installed VS8 it gave me the opportunity to upgrade (i.e. upgrade VS8) but the upgrade wouldn't run unless I upgraded the whole of XP (which seemed a bit draconian, given that I'm already struggling for disk space). Is there some way that I can just inslall the more recent DebugCRT?

Quote:

---

Originally Posted by John E

If I build my app without Boost support (Debug or Release mode) it uses CRT 8.0.50608.0. If I add Boost support, the manifest then specifies a second CRT. So I need 8.0.50608.0 and also 8.0.50727.4053, which is the one used by Boost.

---

I would recommend not mixing different versions of the CRT. For one, you're asking for trouble when you need to distribute your binaries. If all your dll's link against the same version, you can always distribute that version with your binaries.

Quote:

---

Note that I don't have 8.0.50608.0, which seems to be the one used by my copy of VS..! Surely it wouldn't have installed itself and not installed the CRT that it needs? Or is it the case that CRTs are backwards compatible (i.e. more recent ones can be used in place of older ones?)

---

I think that's where the 'intricate' part of the whole thing really kicks in. I'm not sure how Windows keeps track of the different versions on your system and, to be honest, I really don't want to know. ;)

In my opinion, the best you could do is to figure out how to build the boost libraries yourself using bjam. That way you can make sure they link against the correct CRT. Also, when you decide to update boost, you won't be facing the same problem all over again.

Quote:

---

Originally Posted by D_Drmmr

In my opinion, the best you could do is to figure out how to build the boost libraries yourself using bjam. That way you can make sure they link against the correct CRT. Also, when you decide to update boost, you won't be facing the same problem all over again.

---

I must admit, I'm tempted to do that. In fact, I tried it yesterday but gave up after a few build problems.

This morning I bit the bullet and updated both XP (to SP3) and VS8 Express (to SP1). I've lost a whopping 500MB of disk space that I could ill afford and (whoopee!!) I've got an extra DebugCRT installed. The bad news is that it's only taken me up to 8.0.50727.762. So I still haven't attained the much needed 8.0.50727.4053. I guess there must be a SP2 lurking somewhere for VS8 Express. Or (knowing Microsoft) they probably left the Express Edition at SP1 and I'll now have to pay a lot of money (and lose a lot more disk space) by installing the full product (which I don't otherwise need).

Personally, I've been a Microsoft fan for many years but I'm beginning to understand why they're so disliked.... :(

I just wanted to document the solution to this problem because I hit exactly the same situation today and I'd completely forgotten how to solve it. The solution is described here.