|
I think is the main difference between value and reference types is, that if you write
x = y
and y is a value type, x contains a copy of y, while when y is a reference type, x contains a reference to y. To copy y, y is required to ICloneable. Is that false?
|
|
|
|
|
perhaps a better example might be
x = y
y.a_property = some_value
if (x.a_property == y.a_property) then referance type
else value type
|
|
|
|
|
OK, but basically it's the same. So what did I understand wrong? It does have something to do with ICloneable, or not?
|
|
|
|
|
referance and values types have very little to do with ICloneable...
values types a guess are effectively implementors of ICloneable as x = y produces essentially a clone of x
|
|
|
|
|
It is obvious that you are not familiar (to be honest your guesses amused me pretty much  ) with Value and Reference types - you may try the following article (the first found one after search).
http://www.codeproject.com/KB/dotnet/Primitive_Ref_ValueTypes.aspx[^]
If I may advise you - you need read more about the basics of .NET such as Common Language Runtime (CLR), IL, value and reference types, etc.
And do not be that arrogant:
Derek Bartram wrote: Uh, ***trying not to sound rude***, how inefficiently do you code?
.
Having in mind that you even dare to compare the performance of native C++ against .NET and after examining some code from your "Famous" Ribbon library I am not completely sure that you are an efficiency master...
Thanks,
Georgi
modified on Sunday, April 13, 2008 4:52 PM
|
|
|
|
|
Georgi Atanasov wrote: It is obvious that you are not familiar (to be honest your guesses amused me pretty much ) with Value and Reference types
I've just read the article and can't see anything wrong with my earlier post specifically; perhaps you could be more specific please.
Thank you for the link however as it does clarify a few implementation details of how value and type referances work; however those details didn't relate to the orriginal question.
Georgi Atanasov wrote: need read more about the basics of .NET such as Common Language Runtime
As a developer of .NET for 5-6 years I've never had a problem yet, and amongst my peer group I am considered a good programmer, so perhaps I question this.
Georgi Atanasov wrote: And do not be that arrogant:
I wasn't being arrogant, in fact I was deliberatly trying not to be; however writing efficient code and algorithms is challenging (and I would happily admit i'm no expert, however subjectively I would say I'm pretty good). Efficiency of coding often impacts performance more than code, and as someone from an innitial Java background there was were many things I used to do 'wrong' in .net initially when I transfered languages that did have an impact on performance. I appologise if offence was taken.
Georgi Atanasov wrote: Having in mind that you even dare to compare the performance of native C++ against .NET
Firstly doing a comparison of high level libraries such as my Ribbon Control Library is generally not a suitable test as too many implementation issues are often prevalent. A number of years ago (and this has been repeated by a number of my colegues) we developed a series of rather primative tests to analyse the performance of a few main basic language functions (data read, addition, subtration, multiplication, division, list sorting etc), and for Java vs. C# .NET the .NET language out performed Java by a significant degree and more importantly consistantly. While I havn't perform a similar test myself I have heard of colegues performing the test upon .NET and native C++ and the difference is not that significant (although granted C++ did outperform consistently).
Georgi Atanasov wrote: after examining some code from your "Famous" Ribbon library I am not completely sure that you are an efficiency master...
Firstly great, I hope you did. I'll go look at the comments you left in the article so that I can improve the library further. Secondly, the library has been developed relatively quickly for functionality primarily and efficiency as not really been considered at this stage. Thirdly i'm not sure what you comparied the efficiency of the system with (and I assume you used the local version rather than the web version which is far older and slower due to lack of an important update), however on my system (and testing be third parties on a number of other systems) my library performs well within the boundaries of office performance (and even better in a few cases). Fourthly, it's "famous"?
Finally, you mention being arrogant yet frankly you message smacks of arrogancy. I'm happy to admit i'm wrong when someone shows me evidence to the opposite, however at no stage you have done this; instead you have done nothing more than a unproved attack against myself. This is a community of developers supporting each other, perhaps if you can't or don't respect that you should consider finding a different site to occupy. Thank you, Derek.
|
|
|
|
|
Derek,
I am glad that you have noticed the arrogance - it was intentional - take my apologies. I just wanted to show you that it is not good to show such attitude when talking with other people. I got somehow angry to one how says Java is the worst code ever. Think about this - why in your opinion SAP have chosen Java? And do you know that Java world is larger than the .NET one and that there are more billions in the Java market? As I mentioned in an earlier post I code in .NET also but nevertheless Java has its own advantages - it is actually PLATFORM INDEPENDENT, does not have Interop calls in the class library, only in its runtime, etc. I think you miss some of my statements - TILL WPF (things are different there) every Windows Forms Control is a Win32 Handle wrapper, with lots of Interop underneath.
OK, about the Value and Reference types - these are the two basic types in .NET. Value types are special objects, which reside on the Stack and are accessed by copying their values (of course you may always pass a value type by ref). Reference (or instance) types on the other hand are objects, which reside on the managed heap, reserved by the CLR, and are accessed by reference. These objects are target of the Garbage Collector. There are other differences which are not in this scope. So, they have NOTHING to do with ICloneable, value types are not ICloneable implementors. This interface is used when an exact copy of a Reference type is required and it is each type's task to implement the "Clone".
Thank you for taking the time to talk with me
Thanks,
Georgi
|
|
|
|
|
Georgi Atanasov wrote: it is not good to show such attitude when talking with other people.
I'd agree certainly, however my original statement wasn't intended in perhaps the way it was percieved.
Georgi Atanasov wrote: one how says Java is the worst code ever
I never said that (I hope), that would be Haskell perhaps. However as a programming language that claims to produce software for all purposes (essentially) then compaired to .NET it does have significant performance and memory limitations that to my mind at least make it all but crippled.
Georgi Atanasov wrote: Java world is larger than the .NET one
I have heard that quoted before, and I wouldn't be as bold as too disagree, however I would say that just because it's used more doesn't make it good. Ask a linux advocate and they would use a similar argument perhaps.
Georgi Atanasov wrote: it is actually PLATFORM INDEPENDENT
I don't dispute that Java some benefits, however I would argue that things like platform independance is very low on my list of priorities.
Georgi Atanasov wrote: does not have Interop calls in the class library
If it doesn't make the language more complicated to use or of lower performance where is the advantage of not doing that?
Georgi Atanasov wrote: I think you miss some of my statements
I was pretty careful to read your posts (and have double checked them before posting this), however while you are technically right in the aspects of java benefits you state, I question however they are of any significance to the average progremmer or perhaps even to industry. If a language is simple to use, works well, and performs well, does it really matter the underlying implementation issues?
Georgi Atanasov wrote: OK, about the Value and Reference types - these are the two basic types in .NET. Value types are special objects, which reside on the Stack and are accessed by copying their values (of course you may always pass a value type by ref). Reference (or instance) types on the other hand are objects, which reside on the managed heap, reserved by the CLR, and are accessed by reference. These objects are target of the Garbage Collector. There are other differences which are not in this scope. So, they have NOTHING to do with ICloneable, value types are not ICloneable implementors. This interface is used when an exact copy of a Reference type is required and it is each type's task to implement the "Clone".
Thank you for clarifying that, always happy to learn. I orriginally said something along the lines of
x = y;
y.some_method(); *
if (x == y) then reference type
else value type
* where some_method alters the value of y
Disregarding the section about the various stacks of the .NET CLR, what part of my orriginal statement is incorrect? or perhaps were you refering to when I said something along the lines of...
when x = y and y and x are value types then effectively they implement ICloneable
To summarise what I meant wasn't (e.g.) int implements ICloneable but rather if x and y were referance types not value types then x = y is the equivilent of x = y.Clone() and so in a way values types perform in a manor similar to that of an ICloneable object.
Georgi Atanasov wrote: Thank you for taking the time to talk with me
Likewise, I look forward to you reply.
|
|
|
|
|
Georgi Atanasov wrote: That is my personal opinion of course.
And which is why you can get away being so wrong 
On a little more serious note...
Georgi Atanasov wrote: Java is completely detached from the underlying OS
So? If it works then why not?
Georgi Atanasov wrote: 99% of the controls are wrappers of their Win32 equivalents; you need to know Win32 API in order to create commercial controls
I'm not sure i'd agree; I've created a Office Fleunt Ribbon control library using nothing more than WPF, which i'm happily using in a commercial grade application, with no problems (http://www.codeproject.com/KB/WPF/ribboncontrol.aspx[^], see also CIRIP).
Georgi Atanasov wrote: WPF consumes lot of memory
It's a new technology, and so not full optimised yet; hey if you want to moan about something *new* then why not have a go about the lack of an open and save dialog. I'm sure exactly the same was said of MFC, Swing, etc.
Georgi Atanasov wrote: is not the platform a company, which cares about performance, would choose on...
There are companies using it, admitadly few currently but growing by the day. Yes, performance is shocking until you learn how to use it properly and then it's more than fast enough. Companies in my eyes don't care about performance, they care about cost to produce something that does the job, and from my experience WPF reduces development time (after over 4-5 years of Windows Forms (and Java Swing for that matter) and only <6 months WPF programming).
|
|
|
|
|
OK, basically, they have nothing to do with ICloneable. But if you want to create a copy of a reference type, this type needs to implement ICloneable, whilst in C++, reference types can be both referenced and copied by default and you can define a copy constructor to change the copying process. I think this is solved much better in C++.
|
|
|
|
|
elektrowolf wrote: you can define a copy constructor to change the copying process
Isn't that then just an implementation or rather synatic difference then.
elektrowolf wrote: copied by default
While certainly clever (and a function by the sounds of it I would like in .net), it sounds like it has the potential to be rather dangerous. Consider;
object a contains b contains c part of dataset d
cloning a potentially may be cloning d as well?
|
|
|
|
|
Derek Bartram wrote:
Isn't that then just an implementation or rather synatic difference then.
Yeah, it's an implementation, I think.
Derek Bartram wrote: cloning a potentially may be cloning d as well?
Yeah, for this you have the copy constructors. Then you can only reference the DataSet in the clone. But of course it's dangerous if you forget this..
|
|
|
|
|
Last symester in High school I learned Java. It was so annoying. For our final sumative we had to make a game (We're kids oaky) and due to time constraints I had to work on it at home. At home I have JRE 1.6, at school they have JRE 1.5. Java 1.5 wouldn't display my game properly, it was all screwed up. I like C# way, way better.
|
|
|
|
|
But.. but... it's portable... so it has to be good
|
|
|
|
|
Huh, I don't know Java. But I don't think it's that bad. C# isn't too fast, too. But there are pretty much features in C# now I don't want to miss like (automatic) properties, WPF, LINQ, extension functions,...
|
|
|
|
|
elektrowolf wrote: C# isn't too fast, too
Uh, ***trying not to sound rude***, how inefficiently do you code?
|
|
|
|
|
.. I mean compared to C++. I don't think it's too slow, I've never had problems with C#'s performance, but for some algorithms you need C++.
|
|
|
|
|
elektrowolf wrote: but for some algorithms you need C++.
like what?
Yes, i'd agree there is a slight performance decrease compaired to c++ but it's neglible.
|
|
|
|
|
Thread t = new Thread(delegate()
{
while (keepShowing)
{
this.Dispatcher.Invoke(System.Windows.Threading.DispatcherPriority.Normal, new RefreshDelegate(delegate()
{
if (!(Mouse.LeftButton == MouseButtonState.Released &&
Mouse.MiddleButton == MouseButtonState.Released &&
Mouse.RightButton == MouseButtonState.Released &&
Mouse.XButton1 == MouseButtonState.Released &&
Mouse.XButton2 == MouseButtonState.Released))
{
if (!insideControl)
{
for (int i = 0; i < this.MenuButtons.Count; i++)
{
if (this.MenuButtons[i].PopupMenu != null && this.MenuButtons[i].PopupMenu.IsMouseInside)
{
return;
}
}
keepShowing = false;
}
}
}));
Thread.Sleep(10);
}
this.Dispatcher.Invoke(System.Windows.Threading.DispatcherPriority.Normal, new RefreshDelegate(delegate()
{
this.IsOpen = false;
}));
});
t.Name = "Capture Click Events Thread";
t.Priority = ThreadPriority.AboveNormal;
t.Start();
A thread with anonamous delegate to a dispatcher with an anonamous delegate.... crazy talk I say. I don't remember exactly where it is (hence I havn't posted it), but I have a thread with anonamous delegate to a dispatcher with an anonamous delegate to a thread with anonamous delegate to a dispatcher with an anonamous delegate somewhere. *Ps. It's in the RibbonControl library, oops (http://www.codeproject.com/KB/WPF/ribboncontrol.aspx[^])
|
|
|
|
|
Yeah, that looks like abuse.
|
|
|
|
|
It's the way forward 
Still, it's a shame they didn't go back to the ways of .NET 1 where you could just directly modify gui properties directly. I remember seeing the justification for it, but frankly .NET 1 never gave me any problems so why change it.
|
|
|
|
|
Nothing really wrong with that... maybe you are just scared of nested closures You should probably stay away from any functional language in that case 
|
|
|
|
|
I'd question perhaps how maintainable that is though!
|
|
|
|
|
I don't even know the code that belongs to and it is rather easy to see what it does. It needs a delegate to invoke back to the GUI thread from within the runner thread. As an exercise, convert that code to a non-anonymous delegate way, you will see the resulting code will be much more disconnected, and a lot more verbose. Unless he is repeating the code anywhere else, I see no reason to refactor it.
|
|
|
|
|
leppie wrote: you will see the resulting code will be much more disconnected
Certainly, however convert it to the .NET 1.0 way and it'll be far less confusing.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
