REALLY mixed source files

[Peter Oliphant]

It occured to me that C++, C# and VB (ok, and J#, are you happy now? : ) are
becoming so close that it makes sense to have a 'langauge' that allows
mixing these in the same source!

That is, if the source file is ".cpp" it compiles as a C++ source, ".cs" a
C# source file, and ".vb" for visual basic source. As long as they are
isolated in this way, the calling convention could make it possible to not
have to choose amongst VB, C++, C# (and, OK, J#) as an 'environment', but
just have VS.NET (in contrast to VS C++.NET vs. VS VB.NET). By calling
convention I mean that, in most cases, methods in any language can be called
from, and classes constructed in another language can be refered to, by
using a slightly different syntax (e.g., C# uses '.' for scoping while C++
uses '::").

I'm guessing this isn't possible right now, but it seems like a natural
extension ot the trend towards unification going on with the languages of
VS.NET. Ultimately, it might even be posible to have 'blocks' of code in one
source file that are really another language. For example, in a ".cpp" have
something like a '#start_block visual basic' with a '#finish_block' ender.
In other words, a sort of extension to the way in-line coding mixes assembly
with high-level languages...

[==P==]

 

[William DePalo [MVP VC++ ]]

That is, if the source file is ".cpp" it compiles as a C++ source, ".cs" a
C# source file, and ".vb" for visual basic source. As long as they are
isolated in this way, the calling convention could make it possible to not
have to choose amongst VB, C++, C# (and, OK, J#) as an 'environment', but
just have VS.NET (in contrast to VS C++.NET vs. VS VB.NET). By calling
convention I mean that, in most cases, methods in any language can be
called ...
I'm guessing this isn't possible right now, but it seems like a natural
extension ot the trend towards unification going on with the languages of
VS.NET.

What is sad to this old dinosaur is that what you describe was possible on
the VAX over twenty years ago.

In truth there were issues - the initialization of the runtimes, necessity
to mark some parameters as "by ref" or "by val" depending on the language -
but it was eminently possible to write an application in C and do numerical
stuff in Fortran.

Just by the way, you can't do what you describe within a single project, but
you can partition an application into assemblies, each of which is written
in the desired language. In fact, it is this ability of .Net that allows for
applications written in J#, say, to use the base class library which was
written in C# and C++.

Regards,
Will

 

[David Ching]

Just by the way, you can't do what you describe within a single project,
but you can partition an application into assemblies, each of which is
written in the desired language.

See
http://groups.google.com/group/micr...9eeb083532f/e388ecba0f64b348#e388ecba0f64b348

for a discussion of how you can mix and match languages within a single
..exe. It works great!

-- David
http://www.dcsoft.com

 

[William DePalo [MVP VC++ ]]

So you are translating between source languages?

If so, and you need to make a change, do you make a change to the original
or the translated source file.

Regards,
Will

 

[Carl Daniel [VC++ MVP]]

So you are translating between source languages?

I guess you didn't read the link. Basically, you can get something out of
C# or VB.NET that the VC++ linker can accept as input (a 'netmodule'), so
you can build a single DLL or EXE that contains code from several languages.

-cd

 

[William DePalo [MVP VC++ ]]

I guess you didn't read the link.

I just scanned it. I thought someone was peddling a tool.

Basically, you can get something out of C# or VB.NET that the VC++ linker
can accept as input (a 'netmodule'), so you can build a single DLL or EXE
that contains code from several languages.

I'm probably being thick (again <g>) but I thought that netmodules were DLLs
that are a kind of sub-assembly to be linked into a a "final" assembly. Good
as far as it goes, but there is still the intervening link step.

Regards,
Will

 

[Ronald Laeremans [MSFT]]

I just scanned it. I thought someone was peddling a tool.




I'm probably being thick (again <g>) but I thought that netmodules were DLLs
that are a kind of sub-assembly to be linked into a a "final" assembly. Good
as far as it goes, but there is still the intervening link step.

Regards,
Will

You end up with a single file assembly that is basically
indistinguishable from builing it all together in the first place. Not
sure that matches your understanding or not.

Note that this is a new 2005 feature. In 2002 and 2003 .netmodules could
not be used to build a single file assenmbly. They could only be used as
parts of a multi-module assembly as you describe.

Ronald Laeremans
Visual C++ team

 

[William DePalo [MVP VC++ ]]

You end up with a single file assembly that is basically indistinguishable
from builing it all together in the first place. Not sure that matches
your understanding or not.

Note that this is a new 2005 feature. In 2002 and 2003 .netmodules could
not be used to build a single file assenmbly. They could only be used as
parts of a multi-module assembly as you describe.

That's cool.

I didn't realize that building an assembly from netmodules w/2003 didn't
yield a single file assembly.

And in the give-'em-an-inch-and-they'll-take-a-mile-department ...

.... wouldn't it be cool if you could just add, say, C# and C++/CLI source
files to the same project and be done with it. ;-)

Regards,
Will

 

[Ronald Laeremans [MSFT]]

That's cool.

I didn't realize that building an assembly from netmodules w/2003 didn't
yield a single file assembly.

And in the give-'em-an-inch-and-they'll-take-a-mile-department ...

.... wouldn't it be cool if you could just add, say, C# and C++/CLI source
files to the same project and be done with it. ;-)

Regards,
Will

Seeing that the build model is completely different (C# is
build-everything-at-once, C++ is per file compilation) that would be
extremely hard and probably have surpriszing semantics if we were to try.

Ronald

 

[William DePalo [MVP VC++ ]]

Seeing that the build model is completely different (C# is
build-everything-at-once, C++ is per file compilation) that would be
extremely hard and probably have surpriszing semantics if we were to try.

It's just another case of things appearing easy to those who aren't tasked
with the job.

Regards,
Will