By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,154 Members | 1,041 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,154 IT Pros & Developers. It's quick & easy.

compiling (native) C++ under VC7

P: n/a
I am writing a communications library which makes extensive use of the
STL and templates in general. I am using VC7 to compile because of
alledged better support for templates etc.

However, I have not been able to get a simple question answered. Will my
C++ code be compiled to IL? (I hope not). Is there anyway in the project
settings etc that I can ensure that the binary produced during
compilation is a native binary, i.e. NOT IL code which can be so easily
disassembled, and requires a VM (yuk!)

Question is, how I can be sure that I am producing native binaries
instead of Il (without having to resort to using a dissasembler et, etc.) ?

If I am not convinced that VC7 is really generating native binaries, is
there anyway I can use STL (loki code etc) from VC6?
Mar 12 '06 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Hi Bart!
However, I have not been able to get a simple question answered. Will my
C++ code be compiled to IL? (I hope not).
If you want IL-Code you must "explicit" tell the compiler to do so
(option "/clr"; "use managed extensions" in the "general" tab).
If you have not set this option in your project setting, then the output
will be native.
You can verify this by checking the _MANAGED macro:

#ifdef _MANAGED
#error "This app must be compiled as native code!"
#endif
Is there anyway in the project
settings etc that I can ensure that the binary produced during
compilation is a native binary, i.e. NOT IL code which can be so easily
disassembled, and requires a VM (yuk!)
As I said (see above).
Question is, how I can be sure that I am producing native binaries
instead of Il (without having to resort to using a dissasembler et, etc.) ?
#ifdef _MANAGED
#error "This app must be compiled as native code!"
#endif

If I am not convinced that VC7 is really generating native binaries, is
there anyway I can use STL (loki code etc) from VC6?


I suggest you should upgrate to VC2005, because the new compiler is more
standard conform than VC7...

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/
Mar 12 '06 #2

P: n/a
"Bart Simpson" <ea*********@springfield.com> wrote in message
news:dv**********@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com
I am writing a communications library which makes extensive use of the
STL and templates in general. I am using VC7 to compile because of
alledged better support for templates etc.

However, I have not been able to get a simple question answered. Will
my C++ code be compiled to IL? (I hope not).
Not unless you specifically ask for it.
If I am not convinced that VC7 is really generating native binaries,
Build a simple "Hello, world!" console app, run it on a machine without
..NET installed. If this does not convince you, I don't know what will.

Try to open the executable in MSIL Disassembler (ILDASM) tool. If it
opens, it's a .NET assembly. If there's an error, it's a native
executable.
is there anyway I can use STL (loki code etc) from VC6?


This question does not make any sense to me. STL is almost completely
implemented in header files. Wherever you take it from, it's in source
code form and gets compiled by whatever compiler you are building the
project with. If you don't trust said compiler, I'm not sure how getting
STL headers from elsewhere would help.

Loki is a template library completely unrelated to STL. It's also
distributed in source form, so the same argument applies. Besides, Loki
does not compile on VC6 so it's not clear what you mean by "loki code
from VC6".
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
Mar 12 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.