|
norm wrote:
2. When instantiating managed class..
SomeClass MyInstance; (illegal, if "SomeClass" is a managed class.
SomeClass* pInstance = new SomeClass (legal)
Why did they design it as such? Is there any purpose behind this?
It just makes object instantiation more consistant across .NET languages.
norm wrote:
//QUESTION 1: What's the purpose of "__property"?? What's the difference between "__propery" and "method"??
Dummer * Tom = new Dummer;
Console::WriteLine(Tom->get_Val());
Actually a property is referenced slightly different, and similar to field access. You would call:
Dummer * Tom = new Dummer();
Console::WriteLine(Tom->Val);
norm wrote:
//QUESTION 2: Error C3149 here. You must declared John as a "pointer" - but why did the .NET team assert that all managed class instance must be "pointer" to the class at hand??
/*
Dummer John;
John.m_nValue = 10;
*/
return 0;
}
Declare the type as a __gc struct. Then behaviour is like a struct, but it can contain members. You can look into __value types too, AFAIK these are allocated on the C++ heap and not the .NET heap, and hence are accessable from both.
leppie::AllocCPArticle(Generic DFA State Machine for .NET);
|
|
|
|
|
norm wrote:
1. Why "__property"? What does it offer that regular "method" does not?
I am not a fan of properties myself - I think that a function should have a syntax of a function, but anyway in .NET all accessor methods should be implemented as properties. Just learn to live with it
norm wrote:
2. When instantiating managed class..
SomeClass MyInstance; (illegal, if "SomeClass" is a managed class.
SomeClass* pInstance = new SomeClass (legal)
Why did they design it as such? Is there any purpose behind this?
Because in C++ the first version would create MyInstance on stack, and gc objects can go only to managed heap.
|
|
|
|
|
Nemanja Trifunovic wrote:
I am not a fan of properties myself - I think that a function should have a syntax of a function, but anyway in .NET all accessor methods should be implemented as properties. Just learn to live with it
It has a number of benefits. For instance, if you wanted to increment a value by 1, with a property you could do this:
Object.Property++;
rather than
Object.setProperty(Object.getProperty()+1);
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
Yes it is easier to type
However, properties's syntax hide the fact that they are functions, not data members, and I don't like it. In ideal world nobody would use public data members and then I wouldn't mind. However, too many people use public members, and sometimes it is not obvious whether
Person.Name = "Joe";
refers to property or member data.
|
|
|
|
|
Yeah, that's true. The guidelines I go by are: If it's essentially going to set some member data and then do some things that should be done when that value changes, then it should be declared as a property. But if it's going to do more than that - say, setting some value outside of the class it's in, then it should be a method. I also noticed that a number of the framework classes go by this rule, too.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
__gc class A
{
protected:
String* m_sobj_name;
int m_nCountRead;
...
...
public:
__property String* get_name() {
m_nCountRead++; //Keep count.
bArth=Authorize(); //Do other stuff.
if(bArth==false) {return "error";}
return m_sobj_name; //Then, return protected property in the end.
}
...
...
};
_tmain(..)
{
...
A *pObj = new A;
String* sName = pObj->name; //simpler syntax, yes.
};
norm
|
|
|
|
|
Where can I find it?
--------
"I get to go to lots of overseas places, like Canada."
- Britney Spears, Pop Singer
|
|
|
|
|
|
|
I am paitently waiting for Microsoft to release SP1 of 1.1 to resolve the following issue (the host won't install the hotfix until it is part of a service pack)...
http://support.microsoft.com/default.aspx?scid=kb;en-us;818803[^]
Any idea when the service pack is planned?
David Wulff
"Yeah, ohh, ahh. That's how it always starts. But then later there's running, and screaming."
-- Jeff Goldblum, The Lost World.
|
|
|
|
|
9rays.net Report Sharp-Shooter 1.3 has been published!
Report Sharp-Shooter is the most flexible .NET report engine available on
the market. It's a suite of 100% managed .NET components that allow you to
create both bound and unbound reports with unlimited number of master-detail
relations. You can build highly complex reports by using groups, columns,
crosses, double pass mode, C#/VB scripting etc. Full data-binding model is
supported with all .NET sources.
Package includes royalty free runtime designer for ready documents and
report-templates.
The professional version comes with the source code.
Visit us at www.9rays.net for more info.
Best regard,
Eugene
|
|
|
|
|
I have some problems whith the splitters. In design time it's O.K. But the problems start at runtime, when I create some child Forms by code and I try to dock them inside a new splitter but it's impossible, the splitter ignores the correct order (it´ss been generated later than the Form child) and does not include the new child form inside. It's like the Form child is not treated like another design control inside the main Form.
Please, can anybody help me about the treatment and placement of splitters controls in run time with Windows Forms?
Thank you.
Raf.
|
|
|
|
|
I have some problems whith the splitters. In design time it's O.K. But the problems start at runtime, when I create some child Forms by code and I try to dock them inside a new splitter but it's impossible, the splitter ignores the correct order (it´ss been generated later than the Form child) and does not include the new child form inside. It's like the Form child is not treated like another design control inside the main Form.
Please, can anybody help me about the treatment and placement of splitters controls in run time with Windows Forms?
Thank you.
Raf.
|
|
|
|
|
Why does a simple .NET app with a few forms take more memory to run than apps like explorer.exe and wmplayer? Furthermore, why after closing a form does a .NET app not release the memory used by that form? For extended runtime apps this could pose to be a serious issue. Are there any tips you all could offer on memory management in .NET to make it more efficient?
-- Adam
"If you can't beat your computer in chess, try kickboxing"
|
|
|
|
|
The same reason its such a processor hog, its interpreted.
I'm sure that the garbage collection system will eventually release the memory.
I haven't got this far in .net yet but in java I had to implement Object Pools and an ObjectPoolManager to recycle objects. The costs in gc and performance where too high otherwise.
|
|
|
|
|
What do you mean by its interpreted?
Bo Hunter
|
|
|
|
|
I mean that the CLR converts IL to x86 machine code at runtime.
|
|
|
|
|
That's not quite the same - an interpereted language is never compiled at any point, whereas Java and MSIL are compiled to native code at runtime, and can even be turned into a native code exe using ngen.exe .
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
I see. The processor uses esp to sense which instructions to perform from an interpreted language...
Interpreted / JIT it is about the same performance hit (in the same order of magnitude anyway)
|
|
|
|
|
No, it parses the code and calls predefined methods based on the code.
But even if it compiled it (which no doubt some interpreters do), there is a huge difference between parsing text code and reading byte code.
You can also easily create a native image from an assembly, which is just a cached native code image of the assembly, and does not need to be JITed.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
Joey Bloggs wrote:
Interpreted / JIT it is about the same performance hit
When code is JIT compiled, it will be compiled only once during the execution of the program, regardless of how many times the same code is run (in loops etc.)
In interpreted code, the interpretation process is repeated for each loop iteration.
|
|
|
|
|
I think that that would depend on how much memory is available to the VM. It might need to discard and recompile depending on a wide range of issues.
|
|
|
|
|
That's exactly right. It is not interpreted. I have read this in books
and MSDN that's why I asked before I anwsered. To be interpreted it means
that it is interpreted at runtime. Big Big difference.
Bo Hunter
|
|
|
|
|
Joey Bloggs wrote:
It might need to discard and recompile depending on a wide range of issues.
IIRC the version of .NET available on your PC does not throw out JITted code. The notion that it does happen is because of early announcements released by MS and at conferences where they were going to make 3 different JIT compilers.
That didn't actually happen in time for the framework to go live, so you have two different compilers, the one used by PCs and one used by the compact framework (which does have code-pitching).
I thought I remembered someone from MS making a comment to this end, but all I can find is this one[^].
James
"I despise the city and much prefer being where a traffic jam means a line-up at McDonald's"
Me when telling a friend why I wouldn't want to live with him
|
|
|
|
|
As I said before, if you run ngen.exe on the assemblies, they will no longer need to be JIT'ed at runtime, and therefore, will run much faster.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|