|
Ankh 2.0 is a free source control provider for VS if you are running SVN > 1.5. Don't bother with Ankh 1 though 
|
|
|
|
|
SourceVault is free for single-user
|
|
|
|
|
There are two ways to pass argument: byVal or byRef. (C# and VB.Net)
However, I also know that all objects are passed by reference. So what happens when we pass an object byval--Does it make a difference?
Also, when arguments are passed byVal it hinders performance since a copy needs to be made. ByVal also means the called method can modify the argument and it will not affect the original data. If a method only needs to read an argument but does not need to modify it, does it make sense to send it byref? But then how can you guarantee the data will not be modified in the called method; specially when the called method is being coded by another programmer? Does it come down to simply making a choice between integrity and performance? Or is there a convention or am I just confused?
|
|
|
|
|
CodingYoshi wrote: However, I also know that all objects are passed by reference.
That is not correct. By default, objects references are passed by value.
Do not confuse variable data types (value types vs. reference types) with argument passing mechanisms (pass-by-value vs pass-by-reference).
For example, arrays are reference types. When you create an array, a block of memory is allocated and your array variable contains a "reference" the to the memory area (typically a four-byte address). For example:
In Visual Basic:
Dim values(10) As Integer In C#:
int[] values = new int[10];
The variable, values, contains a reference to a block of ten integers.
If you pass your array to a method as an argument, the reference to the array is passed by value (important). You can modify the elements of the underlying array but you cannot assign a new array to it.
To illustrate what I am talking about, take a look at this C# code:
using System;
class Program
{
static void Main()
{
int[] values = { 1, 2, 3 };
TestMethod(values);
Console.WriteLine("{0}, {1}, {2}", values[0], values[1], values[2]);
}
static void TestMethod(int[] values)
{
int[] newArray = new int[] { 4, 5, 6 };
values = newArray;
}
}
This code will print "1, 2, 3". Why? First, an array containing { 1, 2, 3 } is created. The TestMethod() creates a new array with { 4, 5, 6 } and attempts to point your array reference to it. But when TestMethod() returns, the reference is not changed because the reference was passed by value.
However, you can change the underlying data pointed to by the reference. If TestMethod() did this:
static void TestMethod(int[] values)
{
values[0] = 4;
values[1] = 5;
values[2] = 6;
}... the values would be changed (i.e., it prints "4, 5, 6") because you passed a reference to the data contained in values, which TestMethod() is free to change.
CodingYoshi wrote: when arguments are passed byVal it hinders performance since a copy needs to be made
Nah. Performance differences are usually insignificant. Maybe if you need to pass really large value types (like large structures) and you really need to tune for performance, you could pass those value types ByRef. But, more often than not, it is much more important to communicate your intentions to the programmer (to protect the parameter's value or not) rather than prematurely optimizing your code.
CodingYoshi wrote: If a method only needs to read an argument but does not need to modify it, does it make sense to send it byref?
No. Passing arguments ByRef or ByVal should declare your intentions to protect (or not protect) the value of the parameters you are passing. It will improve the readability and safety of your code.
Enjoy,
Robert C. Cartaino
|
|
|
|
|
OK - so I've been working on a couple of intranet sites that use Index Server to handle content searching. Everything is going great - but I've been stuggling with a question for a while now: What type(s) of algorithms are at use within the internals of Index Server that allow it to search a 30+ MB catalog in under a tenth of a second??? Granted, to heavy lifting is done by the cidameon processes at crawl time, but even so - of 30 meg key catalog is still a lot of data to sift through. And of course, none of this information is published by MS, but I'm so ever curious....any insights???
Cheers!
|
|
|
|
|
This article[^] might help you gain an understanding.
|
|
|
|
|
Hi,
I often ponder upon this. If I have a class with, lets say, 10 methods and about 6 of these methods need the same variable, is it a good idea to pass those variables as arguments to these methods? It just does not make sense to make this a member variable, in my opinion, as it has nothing to do with the state of the object, but only needed by these methods.
What should I do in such a case? Should I pass them as arguments or should I declare them as member variables?
Thanks before hand
|
|
|
|
|
If it's purely an argument, and is not data that should be encapsulated by the object then pass it in as an argument to the methods. You should really only use members when they encapsulate data for the object.
|
|
|
|
|
Hi guys,
Quick question - are c# interfaces immutable in the same way that COM interfaces were - i.e. once published cannot be changed?
C# has already designed away most of the tedium of C++.
|
|
|
|
|
Interesting question. The first answer is "No" they aren't immutable. You can change them. The second answer is "In certain circumstances, they should be". If you publish an API, then you shouldn't modify a method signature - it's just bad practice. However, you may choose to add new methods and properties, but you have to be aware of the impact - e.g., are you going to cause a serialized object to fail/
|
|
|
|
|
OK - excellent, pretty much what I thought....so the next question is what is the point of an interface in c# (lol!). I mean, I know the textbook answer, but given a situation where we need to add a field to a database call, if we're using an interface type setup, then we'd have to make the change in 2 places - interface and implementation - so unless I'm expecting my class to have many clients, there's not really much point in going down the interface route?
I'm clearly missing something here, just not sure what lol!
C# has already designed away most of the tedium of C++.
|
|
|
|
|
If you're just developing an internal application, then an interface is pretty useless in that it won't really add that much value to your code. If, though, you want to expose your application to the outer world, then an interface is really useful - and you should certainly look at using it if you want to move into areas like WCF.
|
|
|
|
|
OK - that's brilliant....thanks for that.
The reason I ask, is that I come from a very "rigid" dev background - kinda places where if you don't have a signed off spec, you don't write a line of code. Now I've moved into a more "relaxed" environment, but the code is basically a big morass of procedural code in an object oriented dress - with inheritance implemented using copy and paste lol....
I'm trying to get some more structure into things, and whilst at the moment we're a closed platform, I can personally see the value in a clearly defined API...and from what you're saying, interfaces are probably the way to go for that one. Adittionally, the more "experienced" members of the team need convincing that what I propose will actually help - to give you some idea of the "challenge" here, I put together some unit tests, and they were struck down on the grounds that they're "extra work, why can't you just look at your code and find bugs that way - eyeball Mark 1!"
Again, many thanks for the time Pete.
C# has already designed away most of the tedium of C++.
|
|
|
|
|
Interface are also good in places where you have an object that depends on another, especially if that other object is passed in at construction time. (This is a lot like Dependency Injection and Inversion of Control.)
You can also use them when you potentially have multiple objects that will share common traits. Think of this scenario:
You are implementing a Visual Studio-like application so you have a concept of a project and project items. You can have multiple project types and and multiple project item types. There is only a very small bit of functionality that is common across all project types and all project item types. By implement a set of interfaces (IProject and IProjectItem), you can pass interfaces around as method parameters, etc. and always guarantee that the object you are given will implement certain methods/propterties. You can't guarantee the actual implementation, only that the method or property will be available. This allows you to more easily expand the system by adding new project or project item types by simply deriving from the interface.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
RichardGrimmer wrote: Now I've moved into a more "relaxed" environment, but the code is basically a big morass of procedural code in an object oriented dress - with inheritance implemented using copy and paste lol....
I was on vacation, did you just join my shop? 
RichardGrimmer wrote: so unless I'm expecting my class to have many clients, there's not really much point in going down the interface route?
I'm clearly missing something here, just not sure what lol!
It sounds like you are missing something but you also said you know the text book definition so this is a bit confusing. In Object Oriented Design an interface is a mechanism of abstraction. So you want to use an interface if it is desirable to abstract the functionality.
RichardGrimmer wrote: are c# interfaces immutable in the same way that COM interfaces were
First, COM is not Object Oriented Design and there is not generally any reason to compare COM to OOD. Also I am not sure what you mean by immutable. My best guess is that you mean, can you modify an interface, build and distribute the assembly without breaking existing code. While there might be some scenarios where that would work, most of the time I expect it would not.
led mike
|
|
|
|
|
led mike wrote: First, COM is not Object Oriented Design and there is not generally any reason to compare COM to OOD. Also I am not sure what you mean by immutable
He's dealing with the idea of interfaces as the way that COM defined them, i.e. Contracts that were exposed to the outside world (and referenced through IUnknown and so on). In COM, interfaces were supposed to be immutable because COM relied heavily on VTable binding, so changing the interface resulted in the VTable being incorrect, which obviously caused errors when attempting to call a method which had been moved because a new parameter was added to a method.
|
|
|
|
|
Pete O'Hanlon wrote: so changing the interface resulted in the VTable being incorrect
Not incorrect in the compiled module, so what I said then, right?
led mike wrote: My best guess is that you mean, can you modify an interface, build and distribute the assembly without breaking existing code.
led mike
|
|
|
|
|
Well - depending on versioning, yes.
|
|
|
|
|
Yep, but rather than the nicely broken like you get in .Net, it was horrible horrible things like stack corruption or jumping to a completely wrong location
|
|
|
|
|
Are there any software with modeling can get knowledge from texts?
Something like terminology extraction software
With modeling that can idenfify texts, get knowledge from texts.
Will be install on Novell Linux Enterprise, Sun Solaries, openSolaries.
OCR from books.
OCR to turn the text into a digital format
Reference, some machine learning software:
http://www.dmoz.org/Computers/Artificial_Intelligence/Machine_Learning/Software/
http://www.cs.waikato.ac.nz/~ml/weka/
http://www.ph.tn.tudelft.nl/PRInfo/software.html
http://www.fml.tuebingen.mpg.de/raetsch/workshops/MLOSS06
http://www.mloss.org/software/
http://maltman.hmdc.harvard.edu/socsci.shtml
http://home.earthlink.net/~dwaha/research/machine-learning.html
http://dir.yahoo.com/Science/Computer_Science/Artificial_Intelligence/Machine_Learning/Intelligent_Software_Agents/
http://www.google.com/Top/Computers/Artificial_Intelligence/Machine_Learning/Software/
http://www.nec-labs.com/research/machine/ml_website/main/software.php
http://www.isp.pitt.edu/information/software.html
|
|
|
|
|
Hi,
I am new to MVP architecture. Can anybody please send the sample project like student/Employee which will demonistrates the MVP architecture. The article is good help to me which is posted by you.
Thanks in advance.
|
|
|
|
|
sreenivasaraok wrote: I am new to MVP architecture. Can anybody please send the sample project
Is there something wrong with this sample project?[^]
led mike
|
|
|
|
|
|
(Cross posted from the c# forum)
A Customer can have multiple Products and a Product can be assigned to zero to more Customers
But, there are some items (such as BasePrice and DefaultPrefix) that are implicit to a customer-product relationship.
In the database this can be modeled as
Table Customer with Columns CustomerId, Name, etc.
Table Product with Columns ProductId, Name, etc.
Table CustomerProduct with Columns CustomerId, ProductId, BasePrice, DefaultPrefix, etc.
How would you model this as Domain Objects?
All I could think of is
Customer
..CustomerId
..Name
..AssignedProduct[] Products
Product
..ProductId
..Name
..Customer[] Customers
AssignedProduct : Product
..Customer Customer
..BasePrice
..DefaultPrefix
But that doesn't strike me as too slick (an Assigned Product has a Customer and a Customers[]???) and as this simplified example gets closer to what I actually have to model, this design starts to have problems among which is that NHibernate can't model some of this stuff
|
|
|
|
|
I'm toying with the idea of using 'virtual' menu items to allow a user to configure a menu. When placed in an 'edit mode', each real menu item will get extra 'virtual' child items such as 'Add Child', 'Add Above', 'Add Below', etc. which will bring up a dialogue for configuring the menu item. Any thoughts on this approach?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
