|
Nemanja Trifunovic wrote:
Another C++/CLI feature that didn't make into Beta 1? I really feel I'm wasting my time here
Then stop wasting your time with it and wait for the next release.
Signature under construction.
|
|
|
|
|
I wrote the next piece of code today:
System::IO::StreamReader^ file = new System::IO::StreamReader(L"test.txt");
String^ line = file->ReadLine();
Console::WriteLine(line);
file->Close();
and got the compiler error error C2750: 'System::IO::StreamReader' : cannot use 'new' on the reference type; use 'gcnew' instead.
Of course, of course... even with old MC++ I would usually type
System::IO::StreamReader __gc* file = __gc new System::IO::StreamReader(S"test.txt");
, but it is still too easy to forget. Anyway, if we correct this typo, we end up with:
System::IO::StreamReader^ file = gcnew System::IO::StreamReader(L"test.txt");
String^ line = file->ReadLine();
Console::WriteLine(line);
file->Close();
It compiles and runs fine. However, I would never put something like this into production code. Why? Because StreamReader::ReadLine() can throw an exception, and if it does we have a resource leak - the file never gets closed. One way to make this code exception safe is to rewrite it like this:
System::IO::StreamReader^ file = nullptr;
try
{
file = gcnew System::IO::StreamReader(L"test.txt");
String^ line = file->ReadLine();
Console::WriteLine(line);
}
finally
{
if (file != nullptr)
file->Close();
}
Now, that is too much work, and many developers are just too lazy to write the finally clause. In fact, I can't really blame them. This is way too tedious way to make your code exception safe.
Tha right way to take care about resource management is a technique called RAII. If you don't know much about RAII, I strongly encourage you to read this article by Jon Hanna[^]. This idiom is so simple and effective that I even consider keyword finally a flaw in a programming language, because it is either a sign that RAII is not supported, or encourages developers not to use it.
The problem is that RAII does not go well with nondeterministic GC envirinments. For instance, it is impossible to implement it in Java or VB.NET 2003. In C#, there is using keyword wich enables some kind of poor man's RAII mechanism, but even that is too much work IMHO, and I know some C# developers who just don't get why they should bother with using . Even more, in the first edition of Professional C#[^] the author recommends avoiding using which is IMHO a crime.
In old MC++, there is no built in support for RAII. However, I wrote a template class[^] that gives developer a possibility to use RAII, although with some performance cost.
One of the big things about C++/CLI is supposed to be the return of deterministic finalization and support for RAII. Having read an interview with Nick Hodapp[^], I expected to be able to modify my code like this:
System::IO::StreamReader file(L"test.txt");
String^ line = file.ReadLine();
Console::WriteLine(line);
but I got error C3149: 'System::IO::StreamReader' : cannot use this type here without a top-level '^'. Huh? How do we use deterministic finalization with C++/CLI? I'll try to investigate this, and get back to you later.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Ah, I found it here[^].
Hi Stan,
In the VC 2005 Express edition, I cannot seem to create a managed ref class on the heap to take advantage of standard RAII techniques. The compiler seems to think I have to use a ^ to build up my instance. What gives?
# re: Changes in Destructor Semantics in Support of Deterministic Finalization 7/7/2004 12:01 PM stan lippman
yes, i know. it did not make it into the beta release. that's disappointing. but it is in the language, and will be there for you when you next get an opportunity towards it. sorry!
stan
No STL.NET, no RAII. Why did I even download this Beta 1?
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
One of the new features of C++/CLI is trivial properties. Basicaly, the code:
class SomeClass
{
public:
property int State;
};
translates to:
class SomeClass
{
public:
property int State
{
int get() const
{ return State_; }
void set(int value)
{ State_ = value; }
}
private:
int State_;
};
Now, to be quite honest with you, I don't like properties. Not because I believe they hurt encapsulation like some people do[^]. No, properties per se don't hurt encapsulation any more than other member functions do. What I don't like about them is the syntax: they are really methods, but you call them as if they were public fields. Maybe it is because I work with linguists a lot these days, but I firmly believe that good functions' names are verbs ( DoSomething() ) and that good variables' names are nouns ( someValue ). In my mind object.SetSomething(value); is much better than object.Something = value; .
As for encapsulation, as I said - properties don't have to hurt it at all. Abstraction, yes - just as much as accessor functions hurt abstraction, but this is another story.
BTW, does anybody know why Java and C# even allow public fields?
|
|
|
|
|
Nemanja Trifunovic wrote:
BTW, does anybody know why Java and C# even allow public fields?
Because 95% of the user base for these languages are lazy. Smalltalk 80 is the only "mainstream" language I know where fields are never public.
--
Ich bin Joachim von Hassel, und ich bin Pilot der Bundeswehr.
Welle: Erdball - F104-G Starfighter
|
|
|
|
|
Heh, I would never expect lazy people to use OO languages. I had some arguments with people who use scripting languages like Perl and Python, and their main objection against C# and Java was that "there is too much unnecesary typing" - tehy meant class declarations and even variable declarations.
Whenever a programmer uses public fields, he really says goodbye to encapsulation - one of the pillars of OO. Why do they bother with declaring classes then?
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Nemanja Trifunovic wrote:
Whenever a programmer uses public fields, he really says goodbye to encapsulation - one of the pillars of OO. Why do they bother with declaring classes then?
They may be old timers. C and structs die hard. I sometimes revert back to the C days, only to discover myself rewriting it as classes.
--
Ich bin Joachim von Hassel, und ich bin Pilot der Bundeswehr.
Welle: Erdball - F104-G Starfighter
|
|
|
|
|
Nemanja Trifunovic wrote:
In my mind object.SetSomething(value); is much better than object.Something = value; .
How about:
object.Something += value;
|
|
|
|
|
|