|
I agree with your points. I don't see why one couldn't use OOP in scientific programming.
|
|
|
|
|
I think it's a matter of whether or not OOP makes sense. For example, a scientific application dealing with specific representations of numbers (in a matrix, perhaps) and operating on those representations would do well to use OOP. I'd say that C is probably best in a compact (few KB in size), high-performance scientific library.
|
|
|
|
|
the answer i've always heard on this is that OO code is seen as non-deterministic by a lot of scientists. The scientific code i have seen written in OO languages tends to separate the entity objects from the control objects which largely gets round these problems
The few scientific computer users i know are all Fortran users and i suspect that they are using libraries that have been developed and performance tuned over the course of many years, unlike banks, scientific institutions often have small budgets and loads of inertia.
|
|
|
|
|
Hello everybody, I have been trying to make my own control. I have looked at some articles such as the combo-box based color picker[^], but I still don't get how I am supposed to make my own control. If anyone has had any success with a certain article, I would greatly appreciate a link to it.
Thanks.
|
|
|
|
|
You start by adding a new control to your project, it's an object type. You then get an area like the forms designer, but the controls you add to it, are added to your control. You obviously get to add code to it as well, just like a form. The process is really the same, all that differs is the base class, really.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
I'm creating C# MONO/.NET 2 Winforms application.
I need to enter part names but store part ids in orders table.
I set Combobox Datasource to parts table.
Since parts table is very big, it takes a lot of time to load the data source.
How to use lookup table when lookup table is large ?
Is it possible to use virtual combobox or some other control?
Andrus
|
|
|
|
|
Use a hashtable. How big are we talking ?
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Thank you.
I asked for a WinForms control like which shows first 10 parts whose name starts with entered name.
User can scroll and see next or previous 10 part names. In this case combobox should ask next 10 rows from server etc.
Total table size is from 100 .. 500000 record depending on the user and it is not reasonable to load it as combobox lookup table
during combobox creation like ms doc sample recommends.
Hashtable is not UI control and cannot used for this.
This should be common requirement. Where to find code which implements this ?
Andrus
|
|
|
|
|
Ah, OK. I thought you wanted to look up values and then display them.
AndrusM wrote: This should be common requirement.
I don't think it is.
I know that comboboxes offer auto complete, perhaps you can find something there ? I'm not sure if it works with a callback, or just a data source.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
for auto-complete combobox need to read whole lookup table in init which is not reasonable for large tables.
I'm looking for a virtual combobox control which reads data from sql server only when user actually needs it.
Andrus
|
|
|
|
|
To me it sounds like you should have a BackgroundWorker that will load the data in small pieces and then add them (when possible, or by request) to the combo box.
I am wondering weather you really need a combo box though.. Wouldn't a ListView be better?
Internet - the worlds biggest dictionary
|
|
|
|
|
Backgroundworker is too complicated for this task.
Usually user type first characters of name and want to see 10 matching character. It is best that control reads data only from server when user requestes autocomplete or opens dropdown menu.
ListView takes a lot of screen space.
I need singe-line width field, autocomplete and selection from dropdown table.
I think that combobox nearest to those requirements
Andrus
|
|
|
|
|
Hello,
I've recently posted a question about destructors.
The replies here made me go on a journy of articles reading.
Of course I got wiser , but there's something I'm still not sure about...
If I have a class which holds non-disposable objects, how should I go about releasing my object?
Should I not implement IDisposable?
Should I only set their references to null?
Should I write a finalizer method?
Also, is a finalizer needed if I don't have a Dispode() method?
Thanks in advance,
Shy.
|
|
|
|
|
You need a Dispose method if you want to offer a way to free memory immediately, or if you hold on to things like window handles or database connections, which need to be released. Yes, you should also write a finaliser, this is eventually called by the system, it should check if dispose was called, and if not, clean up for your class.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
What should I do in the following scenario...?
Class X is holding reference to disposable objects, but should not dispose of them, as the referenced objects are used somewhere else (outside of the class).
Lets say that the instance of X is no more in use, and should now be disposed of.
Should I use a finalizer method in order to set X's inner references to null?
Or maybe it is done automatically, and a finalizer method will only be a nag on performance?
|
|
|
|
|
You probably want to wrap the object that needs disposing in another class, which impliments a reference count. This means, you keep track of how many objects are using your object, and when the counter drops to 0, you call Dispose.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
It's possible that I didn't understand exactly what you meant, But what should I do with the inner references?
I'm not really sure as for the following, but AFAIK the GC will not collect an object which is still referenced somewhere.
Lets say both class A and B are referencing an object (and they both should NOT dispose of it). A and B are the only ones holding a reference to the object.
B should now be disposed of, but does not set the reference to the object to null.
Now A is disposing and sets the reference to the object to null.
Would the GC identify it needs to collect the object?
Or maybe it would decide not to collect it, because it is, seemingly of course, still referenced by the disposed/finalized B?
|
|
|
|
|
shyagam wrote: AFAIK the GC will not collect an object which is still referenced somewhere.
Correct. But, the issue is, you want to manage cleanup of some resources, right?
My point would be something like this
object C is the object that both A and B refer to.
object C contains a resource, which needs disposing of
object C keeps track of how many objects are referring to it
object A and B both refer to object C. So it has a reference count of 2.
object A calls Dispose and sets it's reference to null. object C internally does not dispose of the resource it holds, but it does drop it's counter to 1.
object B calls Dispose and sets it's reference to null. object C notices that it's reference count is now 0, so it calls Dispose on the resource in question
The GC cleans up the rest of object C, as nothing has references to it.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
shyagam wrote: AFAIK the GC will not collect an object which is still referenced somewhere
This is not correct. The "somewhere" in your statement must still be alive:
if the only references to Y are from inside objects that themselves are no longer
referenced, object Y is collectable (Otherwise two objects with cyclic references
would never die).
Furthermore, I would discourage the use of reference counts; it is cumbersome,
and when it goes wrong, your code becomes unsafe. It is better to create
a class Z (possibly a singleton) that holds your special resources, and has a Dispose
if applicable; when an object of class Z happens to be no longer referenced,
it becomes collectable (and its finalizer would call its Dispose in case you have
forgotten to call Dispose explicitly).
Remember: you should always call Dispose for objects that offer such method.
(On some classes it may have a different name, e.g. File.Close).
Luc Pattyn
|
|
|
|
|
Christian Graus wrote: You need a Dispose method if you want to offer a way to free memory immediately
Freeing (managed) memory is no reason to implement IDisposable.
The only time that there would be any point in having a Dispose method for removing references, is if you plan to hold on to the object after it's disposed. That sound's a bit creapy, though... like keeping your dead pets in the freezer... 
---
single minded; short sighted; long gone;
|
|
|
|
|
Guffa wrote: Freeing (managed) memory is no reason to implement IDisposable.
Really ? Is the memory used by the Bitmap object unmanaged ? I'd say that if a large amount of memory is being used by commonly created objects, Dispose should be implimented to control cleanup. The framework does NOT manage it very well, I've seen a computer basically frozen, trying to solider on, because the GC had not cleaned up a bunch of objects.
Guffa wrote: The only time that there would be any point in having a Dispose method for removing references, is if you plan to hold on to the object after it's disposed
The point is, the Dispose method on the class in question, would be used to manage a resource count, before deciding if it should in fact call Dispose on an object which it contains.
Guffa wrote: That sound's a bit creapy, though... like keeping your dead pets in the freezer...
Have you not read Pet Cemetary ?
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Christian Graus wrote: I'd say that if a large amount of memory is being used by commonly created objects, Dispose should be implimented to control cleanup.
That makes no sense, as there is no way that you can free managed memory. You can remove the references to it, but it's still the garbage collector that frees it. once there is no reference to an object, it doesn't matter what references it contains. It makes no difference if the object references other objects or not, as the garbage collector doesn't consider references inside objects that no other object has a reference to.
Christian Graus wrote: The point is, the Dispose method on the class in question, would be used to manage a resource count, before deciding if it should in fact call Dispose on an object which it contains.
Each object should be owned by a single object that is responsible for it's life cycle. All other objects that use it should just leave it be and let it be disposed by the owner.
There might be situations where something similar to reference counting might be useful, but it's certainly not the first option. Also, I would definitely let the object itself keep track of the references, not the objects that uses it.
---
single minded; short sighted; long gone;
|
|
|
|
|
ARGGHHHH !!! I answered this at length, and CP crashed and my post was lost.
I am advocating reference counting because the OP said that multiple objcts need to track one resource. I am advocating a wrapper class, so the refrence count is internal to a wrapper class. I'm not typing the rest again, sorry, but the core was, you're right, managed memory can't be freed anyhow, I am just used to working with Bitmaps.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
If your object owns unmanaged resources (or objects that implement IDisposable), it should implement IDisposable. When you implement IDisposable, you should include a finalizer as backup.
Other than that, finalizers should rarely ever be used. It takes much longer for the garbage collector to free objects that has a finalizer. As they can't be freed right away, they will have to be moved to the next heap generation, which includes actually moving the entire object in memory.
Objects that doesn't own unmanages resources (or objects that implement IDisposable) don't need a Dispose method or a finalizer. You can just remove the reference to your object (or let it go out of scope), and the object will be freed by the garbage collector eventually.
If your object has a reference to an object that implements IDisposable, but is not responsible for it, you can just leave it be. You don't need to implement IDisposable to handle it, and you don't need to remove the reference. When there are no more reference to your object, the references inside your object doesn't count any more.
---
single minded; short sighted; long gone;
|
|
|
|
|
WoW.... It's an endless road of knowledge...
So many things to learn...
When I started developing in C#, I had a good understanding of C++ destructors, so I figured I knew all about them in C# as well (WRONGGGGG!  ).
Anyhow...
Guffa wrote: Objects that doesn't own unmanages resources (or objects that implement IDisposable) don't need a Dispose method or a finalizer. You can just remove the reference to your object (or let it go out of scope), and the object will be freed by the garbage collector eventually.
If no finalizer is present, where than should I remove the reference to my object?
Also, is the last statement in the following code redundent?
I think of it as a good programming practice, as you can be sure that the reference was removed.
public void F()
{
Object obj = new Object();
obj = null;
}Should I simply let obj go out of scope to improve performance?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
