|
__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
|
|
|
|
|
|
How can I force ngen on the client?
Or you are saying I should ngen it on my machine?
What an advantage then?
"...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..."
Me
|
|
|
|
|
igor1960 wrote:
How can I force ngen on the client?
You can run it from setup.
igor1960 wrote:
Or you are saying I should ngen it on my machine?
It has to be ngen'ed on each computer it's installed/run on.
igor1960 wrote:
What an advantage then?
Ngen speeds up start times, but it may actually slow things down overall, because it does not allow the compiler to do as many optimizations. However, it is useful where start times are crucial.
"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
|
|
|
|
|
You can run it from setup.
It has to be ngen'ed on each computer it's installed/run on.
So, I should run it during install?
And I thought: .NET is all about security!
BTW: I'm not sure you can even distribute ngen.
Ngen speeds up start times, but it may actually slow things down overall, because it does not allow the compiler to do as many optimizations. However, it is useful where start times are crucial.
About optimization: Do you know what floating point support CLR uses on each particular machine? What floating point precission to use?...
"...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..."
Me
|
|
|
|
|
Joey Bloggs wrote:
Interpreted / JIT it is about the same performance hit (in the same order of magnitude anyway)
Certainly not! The CLR compiles to native code once and then re-uses the native code. It does not throw out any compiled code. Interpreted code is completely different from this.
Something you don't mention is that managed code in fact can be much faster:
- A managed execution environment can optimize on the specific machine you're running.
- There are JVMs that re-compiles code that is frequently run and does more heavy optimizations on that code.
- A managed execution environment can do cross-optimization over several assemblies, that weren't even known when designing the application.
The above wouldn't be possible in a non-JITted environment.
Before your next post, please spend some time learning how the CLR really works! Some good links are:
Applied Microsoft .NET Framework Programming
Writing High-Performance Managed Applications : A Primer (in the left columns you have several good articles as well)
Articles by Jeffrey Richter
MSDN Magazine
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
