REALLY mixed source files

  • Thread starter Thread starter Peter Oliphant
  • Start date Start date
P

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==]
 
Peter Oliphant said:
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.
Click to expand...

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
 

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
 
William said:
So you are translating between source languages?
Click to expand...

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
 
Carl Daniel said:
I guess you didn't read the link.
Click to expand...

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.
Click to expand...

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
 
William said:
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
Click to expand...
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
 
Ronald Laeremans said:
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.
Click to expand...

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
 
William said:
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
Click to expand...
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
 
Ronald Laeremans said:
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.
Click to expand...

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

Regards,
Will
 
Back
Top