From the standard

5.2.1 Managed Code Managed code is simply code that provides enough information to allow the CLI to provide a set of core
services, including

•Given an address inside the code for a method, locate the metadata describing the method
•Walk the stack
•Handle exceptions
Store and retrieve security information

This standard specifies a particular instruction set, the Common Intermediate Language (CIL, see Partition III),
and a file format (see Partition II) for storing and transmitting managed code.

Thats what managed data means from the ECMA standard.

Although C# applications are intended to be economical with regards to memory and processing power requirements, the language was not intended to compete directly on performance and size with C or assembly language.

And it means C not C++, but specifically C.

*sigh* okay, I'll bite... apart from probably being true, what is the point of your posts ?

The point is that people were asking the question 'what does managed code' mean. So this is the definition from ECMA.

>And it means C not C++, but specifically C.

Umm? Well it says C so I suppose you're right, but why does it not apply to C++?

>The point is that people were asking the question 'what does managed code' mean

Who was asking these questions?

>The point is that people were asking the question

Please attach your answers to the questions next time and don't litter the boards with it.

Please get a life nv. That has been your challenge for a long time hasn't it?

Oh, but I have a life ! ... I just don't use it.


Remember Mods can view IP adresses.

Yup, once again I could care less about your cheap thrills. The sad thing is that you think I posted unregistered on purpose. What a pathetic loser you are. [...]

Umm? Well it says C so I suppose you're right, but why does it not apply to C++?

I don't think that C++ is as competitive performance wise. The standard mentions C++ when it means C++. The Microsoft OS was primarily coded in C and assembly. Maybe the reason was performance.

/* edited for offensive language -nv, mod*/

>I don't think that C++ is as competitive performance wise. The standard mentions C++ when it means C++. The Microsoft OS was primarily coded in C and assembly. Maybe the reason was performance.

If you know what you're doing, there's no reason that C++ can be any less competitive in the performance stakes than C. If I remember correctly the reason stated for using C in the 'Microsoft OS' was existing C tools.

I'm just quoting the ECMA standards comittee that worked closely with Microsoft on C#.

>I'm just quoting the ECMA standards comittee that worked closely with Microsoft on C#.

Fair enough, but I wasn't questioning anything that the ECMA had stated.

Name one professional operating system that wasn't build using C.

>Name one professional operating system that wasn't build using C.

I not aware of any, but as C is efficient and has been reasonably stable/portable for quite a while it would probably make sense to code an o/s in C. As C++ is a superset of C, I see no reason that these o/s's couldn't be ported to C++ with a bit of work with no loss in performance.

C with Classes was explicitly designed to allow better organization of programs; "computation" was considered a problem solved by C. I was very concerned that improved program structure was not achieved at the expense of run-time overhead compared to C. The explicit aim was to match C in terms of run-time, code compactness, and data compactness. To wit: Someone once demonstrated a 3% systematic decrease in overall run-time efficiency compared with C caused by the use of a spurious temporary introduced into the function return mechanism by the C with Classes preprocessor. This was deemed unaccpetable and the overhead promptly removed. Similarly, to ensure layout compatibility with C and thereby avoid space overhead, no "houskeeping data" was placed int class objects.

Another major concern was to avoid restrictions on the domain where C with Classes could be used. The ideal - which was achieved - was that C with Classes could be used for whatever C could be used for. This implied that in addition to matching C in efficiency, C with Classes could not provide benefits at the expense of removing "dangerous" or "ugly" features of C. This observation/principle had to be repeated often to people (rarely C with Classes users) who wanted C with Classes made safter by increasing static type checking along the lines of early Pascal. The alternative way of providing "safety," inserting run-time checks for all unsafe operations, was (and is) considered reasonable for debugging environments, but the language could not guarantee such checks without leaving C with a large advantage in run-time and space efficiency. Consequently, such checks were not provided for C with Classes, although some C++ environments do provide such checks for debugging. In addition, users can and do insert run-time checks where needed and affordable.

C allows low-level opperations, such as bit manipulation and choosing between different sizes of integers. There are also facilities, such as explicit unchecked type conversions, for deliberately breaking the type system. C with Clases and later C++ follow this path by retaining the low-level and unsafe features of C. In contrast to C, C++ systematically eliminates the need to use such features except where they are essential and performs unsafe operations only at the explicit request of the programmer. I strongly felt then, as I still do, that there is no one right way of writing every program, and a language designer has no business trying to force programmers to use a particular style. The language designer does, on the other hand, have an obligation to encourage and support a varietly of styles and practices that have proven effective and to provide language features and tools to help programmers avoid the well-known traps and pitfalls.

D&E

Perhaps this explains some stuff.