Board index » cppbuilder » Re: ".NET" for Dummies !

2004-09-17 02:05:29 PM
cppbuilder11
e.g. Mono and the code cannot be used directly by other .NET applications
- but it´s C++ code compiled to IL code and therefore needs the framework to run.
(At least the IL compiler)
or your code has to be used from other .NET code.
I can us managed objects, but i´m not forced to - only when i´m using other .NET code.
For example C++/CLI gives you some features C++ doesn´t have,
e.g. specifying the underlying type of enumerations.
some minor complains of the compiler (e.g. __fastcall will be ignored -
but that isn´t C++ standard either).
I admit that accessing memory of VCL objects is easier than that of .NET
objects from C++ code. But that´s by design, since .NET objects are manged
objects which may be moved around by the managed heap manager,
you have to pin them before you are able to access their memory
(e.g. array) from native C++, therefore C++/CLI is easier.
Currently you have to map all C++ objects to handle functions so that
they may be used from other languages or use some other standards
like CORBA or COM.
In .NET you simply reference the DLL and use the C++/CLI objects directly.
And, yes, the C++ objects still cannot be used directly.
map the objects to single functions and use handles to represent the objects.
code running in an virtual environment.
native code. But it´s more secure than native code. The same is to .NET
during compilation (e.g. when you are running a .NET application in the
internet area). You may remove all code calling restricted areas or
deny the application to run.
E.g. derivation and using handles in native objects - that will be added in future versions.
[snip]
Andre
 

"Andre Kaufmann" <## XXXX@XXXXX.COM ##>writes:
[snip]
runtime of an application doesn't make it secure or insecure. A Java
app running on a bug-free Java VM can be insecure, on a thousand
different ways. Same for .NET.
[snip]
--
Oscar
 

That depends on how you define security code injection via stack overflow
cannot occur in a properly written Java runtime by definition.
But i wouldn´t bet on it for 100%.
I think you can´t divide code in 2 classes, secure and insecure.
And that´s what i wrote: more secure
Java and .NET code is more secure than native compiled code,
i didn´t wrote that both make it possible to write 100%
secure code.
The point is at which level the code may be controlled and restricted,
i would call native code running in a virtual machine secure so perhaps
this would be an option for native code downloaded from the web.
Besides i currently don´t need managed code or the security of .NET,
since i don´t write applications for the web / webserver.
But it´s easier to write applications, when you don´t have to care that much
about memory allocation / deallocation or if you compile 100+ source code
files in a few seconds.
Though i still like C++, simply can´t live without templates.
Andre
"Oscar Fuentes" < XXXX@XXXXX.COM >wrote in message news: XXXX@XXXXX.COM ...

{smallsort}

"Mark Jacobs" <markj atty critical dotty co dotty uk>wrote:
not yet fallen. ;-)
--------------------
FLUSH THE JOHNS NOVEMBER 2004!
 

Oscar Fuentes < XXXX@XXXXX.COM >writes:
the language, and if you don't use them your code is not affected.
Further, the .NET features work together with the standard C++
features. That is, you're not limited to having two subsystems in
your program, the "pure" C++ and the "managed" C++ sections. For
example, you can use C++ templates (including STL) on managed C++
garbage-collected pointers, and so on.
While I don't know all the details, I feel that they did an excellent
job of adding the features in a non-intrusive way.
NOTE: I'm not advocating .NET, and am certainly not one to like
Microsoft to widen its monopoly. However, they are fast-tracking the
standardization of these extensions, and in theory they should (or
could) be available in non .NET environments as well, provided the
compiler/runtime correctly implement the langauge features.
Some things that I really like that the extensions offer:
* the ability to declare that a function overrides a virtual
function. If it turns out that it doesn't actually override a
virtual function from the base class, it's a compile-time error.
* the ability to declare that a virtual function does NOT override
a virtual function. (It's "new")
* the ability to declare a class cannot be a base class. ("sealed")
* optional garbage collection in a non-intrusive way. Stroustrup has
wanted this in C++ for years... and it does not HAVE to be
implemented by .NET, I think.
I am concerned about Microsoft's recent history of collecting patents
and then trying to inject their patented "intellectual property" into
standards. If they sandbag these language extensions as patented
extensions, then I'll be thorougly disgusted with them, but so far I'm
really looking forward to the features, though I'd like them to be
implemented in a non .NET environment as well. :)
--
Chris (TeamB);