|
If you don't intend the loop to finish, consider using a while loop instead.
Christian Graus - Microsoft MVP - C++
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
Please don't do this. It's really bad practice because it indicates that you haven't really thought about what you are trying to do. There are other constructs that are better suited to this:
bool found = false;
int counter = 0;
do
{
if (loop[counter] == 1)
found = true;
} (while !found || ++counter == loop.Count);This doesn't rely on any "hacks". Seriously, if you find that your design implements the for (...)break; pattern then consider using a different loop.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Does anyone have any tips or helpful pieces of info for a newbie programmer? Any piece of info is welcome, such as recommended sites, any tips, or even some basic knowledge of C#. Thankyou anyone who reads this and replys, an thanks in advance. -M.S.
|
|
|
|
|
Practice : And practice. And then some more. You can't beat it. Write lots of code - when it works, look at it and understand why it works. When it doesn't, post it here. There are hundreds of people on this forum who enjoy helping the newbies, but only if it seems they have had ago themselves.
Read : Browse the articles here, pick one that is interesting, download the source, and understand it. Don't just cut and paste into your own app - understand what you are cutting and pasting.
Program : Pick a very simple app to write (winform or web ) - such as a CD library. You will have to work on UI design, data access layers etc.
Enjoy : If you don't enjoy what you are doing, don't do it.
Share : If you flick through the articles, they all tackle a specific element. YOu could write an article of how you wrote your first app - ie the CD Library. The problems you hit, how you solved them. Or Blog about it. Link the blog to your sig - you could become a cult coder and we all follow your trials and tribulations as you make your first listbox populate from an access database!
"More functions should disregard input values and just return 12. It would make life easier." - comment posted on WTF
"This time yesterday, I still had 24 hours to meet the deadline I've just missed today."
|
|
|
|
|
1 - buy some good books and work through them. There's no substitute early on for having everything presented in one place, so nothing is missed
2 - set yourself realistic goals. Look for ways to take bite sized chunks so that you continuously learn new things, and learn to do them well. Trying to go too far at once, you get a basic idea and end up cutting and pasting lots of forum code
3 - when you ask for help on a forum and you're given a code snippet, look for any code you don't understand and use google/MSDN to find out exactly what it does. Try changing it and see what other options you have within that sort of code.
Above all, just keep going. We're all still learning, it's just that the longer you've been going, the quicker you learn and the more you already know ( obviously )
Christian Graus - Microsoft MVP - C++
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
Hi, i'm building a solution that has plenty of forms interacting with each other, based on MDI Parent - child model.
I created instances of them, never closing, just hiding those. I've also got some other forms that perform some analysis that might take a while. What i'm wondering  is if it would be a good approach to make this calls to modalform on a different thread, or to only perform the long tasks on these forms on different thread in order to prevent the app to hold.
Thanks for your time. I appreciate all suggestions.
daniel sovino
|
|
|
|
|
Hi,
the rule is to perform long (over 30 msec) operations on extra threads, and all GUI stuff
on the main thread (because Controls are not thread-safe, so having other threads access
some Controls will eventually hang the app).
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
Which is better according to coding standard for c#?
this:
<br />
public bool isDraggable<br />
{<br />
get { return _draggable; }<br />
set { _draggable = value; }<br />
}<br />
or this:
<br />
public bool isDraggable{ get; set; }<br />
without using private members? Or is this a matter of personal choice?
rather have something you don't need, than need something you don't have
|
|
|
|
|
There is no overall C# standard.
The second method isn't very useful.
only two letters away from being an asset
|
|
|
|
|
The first code snippet would be a reasonable way to implement accessors for a property in a class.
The second snippet looks like a property declaration for an Interface.
I suggest you read up on the differences between classes and interfaces if you do not understand the difference between these two pieces of code.
Paul Marfleet
|
|
|
|
|
pmarfleet wrote: The second snippet looks like a property declaration for an Interface.
it does, but you can use it in a normal class as well
rather have something you don't need, than need something you don't have
|
|
|
|
|
donsolms wrote: it does, but you can use it in a normal class as well
You can - but it doesn't actually accomplish much.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
You are wrong. What it does is to implicitely create a private field which is accessed (I think this was introduced with .Net 3.5). Up to there you could just create a public field instead but this one has the advantage that you can replace it with a real property/field pair at any time without having to change anything on accessing classes.
Robert
|
|
|
|
|
Robert Rohde wrote: You are wrong. What it does is to implicitely create a private field which is accessed (I think this was introduced with .Net 3.5). Up to there you could just create a public field instead but this one has the advantage that you can replace it with a real property/field pair at any time without having to change anything on accessing classes.
Only from .NET 3.5 onwards. At the time of replying to this post, we had no idea that the poster was using Orcas and not asking questions about current versions of .Net.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
donsolms wrote: Which is better according to coding standard for c#?
this:
public bool isDraggable
{
get { return _draggable; }
set { _draggable = value; }
}
or this:
public bool isDraggable{ get; set; }
without using private members? Or is this a matter of personal choice?
Well - the 1st is a better coding standard because it actually does something. The second doesn't actually accomplish anything. You would normally use the second one in an interface.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
donsolms wrote: Which is better according to coding standard for c#?
this:
public bool isDraggable
{
get { return _draggable; }
set { _draggable = value; }
}
or this:
public bool isDraggable{ get; set; }
without using private members? Or is this a matter of personal choice?
Hi,
For Orcas, I thought that these were essentially identical, that the compiler would generate some private fields for you. Perhaps I've missed something - I'm living in a .NET 2.0 world - but, that was my understanding of it. I suspect someone will correct me if I'm wrong.
Hope that helps.
It isn't enough to do well in life.
One must do good when and where one can.
Otherwise, what's the point?
|
|
|
|
|
that's what I thought as I'm in Orcas. I'll just stick to my usual style. Thanks for everyone's feedback
rather have something you don't need, than need something you don't have
|
|
|
|
|
as a general comment if you're asking about something new in a beta/just released version it's generally best to indicate it to avoid confusion.
--
If you view money as inherently evil, I view it as my duty to assist in making you more virtuous.
|
|
|
|
|
Matthew Cuba wrote: the compiler would generate some private fields
Ew, I wouldn't want that. Having the compiler create a default constructor is one thing, but generating fields? Yuck!
|
|
|
|
|
Matthew Cuba wrote: For Orcas, I thought that these were essentially identical
That is true, .NET 3.5 introduced the idea of automatic properties. The only drawback is that it doesn't provide any way to do validation and you must always have both a get and a set.
|
|
|
|
|
My preference would almost always be the first example. The second example is good if you can guarantee that you will never need to do anything more advanced in the property getter or setter. Both of thees example are equivalent, with the second one allowing the compiler to automatically generate the backing variable.
I have used both styles, and generally only use the second for very simple classes and structs.
For future reference, you should be clear that you are referring to a .NET 3.5 (Orcas) feature, especially with this question as the second example is also the way a property is defined in an interface.
|
|
|
|
|
Scott Dorman wrote: with the second one allowing the compiler to automatically generate the backing variable.
<rant>
Man, that's gotta be about the dumbest thing I've heard Microsoft do recently. Does that mean even the class itself is required to use the property? I hope the calls will be inlined.
</rant>
On the other hand, maybe they're trying to entice more VB programmers to C#, that's a worthwhile goal.
|
|
|
|
|
PIEBALDconsult wrote: maybe they're trying to entice more VB programmers to C#, that's a worthwhile goal
That's polluting the gene pool - we wouldn't want that.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
In theory, I agree with you. In practice, however, I don't mainly because there are already a lot of cases where Microsoft is generating code for you. If you use any .NET remoting or serialization, the JIT is compiling an entire assembly on-the-fly at runtime for you; the using statement, ~T (finalizer), anonymous delegates, and generics all generate code at compile time on your behalf. There really isn't a way around it anymore...if you use .NET at somepoint Microsoft is generating code for you either at compile time, run time, or both.
PIEBALDconsult wrote: Does that mean even the class itself is required to use the property?
I'm not sure what you mean by this. In the class, when you want to reference the property you use it just like you would any other property. The only difference is that there isn't an excplict backing variable that you could access instead, so you always use the property.
PIEBALDconsult wrote: I hope the calls will be inlined.
How would this matter? I don't believe they are, since this is really just more syntatic sugar, the compiler treats them just like it would any other property.
|
|
|
|
|
Scott Dorman wrote: The second example is good if you can guarantee that you will never need to do anything more advanced in the property getter or setter.
Well you can change it to a "real" property and field combo any time you want. Accessing classes won't notice the difference.
Robert
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
