|
Sounds like a good fit for a watchdog-application; how about simply getting a list of the running tasks and the CPU-utilization? If you notice any application hogging a CPU, you mail.
Doesn't protect you just against your application from going nuts, but other processes as well. Doesn't need a UI, nor much code
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
If you don't mind can you please provide me a small code snippet or links for it?
Thanks,
Abdul Aleem
"There is already enough hatred in the world lets spread love, compassion and affection."
|
|
|
|
|
|
how to remove Flag status from Outlook by c# programming or register edit
|
|
|
|
|
|
That is done as described on MSDN.
You're welcome
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
I am not getting proper solution. Please give me proper answer.
|
|
|
|
|
As a programmer, one of the best skills you can learn is how to use Google effectively. If you look at the search terms I use here[^] , you can see how easy it is for you to find the answer you want (look at the top answer to get started).
This space for rent
|
|
|
|
|
Hello community,
I'm refactoring a C# application and found 7 (!) methods which do quite the same thing to different parameters. These parameters are LINQ-results.
private void Doit_T(IEnumerable<string> T) {...}
private void Doit_R(IEnumerable<int> R) {...}
private void Doit_C(IEnumerable<int> C) {...}
private void Doit_TR(IEnumerable<string,int> TR) {...}
private void Doit_TC(IEnumerable<string,int> TC) {...}
private void Doit_RC(IEnumerable<int,int> RC) {...}
private void Doit_None() {...}
This sounds like a case for overloading. It would reduce the 7 methods to 5, as there are 5 distinct combinations of parameter types:
private void Doit(IEnumerable<string> T) {...}
private void Doit(IEnumerable<int> R_or_C) {...}
private void Doit(IEnumerable<string,int> TR_or_TC) {...}
private void Doit(IEnumerable<int,int> R_and_C) {...}
private void Doit() {...}
Better than before. But can it get shorter?
As the logics within these methods are quite, but not totally identical, I'd like to unify these methods to just one which "senses" the 7 cases (or gets them passed via a string like "RC" or "T"). The catch is the number and type of arguments of this unified method:
0, 1 or 2 arguments --> optional arguments via default values needed.
different IEnumerable-types --> Generic Approach using IEnumerable<t>.
I lack experience on combining those two needs. What could a "unified" method signature look like?
Thanks
Atrus
modified 21-Jun-17 2:34am.
|
|
|
|
|
atrus2711 wrote: IEnumerable<string,int>
There is no IEnumerable<T1, T2> interface in the framework. Did you mean IEnumerable<KeyValuePair<TKey, TValue>> ?
atrus2711 wrote: What could a "unified" method signature look like?
Without knowing what the methods are doing, that's almost impossible to answer. The obvious suggestion would be:
private void Doit<T>(IEnumerable<T> values) { ... }
That may or may not work, depending on the differences between the methods, and what you mean by IEnumerable<T1, T2> .
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
my fault, my explanation was too compressed...
Take this excerpt of method Doit_R. It isolates the distinct values of a single column:
var result = SomeList.Select(c => c.IntegerField).Distinct();
Here, result is an IEnumerable<int>.
Doit_RC gathers distinct values of two columns, both ints:
var result = SomeList.Select(c => new { c.IntegerField1, c.IntegerField2}).Distinct();
Here, result is an IEnumerable of an anonymous type, consisting of two ints.
Doit_TR gathers distinct values of two columns, a string and an int:
var result = SomeList.Select(c => new { c.StringField, c.IntegerField}).Distinct();
Here, result is an IEnumerable of an anonymous type, consisting of a string and an int.
A unified method should be able to deal with all of these IEnumerables.
How could this be done?
Thanks
|
|
|
|
|
Something like this?
private void DoIt<TSource, TResult>(IEnumerable<TSource> source, Func<TSource, TResult> selector, IEqualityComparer<TResult> comparer = null)
{
...
var result = source.Select(selector).Distinct(comparer);
...
}
DoIt(SomeList, c => c.IntegerField);
DoIt(SomeList, c => new { c.IntegerField1, c.IntegerField2 });
DoIt(SomeList, c => new { c.StringField, c.IntegerField });
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I'll test that. Looks promising...
Thanks, I'll be back tomorrow.
|
|
|
|
|
Yup, it works!
Thank you very much!
Regards
Atrus
|
|
|
|
|
edit #1: fixed errors in code example.
Before getting to the question I have about this new syntax/facility, I thought it would be good to review the facility, first ... to establish context.
Using value tuples allows you a neat way to package up a bunch of named values without ALOTT (a lot of tedious typing):
public class Name
{
public Name(string first = null, string middle = null, string last = null)
{
FirstName = first;
MiddleName = middle;
LastName = last;
}
public String FirstName { set; get; }
public String MiddleName { set; get; }
public String LastName { set; get; }
public (string first, string middle, string last) FullName
{
set
{
FirstName = value.first;
MiddleName = value.middle;
LastName = value.last;
}
get { return (first: FirstName, middle: MiddleName, last: LastName); }
}
} Use example:
Name nametest1 = new Name(first: "john", last: "doe");
var fullname1 = nametest1.FullName;
string lastname1 = fullname1.last;
Name nametest2 = new Name();
nametest2.FullName = ("judy","a.", "doe");
var fullname2 = nametest2.FullName;
string lastname2 = fullname2.last; I'm curious to know if you intend to make use of this new language facility, and whether you see any advantages to doing so compared to returning a class, or struct, instance. Any gotchas you see in terms of multi-threading, etc. ?
thanks, Bill
«Beauty is in the eye of the beholder, and it may be necessary from time to time to give a stupid or misinformed beholder a black eye.» Miss Piggy
modified 20-Jun-17 12:26pm.
|
|
|
|
|
I don't love it. I can see it degenerating quickly in spaghetti-code; but then I generally avoid standard Tuples anyway in favor of interfaces.
I don't think there are more concurrency issues than you would see with a standard property accessor. There are definitely new gotchas when implementing property update events.
I think this is just another functional feature being stitched in. I don't think this really helps out OOP at all.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Nathan Minier wrote: I generally avoid standard Tuples anyway in favor of interfaces. Thanks; I would be interested in seeing a code sample using an Interface that is an alternative to use of a Tuple.Nathan Minier wrote: There are definitely new gotchas when implementing property update events. That seems right; the fact you can't make the objects in a ValueTuple immutable means at some point an internal value can be changed, and then, the ValueTuple may be out of synch with whatever sources it was built from.
«Beauty is in the eye of the beholder, and it may be necessary from time to time to give a stupid or misinformed beholder a black eye.» Miss Piggy
modified 20-Jun-17 13:04pm.
|
|
|
|
|
BillWoodruff wrote: Thanks; I would be interested in seeing a code sample using an Interface that is an alternative to use of a Tuple.
It's not any more complicated than you think.
interface IExample{
int Number {get;set}
string Text {get;set;}
}
Tuple<int,string> ExampleTuple;
IExample ExampleImplementation;
I've just always felt that Tuples are a quick workaround when you don't have a proper system (or module) design. I think they're fine for proof-of-concept, but avoid them like the plague in production code for maintainability reasons.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
First gotcha is that you omit XML documentation on a member. Your fullname, does it include the birthnames, does it include a title, what?
How is it more readable than returning a known structure? And does it justify the money saved on 'typing'?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
fyi: I'm not evangelizing for use of ValueTuples, I'm inquiring about them.Eddy Vluggen wrote: you omit XML documentation on a member. The post is a short, simplified, example intended to elicit discussion.Eddy Vluggen wrote: How is it more readable than returning a known structure? I do not make the claim it is more readable in every circumstance.Eddy Vluggen wrote: does it justify the money saved on 'typing'? It is useful to know that is not obvious.
thanks, Bill
«Beauty is in the eye of the beholder, and it may be necessary from time to time to give a stupid or misinformed beholder a black eye.» Miss Piggy
modified 20-Jun-17 12:54pm.
|
|
|
|
|
BillWoodruff wrote: fyi: I'm not evangelizing for use of ValueTuples, I'm inquiring about them. I know; I'm playing my part in being sceptical
BillWoodruff wrote: The post is a short, simplified, example intended to elicit discussion. I look forward to seeing it in the wild; anything that can be abused will be.
BillWoodruff wrote: I do not make the claim it is more readable in every circumstance. My apologies for attacking you; I already assumed you weren't referring to "every" circumstance, and also assumed that it would be the main reason to introduce this change to the syntax.
As it looks, for this moment, it is merely a shortcut to prevent one from declaring a complete struct. Which means it is incompatible with older compilers and that some coders will not recognize the new syntax, without the only obvious benefit being that it conveys more information using less symbols (aka, more readable).
Or, in simpeler terms; you asked "when" you'd use the syntax, and I replied with the question "what's in it for me if I do?". It is the basic Garfield-question, "what do I gain with this". Answering that question often answers the "when".
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Hi, Eddy, Skepticism is good fertilizer for the growth of judgement
I, too, see the downsides of using this feature, particularly in a team setting where everyone is not "on the same page."
I think you might find Mads Torgensen's comments on the mutability of ValueTuple interesting: quoted in InfoQ article by Jonathan Allen: [^]Quote: An interesting note about ValueTuple is that it is mutable. Mads Torgersen explains why,
The reasons why mutable structs are often bad, don't apply to tuples.
If you write a mutable struct in the usual encapsulated way, with private state and public, mutator properties and methods, then you are in for some bad surprises. The reason is that whenever those structs are held in a readonly variable, the mutators will silently work on a copy of the struct!
Tuples, however, simply have public, mutable fields. By design there are no mutators, and hence no risk of the above phenomenon.
Also, again because they are structs, they are copied whenever they are passed around. They aren't directly shared between threads, and don't suffer the risks of "shared mutable state" either. This is in contrast to the System.Tuple family of types, which are classes and therefore need to be immutable to be thread safe."
|
|
|
|
|
Aw, a little devil in those details
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Currently, I do not like Tuples because they remove so much information (what's Item1 ?). But with these new Value Tuples, things are changing.
Your example above is a typical textbook example, where I do not see the full power of Value Tuples. In my opinion, their major advantages are with more functional styles of programming, e.g. with Linq.
|
|
|
|
|
Thanks, Bernhard; exactly the type of response I hoped to get.Bernhard Hiller wrote: Your example above is a typical textbook example, where I do not see the full power of Value Tuples. Yes, the example is simple, by design.Bernhard Hiller wrote: ... their major advantages are with more functional styles of programming, e.g. with Linq. I think we all might benefit from a better example illustrating this. I guess you are referring to using Linq to iterate-over or transform some IEnumerable collection of ValueTuples ?
«Beauty is in the eye of the beholder, and it may be necessary from time to time to give a stupid or misinformed beholder a black eye.» Miss Piggy
|
|
|
|
|