From the standard

[Unregistered]

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.

[Unregistered]

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.

[nvoigt]

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

[Unregistered]

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

[Sorensen]

>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?

[nvoigt]

>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.

[Troll_King]

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

[nvoigt]

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


Remember Mods can view IP adresses.

[Troll_King]

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*/

[Sorensen]

>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.

[Troll_King]

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

[Sorensen]

>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.

[Troll_King]

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

[Sorensen]

>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.

[Troll_King]

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.

[Sorensen]

That just backs up what I've been stating, and since we're quoting Stroustrup -

Considering C a smaller, faster, and better specified alternative to C++ is another popular fallacy. The C-like subset of C++ is as fast, as well specified, and easier to deal with than C itself. One source of popularity of this fallacy is an unwillingness by some C/Pascal-level programmers not to learn something really new. Another is wishful thinking by some proponents of more advanced languages: after all, if C++ is simply a more complicated C it cannot be a serious competitor to a more advanced language.

[Troll_King]

Yes, that previous post was a positive for C++, however C and C++ have been growing apart. They have separate standards. To say that C++ is a superset of C is also a myth. C has moved on to improve its low level functionality while C++ has striven to improve it's STL.

[Sorensen]

>C has moved on to improve its low level functionality

How?

It's true C has moved on from when C with Classes was concieved, mainly due to the most recent C standard. However, it's an aim of the C++ standards commitee to bring them closer together and the new C++ standard will require as much of C99 be implemented in C++ as possible (if it's ever implemented in a C compiler :) ).

The standard commitees don't work in entire ignorance of what the other is doing, and features added by C99 were to some extent chosen so that they would also be easily included in future implementations of C++.

[Troll_King]

They are moving apart. I'll look for the article. I read it on Bjorne's web site.

[Sorensen]

This was stated by Herb Sutter (Secretary of the ISO/ANSI C++ standards committee) -

C99: The second official ISO/ANSI C Standard, published in 1999. This standard contains much that the C++ committee can be expected to adopt wholesale, or with minor modifications, as part of C++0x. After all, it's clear that the C++ committee values C compatibility, and the C committee has helped us by likewise valuing C++ compatibility, which has made some of C99's features easier to integrate into C++0x than they might otherwise have been. There are still some C99 features, however, that C++0x cannot easily adopt in their C99 form, because conflicting facilities already exist in C++98 (for example, complex is a class template in C++98 and a keyword in C99).

[Troll_King]

see below

[Troll_King]

LinuxWorld.com: With the ratification of the new C99 standard, C/C++ compatibility seems more evasive than ever before. Is backward compatibility with C still one of the goals of C++? If so, what should be done to minimize the gaping chasms between the two languages?

Bjarne Stroustrup: C99 focused on extending the low-level facilities of C in the area of numeric programming. It basically ignored the abstraction facilities and the aims of generality embodied in C++. This makes compatibility harder as C adds more ad hoc, special-purpose facilities, where C++ addresses the same programmer needs through libraries implemented using general-purpose language facilities. An example is C99 variable-length arrays vs. C++'s vector. A more coordinated evolution of the two languages would have avoided this split.

My ideal is still a single language, and it is still technically feasible to merge C++ and C99 into a single, reasonably coherent language. I think such a language could meet every rational technical requirement. However, I'm not sure that the political will is there. For starters, it would require a merger of the C and C++ standards committees; it is not possible to have two different groups of people evolving two languages in parallel. Each committee attracts people who don't share the ideals of the majority of the other and who dislike compromising with that majority. Thus, whereas a single committee fosters a shared community, trust, and compromise, two committees provide opportunities for divergence and for ignoring inconvenient facts and opinions. Personally, I think the committees should work out an agreement to merge, and then merge in good time before the ISO C++ standard comes up for renewal. The result would be a better language and a much stronger community.


On BS's Website.

[Sorensen]

>LinuxWorld.com

See quote from Herb Sutter.

>Bjarne Stroustrup

I wouldn't be suprised if variable-length arrays were included in the next C++ standard, along with much of the other C99 extras (again see quote by Herb Sutter), some of which was added from C++ in the first place.

That leaves the in-built complex,imaginary and bool types. Unless your doing scientific programming I'd hardly call the first two a gaping chasm (in any case there's already support through the C++ library which would make porting trivial), and C++ already has its own built in bool type.

[Troll_King]

I don't see a chasm, just a schism.