|
|
Brady Kelly wrote: When your property methods contain logic that maintains some other value when the property changes. The alternative is to duplicate that logic ( [Unsure] ) wherever you directly change the property value.
That's why I would always access a data member through the property, if one is provided by the class designer. Even if it appears that accessing the member directly would accomplish the same thing, you don't know what what might be added to the property later. That's what properties are for; to provide controlled access to a data member. Why circumvent it?
Robert C. Cartaino
|
|
|
|
|
Just when they need to.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
Hi All! I am new to the forum and am hoping you can help with finding a simple source code management software. I've tried downloading older open source versions but either the websites weren't running anymore or the code was for Linux or something. I am running Windows Vista...Other programs I found online were either designed for a server or too much money.
I just want a simple code management program with check in/out functionality, some basic version tracking capability and to be able to export the database for easy backup.
Is there any software like this that is free?
Thanks for your help!
|
|
|
|
|
Subversion[^] comes to mind.
There are a few free version management applications discussed here[^].
|
|
|
|
|
I'll second that.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
I have used Perforce - I believe a 1 or 2-user license is free.
HTH
|
|
|
|
|
I'm trying Perforce. It runs good I'm just trying to figure out how to use it. Not sure of the funtions of different views.
It actually does exactly what I hoped I could. I already have server and client on my home computer and I plan to setup a client version on my work computer. running over the internet.
Hopefully it all works. Looks good though.
Thanks!
|
|
|
|
|
I use VisualSVN, the server is free and is subversion based. TortouiseSVN is the good for the client side and is free as well. VisualSVN provides a low cost Visual Studio plug in that runs on top of TortuoiseSVN that I think is well worth it.
|
|
|
|
|
Netblue wrote: VisualSVN
That is really nice to add to subversion
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
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
|
|
|
|
|