[To make sense of evil macro errors, I often end up resorting to looking at the preprocessed source.]

Sure thanks Dominique! But I am 100% sure there is no redefinition of new in our code here. We use another version "customNew" to use a safer "new".

Joaquin,

I forgot to mention that changing "Use preprocessed headers" to No/Yes did not make a difference. I confirmed this by running the stand alone test program in both modes and it was successful in both. So I was thinking of ruling that possibility out.

About the steps you asked me to follow to experiment to narrow down the problem, I will do that today and reply to you.

Thanks,

Ram

On Wed, Sep 21, 2016 at 8:36 PM, Dominique Devienne <ddevienne@gmail.com> wrote:

On Wed, Sep 21, 2016 at 4:56 PM, Joaquin M López Muñoz <joaquinlopezmunoz@gmail.com> wrote:

El 21/09/2016 a las 13:58, Ram escribió:

Yes, it shows that the problem seems not to be really connected to Boost.MultiIndex.
My hunch is this is related to the precompiled header effect you talked about some
posts ago, or that there's an evil macro affecting this very simple code.

To make sense of evil macro errors, I often end up resorting to looking at the preprocessed source.
Right-click your .cpp file in Visual Studio, Properties, Configuration Properties, C/C++, Preprocessor,
and change Preprocess to a File to Yes (/P). Then CTRL-F7 that file, and look for the .i on your disk.
The file will be big, but look for your own code in there, at the end, and related to the error you get,
and if a macro replaced your program text in an unexpected manner, you'll know the evil macro's name
(the original name in your code, now replaced to some crap that doesn't compile), and can try to
find it in the header you #include (directly or not). Not sure if this works with precompiled headers. --DD

_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users