CLASSES AND STRUCTS in C#.NET

Maker PDF-417 2d barcode in C#.NET CLASSES AND STRUCTS

As you can see, the static constant value is not interpreted as a compile-time constant when referenced in another assembly. Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.42 for Microsoft (R) .NET Framework version 2.00.50727.42 Copyright (C) Microsoft Corporation. All rights reserved. static_const_main.cpp static_const_main.cpp(13) : error C2057: expected constant expression static_const_main.cpp(13) : error C2466: cannot allocate an array of constant si ze 0 static_const_main.cpp(13) : error C2133: 'a1' : unknown size static_const_main.cpp(16) : error C2975: 'i' : invalid template argument for 'f' , expected compile-time constant expression static_const_main.cpp(5) : see declaration of 'i' On the other hand, if you include the same code as source rather than reference the built assembly, static const is interpreted using the standard C++ rules.

Now suppose we have a constant value that cannot be computed at compile time. Instead of marking it literal, we use initonly. A field declared initonly can be modified only in the constructor (or static constructor). This makes it useful in situations where using const would prevent the initialization code from compiling (see Listing 6-8). Listing 6-8. Using an initonly Field // initonly.cpp using namespace System; ref class R { initonly String^ name; public: R(String^ first, String^ last) { name = first + last; }

void Print() { name = "Bob Jones"; // Error! Console::WriteLine(name); // OK } }; int main() { R^ r = gcnew R("Mary", "Colburn"); r->Print(); } The compilation output is for Listing 6-8 is as follows: Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.42 for Microsoft (R) .NET Framework version 2.00.50727.42 Copyright (C) Microsoft Corporation. All rights reserved. initonly.cpp initonly.cpp(17) : error C3893: 'R::name' : l-value use of initonly data member is only allowed in an instance constructor of class 'R' An initializer is allowed if the initonly field is static, as demonstrated in Listing 6-9. Listing 6-9. Initializing a Static initonly Field // initonly_static_cpp using namespace System; ref class R { public: static initonly String^ name = "Ralph"; // OK // initonly String^ name = "Bob"; // Error! // rest of class declaration }; The initonly modifier can appear before or after the static modifier.

In classic C++, a method can be declared const, which enforces that the method does not affect the value of any data in the object, for example: class N { void f() const { /* code which does not modify the object data */} }; This is an important element of const correctness, a design idiom in which operations that work on constant objects are consistently marked const, ensuring that programming errors in which a modification is attempted on a const object can be detected at compile time. Const correctness is an important part of developing robust C++ code, in which errors are detected at compile time, not at runtime. Proper const parameter types and return values go a long way to prevent common programming errors, even without true const correctness in the classic C++ sense. Even so, many C++ programmers do not use const correctness, either because the codebase they are working on did not implement it from the ground up, or because the amount of extra time to design it correctly was too great a price to pay in the results-oriented corporate world. In that sense, full const correctness is like flossing one s teeth. For those who do it, it s unthinkable not to do it. For those who don t, it s just too much hassle, even though they may know deep down that they should do it. In general, const correctness works well only if all parts of a library implement it consistently. Anyone who s ever tried to retrofit an existing library with const correctness knows this, since anytime you add const in one location, it often requires const to be added in several other locations. Like it or not, the CLI is not designed from the ground up to enable full const correctness in the classic C++ sense. Other CLI languages do not support full C++-style const correctness. Since the .NET Framework isn t implemented with C++ const correctness in mind, attempting to support full C++ const correctness in C++/CLI would be an exercise in futility and force programmers to use const_cast to cast away const when using .NET Framework functionality. Hence, C++/CLI does not support const methods on managed types. At one point early in the development of the C++/CLI language, this support was included, but the results were ugly and nearly unusable, so the effort was dropped. While this knocks out one of the pillars of const correctness, C++/CLI does support const parameter types and return values, and, although they are not alone enough to enforce const correctness, they at least enable many common const correctness errors to be detected at compile time.