|
Taka Muraoka wrote: I haven't really bothered looking too deeply into IL but as a hard-core C++ guy, it certainly doesn't make any sense.
The IL is much closer to reading assembly than anything else, but it can sometimes reveal some interesting results.
Taka Muraoka wrote: Well, it doesn't really make any sense from a general OO point of view, either
I can't disagree with this. I was only saying why I think it might have been done that way.
Taka Muraoka wrote: Just stepping through in the debugger. Modifying it in the code sample in my OP to return null seems to have no ill effects.
What you are seeing is actually correct behavior for your code. You have explicitly defined the IEnumerable<T>.GetEnumerator() and implicitly defining the IEnumerable.GetEnumerator(). Since IEnumerable.GetEnumerator() is public (and implicit) this code gets called. There are a few ways to change this so it calls the generic enumerator:
1: Leave your class X defined as is, and change the call in the foreach loop to read
foreach (int n in (IEnumerable<int>)x)
{
System.Console.WriteLine(n);
} 2: Leave the foreach call as is, and change X to read:
class X : IEnumerable<int>
{
private List<int> mList = new List<int>();
public X()
{
mList.Add(1); mList.Add(2); mList.Add(3);
}
IEnumerator<int> IEnumerable<int>.GetEnumerator()
{
return mList.GetEnumerator();
}
IEnumerator IEnumerable.GetEnumerator()
{
return mList.GetEnumerator();
}
} or
class X : IEnumerable<int>
{
private List<int> mList = new List<int>();
public X()
{
mList.Add(1); mList.Add(2); mList.Add(3);
}
public IEnumerator<int> GetEnumerator()
{
return mList.GetEnumerator();
}
IEnumerator IEnumerable.GetEnumerator()
{
return mList.GetEnumerator();
}
}
Scott.
—In just two days, tomorrow will be yesterday.
—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
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
Scott Dorman wrote: 1: Leave your class X defined as is, and change the call in the foreach loop to read
foreach (int n in (IEnumerable<int>x)
{
System.Console.WriteLine(n);
}
This is obviously kinda ugly. The intent of deriving from IEnumerable<T> is to enforce type-safety and I was hoping that the compiler would be smart enough to realize that X can only be iterated over using int's and nothing else.
Scott Dorman wrote: 2: Leave the foreach call as is, and change X to read:
Both these work but there are still some oddities.
The following code compiles but throws a cast exception at runtime, which is what one (or at least I) would expect:
class X
{
private List<int> mList = new List<int>() ;
public X() { mList.Add(1) ; mList.Add(2) ; mList.Add(3) ; }
public IEnumerator GetEnumerator() { return mList.GetEnumerator() ; }
}
foreach ( X n in x )
System.Console.WriteLine( n ) ;
But using the modified foreach with either of your #2 code samples doesn't even compile ("Cannot convert int to X"). So it seems that there's now no way to get into the non-generic GetEnumerator()  I don't particularly want to but it annoys me that I have to define this method but it never gets used 
So, it looks like foreach is ignoring whether the object it's iterating over derives from IEnumerable or IEnumerable<T> and just looks for a public GetEnumerator() method (which is kinda lame). But then how does it know which GetEnumerator() to use in your 2a code? Both of them are public in their respective interfaces, and yes, I tried reversing the order they are defined in I was kinda hoping the compiler could infer which one to use by the type being used in the foreach statement but for some reason, it's only allowing the generic one to be used.
Oh well, I guess we can just chalk this one up to C# evolving on the fly. Thanks for your help.
I enjoy occasionally wandering around randomly, and often find that when I do so, I get to where I wanted to be [^].
Awasu 2.3.2 [^]: A free RSS/Atom feed reader with support for Code Project.
|
|
|
|
|
Taka Muraoka wrote: This is obviously kinda ugly. The intent of deriving from IEnumerable<t> is to enforce type-safety and I was hoping that the compiler would be smart enough to realize that X can only be iterated over using int's and nothing else.
I can't disagree with you here. I pointed this out as an option...I never said it was a good one.
Taka Muraoka wrote: Both these work but there are still some oddities.
What are the oddities?
Taka Muraoka wrote: But using the modified foreach with either of your #2 code samples doesn't even compile ("Cannot convert int to X"). So it seems that there's now no way to get into the non-generic GetEnumerator()
That is correct. By deriving X from IEnumerable<int> you are effectively telling the type system that when you enumerate over X (by calling GetEnumerator) that you are returning a type of int not X. Isn't that the point of providing the strongly typed version? You (and the compiler) know at compile time what the data type will be, so there is no need for it to call the non-typed version.
Taka Muraoka wrote: I don't particularly want to but it annoys me that I have to define this method but it never gets used
True, but that's how interfaces work. If you derive from an interface you have to implement all of the methods defined in the contract.
Taka Muraoka wrote: So, it looks like foreach is ignoring whether the object it's iterating over derives from IEnumerable or IEnumerable<T> and just looks for a public GetEnumerator() method (which is kinda lame). But then how does it know which GetEnumerator() to use in your 2a code? Both of them are public in their respective interfaces, and yes, I tried reversing the order they are defined in I was kinda hoping the compiler could infer which one to use by the type being used in the foreach statement but for some reason, it's only allowing the generic one to be used.
I'm not sure I would say that it's ignoring the interfaces. It knows to use the generic GetEnumerator in the 2a example based on the type defined in the foreach loop. The key is which method is defined explicitly or implicitly. In my 2a example, they are both explicitly defined (notice there is not a public keyword). These methods aren't available unless the object is explicitly cast to the correct interface, which the compiler is being smart enough to do for you based on the underlying type of the List<T>. When you declare one of them as public you are telling the compiler that this is the one you want to use by default.
Scott.
—In just two days, tomorrow will be yesterday.
—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
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
Scott Dorman wrote: By deriving X from IEnumerable<int> you are effectively telling the type system that when you enumerate over X (by calling GetEnumerator) that you are returning a type of int not X. Isn't that the point of providing the strongly typed version? You (and the compiler) know at compile time what the data type will be, so there is no need for it to call the non-typed version.
That's right, this is the behaviour I want but I was playing with the code you gave because I wanted to get a better handle on what was really going on. I was wondering if the non-generic GetEnumerator() would get called if I tried to iterate using something other than int's. But see my next comment...
Scott Dorman wrote: If you derive from an interface you have to implement all of the methods defined in the contract.
Maybe the problem is because I'm still thinking in C++. If I write a C++ class that derives from an interface that in turn derives from another interface, my class has to effectively implement two interfaces. This is reinforced by the fact that I have to implement both versions of GetEnumerator(). So it seems to me that I should be able to foreach over an X using int's (via the generic interface) or using object's (via the non-generic interface). But it seems the compiler is unable to infer which one to call and onlys allow access to the generic one, giving a compile error if you try to "use" the non-generic one. Are there rules governing this i.e. why not the other way around?
Scott Dorman wrote: The key is which method is defined explicitly or implicitly.
Maybe this is the problem, I don't quite understand what the difference is. No such thing exists in C++ - if a method is pure virtual, you have to implement it, end of story.
The fact that your 2b code works really makes me think foreach is ignoring the interface hierarchy and just looks for a public GetEnumerator() method. But on the other hand, the generic GetEnumerator() definition in 2b must be equivalent to the one in 2a (i.e. 2 different ways of defining the same thing, otherwise the compiler would be complaining about an un-implemented interface method) but so then, why does declaring it public make a difference?!
Scott Dorman wrote: When you declare one of them as public you are telling the compiler that this is the one you want to use by default.
I thought you couldn't change the access privilege when implementing interface methods? So both X's GetEnumerator's are already public, because that's how they're defined in their respective interfaces.
Having this compile:
public IEnumerator GetEnumerator() { ... }
but not this:
public IEnumerator IEnumerable.GetEnumerator() { ... }
just seems bizarre to me  Unless the former is a brand new definition of GetEnumerator() that has nothing to do with either of the two interfaces (hence my suspicion foreach is ignoring them). Aaargh, now I'm really confused 
I enjoy occasionally wandering around randomly, and often find that when I do so, I get to where I wanted to be [^].
Awasu 2.3.2 [^]: A free RSS/Atom feed reader with support for Code Project.
modified on Wednesday, January 30, 2008 10:35:32 AM
|
|
|
|
|
Taka Muraoka wrote: That's right, this is the behaviour I want but I was playing with the code you gave because I wanted to get a better handle on what was really going on. I was wondering if the non-generic GetEnumerator() would get called if I tried to iterate using something other than int's.
That's probably the best way to understand it. Hopefully it is clearer for you know.
Taka Muraoka wrote: If I write a C++ class that derives from an interface that in turn derives from another interface, my class has to effectively implement two interfaces. This is reinforced by the fact that I have to implement both versions of GetEnumerator().
This is the same in C#. Your class X derives from the IEnumerable<T> interface, which derives from IEnumerable, so you end up having to implement both interfaces. Since each interface defines a method named GetEnumerator you must specifically tell the compiler which method is being implemented.
Interface declarations in C# do not allow you to specify an access modifier. If it's declared in an interface it's a public method or property. In order to declare the same-named method from two different interfaces you must "inform" the compiler how to tell them apart.
Ordinarily when you implement an interface, you simply define the body for the matching method signature:
public IEnumerator GetEnumerator() { ... } Since (for this part of the example) there is only one method named GetEnumerator the compiler is able to determine which method implements the interface. However, when you add the IEnumerator<T> interface you now have an ambiguous match. In order to resolve that ambiguity, one (or both) of the methods must be defined "in terms of their interface". This is what is meant by an explicit implementation. You are explicitly declaring that you are implementing the IEnumerable.GetEnumerator method.
The key thing here is that when you explicitly implement an interface member you cannot specify an access modifier. It's an implied accessibility, which is something I call "psuedo-public". That is, it's a public member but is not visible unless the object is explicitly cast to that interface.
So, in my example
class X : IEnumerable<int>
{
private List<int> mList = new List<int>();
public X()
{
mList.Add(1); mList.Add(2); mList.Add(3);
}
public IEnumerator<int> GetEnumerator()
{
return mList.GetEnumerator();
}
IEnumerator IEnumerable.GetEnumerator()
{
return mList.GetEnumerator();
}
} I am explicitly implementing the IEnumerable.GetEnumerator member. In the calling code, it will default to using the implicit implementation (the public IEnumerator<int> GetEnumerator()) because the call isn't being cast to IEnumerable.
Defining the member in an interface doesn't imply that it is virtual at all. It does imply, however, that you must implement that member. This is different than a pure virtual method in C++ since virtual members must be defined in a class, and abstract members (which is the C# equivalent to pure virtual) must be defined in an abstract class.
Taka Muraoka wrote: The fact that your 2b code works really makes me think foreach is ignoring the interface hierarchy and just looks for a public GetEnumerator() method. But on the other hand, the generic GetEnumerator() definition in 2b must be equivalent to the one in 2a (i.e. 2 different ways of defining the same thing, otherwise the compiler would be complaining about an un-implemented interface method) but so then, why does declaring it public make a difference?!
Hopefuly my answers above make this clearer.
Taka Muraoka wrote: why does declaring it public make a difference?!
Again, hopefuly my answers above make it clearer as to why declaring one of the methods public makes a difference.
Taka Muraoka wrote: I thought you couldn't change the access privilege when implementing interface methods? So both X's GetEnumerator's are already public, because that's how they're defined in their respective interfaces.
You are correct. You can't change the access level when implementing an interface. Remember, everything in an interface is always considered public. However, you can "hide" the implementation so it is only visible when the caller is cast to a specific interface by declaring the implementations explicitly. When you do that, you aren't allowed to specify an access modifier since one is essentially implied.
Taka Muraoka wrote: Having this compile...but not this...just seems bizarre to me Unless the former is a brand new definition of GetEnumerator() that has nothing to do with either of the two interfaces (hence my suspicion foreach is ignoring them).
Again, this is the difference between the implicit and explicit implementations. It isn't a new definition, simply an explicit definition of one of the interface members.
Taka Muraoka wrote: Aaargh, now I'm really confused
Sorry...hopefuly this response hasn't confused you more.
Scott.
—In just two days, tomorrow will be yesterday.
—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
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
Scott Dorman wrote: Defining the member in an interface doesn't imply that it is virtual at all.
Aha! This is the root of my confusion. I was assuming that a C# interface was the same as a C++ interface (i.e. a collection of pure virtual/abstract methods). I remembered reading in the O'Reilly "C# Essentials" book that a C# interface was simply a syntactic shortcut for a bunch of abstract members in an abstract class but their exact wording was "similar to"
The output from the following code gave me a surprise:
interface I
{
void foo( string msg ) ;
}
class A : I
{
public void foo( string msg ) { System.Console.WriteLine( msg+" -> A::foo" ) ; }
}
class B : A
{
public void foo( string msg ) { System.Console.WriteLine( msg+" -> B::foo" ) ; }
}
static void Main()
{
B b = new B() ;
((I)b).foo( "Static type I" ) ;
((A)b).foo( "Static type A" ) ;
((B)b).foo( "Static type B" ) ;
}
--- OUTPUT ---
Static type I -> A::foo
Static type A -> A::foo
Static type B -> B::foo
In C++, the B::foo() method would've been called every time.
No wonder I thought foreach appeared to be ignoring the IEnumerable's in the inheritance hierarchy. In every other OO language I've worked with, to get access to GetEnumerator() you would have to go through the IEnumerable but in C#, deriving from an interface seems to be little more than a directive to the compiler telling it that certain methods need to defined i.e. it doesn't really affect the class as such (e.g. by causing the layout of the v-table to change, or whatever C# uses).
Playing around a little with the definition of B:
class B : A,I
{
void foo( string msg ) { System.Console.WriteLine( msg+" -> B::foo" ) ; }
}
--- OUTPUT ---
Static type I -> A::foo
Static type A -> A::foo
Static type B -> A::foo
That's weird, but I think because B::foo() is not public:
class B : A,I
{
public void foo( string msg ) { System.Console.WriteLine( msg+" -> B::foo" ) ; }
}
--- OUTPUT ---
Static type I -> B::foo
Static type A -> A::foo
Static type B -> B::foo
And how about these two:
class B : A,I
{
void foo( string msg ) { System.Console.WriteLine( msg+" -> B::foo" ) ; }
void I.foo( string msg ) { System.Console.WriteLine( msg+" -> B::foo 2" ) ; }
}
--- OUTPUT ---
Static type I -> B::foo 2
Static type A -> A::foo
Static type B -> A::foo
class B : A,I
{
public void foo( string msg ) { System.Console.WriteLine( msg+" -> B::foo" ) ; }
void I.foo( string msg ) { System.Console.WriteLine( msg+" -> B::foo 2" ) ; }
}
--- OUTPUT ---
Static type I -> B::foo 2
Static type A -> A::foo
Static type B -> B::foo
I think I get it 
Scott Dorman wrote: I am explicitly implementing the IEnumerable.GetEnumerator member. In the calling code, it will default to using the implicit implementation (the public IEnumerator<int> GetEnumerator()) because the call isn't being cast to IEnumerable.
Ah, so by writing IEnumerator IEnumerable.GetEnumerator() { ... } you are saying that this method is only available if your static type (i.e. at compile time) is IEnumerable. I was going to say this seems to break polymorphism but that doesn't apply if the method is not virtual.
Scott Dorman wrote: hopefuly my answers above make it clearer as to why declaring one of the methods public makes a difference.
This I still don't quite get. You were refering to the two GetEnumerator methods but something still seems intuitively wrong: they are implicitly public, because that's how they are defined in their respective interfaces, so explicitly declaring one as public should be redundant but somehow, it actually changes how things work  It certainly did when I was playing around with the definition of B above.
But I'm heartily sick of this, as I'm sure you are. Thanks again for the help 
I enjoy occasionally wandering around randomly, and often find that when I do so, I get to where I wanted to be [^].
Awasu 2.3.2 [^]: A free RSS/Atom feed reader with support for Code Project.
|
|
|
|
|
So I have been working on teaching myself XNA game programming using C#. Next quarter I have a free space in my schedule finally and was considering taking a programming class. My school doesn't offer C# so my question is would java or C++ be more help for me when it comes to c# programming? Hope that makes sense.
|
|
|
|
|
Hi,
Java and C# are very similar languages. I had several years of Java experience when I switched
to C#, where the new things were merely .NET related (that is the base classes, as used
in C#, VB.NET and C++/CLI but not in unmanaged C++).
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.
|
|
|
|
|
keisal wrote: would java or C++ be more help for me when it comes to c# programming?
Either is fine. I knew both before I tried C#, and when I self taught C#, because of my C++ and Java background, it was easy.
"I guess it's what separates the professionals from the drag and drop, girly wirly, namby pamby, wishy washy, can't code for crap types." - Pete O'Hanlon
|
|
|
|
|
I'll 3rd that. Coming from Java, there really wasn't much to learn. It was a really smooth transition. Of course things have changed some since then, but I think you'll have a similar experience.
I don't know much C++, but I'm sure Java is most like C#. Interfaces, single inheritance, etc...
|
|
|
|
|
If you're already reasonably confident in the basics of C# I'd suggest C++.
As others have said, if you're a total novice in C#, knowing some Java really helps get you started. Personally, I'd been using Java, PHP and VB/VB.net and I found the transition fairly smooth. I'd tried C++ with very limited success and always filed it as one of those things that 'I really should learn properly one day'. Now, having used C# for a while, I'm sure I'd be much more confident with and knowlegeable about C++ if i ever find the need, as C# can do pretty much everything I want.
So (I think) it comes dowwn to how advanced you feel you are in C#. An early learner - probably do the Java. Confident/fairly experienced in C# - probably do C++.
Just my 2c. Good luck with which ever you choose (or do them both if you have the time and can handle it!?!).
Dave
|
|
|
|
|
I'd take the C++ class over the Java based one. Nothing is better than learning the master of all language. If you fully understand C# syntax (then to some extent you know simple C syntax) then I'd go and learn the C++. Nothing is better than fully understanding C++. If you do then you can write C++ in any programming language, now and into the future.
The hard part of switch to C++ syntax from a C# style is the operators used. this->setColor(red,green,blue); instead of this.setColor(red,green,blue);
This is the same when switching from C# (or C++) to php or something with similar syntax.
|
|
|
|
|
C# is based mostly on C++, Pascal and Java.
It's a lot of C++ syntax, but without the need to mess with pointers.
It's object oriented like Java.
It's strictly typed like Pascal (and Java).
I think that you should choose your class depending on where you feel that your weaknesses are. If you want to learn about object orientation you should choose Java, if you like to learn about what really happens with bytes and references you should choose C++.
Experience is the sum of all the mistakes you have done.
|
|
|
|
|
I'm using the remove method of a generic list and then saving the class to disk by serialization.
I've noticed that sometimes the data is serialized before the remove has completed, therefore the class gets saved inlcluding the data that should have been removed.
I'm using Application.DoEvents() and it appears to be working but I wondered if this would be reliable, or if there's a better way?
|
|
|
|
|
you can also use backgroundWorker for the same
|
|
|
|
|
Thanks, I don't know why I didn't think of that - do the serialize in the completed event of BackgroundWorker 
|
|
|
|
|
Hello, I'm currently in the midst of taking an assessment test, and I need some help with something. essentially, what I need to do, is dynamically reverse a string as it is entered into a text box, and while it is being reversed, replace every number entered (1,2,3) with it's word equivalent (one,two,three). Now I have the string reversal part nailed with the following function:
<br />
public string Reverse(string x)<br />
{<br />
char[] charArray = new char[x.Length];<br />
int len = x.Length - 1;<br />
for (int i = 0; i <= len; i++)<br />
charArray[i] = x[len-i];<br />
return new string(charArray);<br />
}<br />
My main problem is I am not very sure how to dynamically change the numbers to words as the entered string is being reversed. I am considering using some code along the lines of this:
<br />
public string numCheck(string x)<br />
{ <br />
string[] numbers = { "0", "1", "2", "3", "4", "5", "6", "7", "8", "9" };<br />
string[] words = { "zero", "one", "two", "three", "four", "five", "six", "seven", "eight", "nine" };<br />
string strReplaced = ""; <br />
int i;<br />
for(i=0; i9) <br />
{<br />
strReplaced = x.Replace(numbers[i], words[i]);<br />
x = x.Replace(ch);<br />
}<br />
return x; <br />
}<br />
However, I do not know how to properly insert this into the rest of my program to get the desired result, or even if this is the best way to do it. Thank you in advance.
|
|
|
|
|
You need to include some code in the loop of your main function that checks whether the current character is numeric. If it is, you need to do a lookup to find the word that represents this number and replace the number with its word equivalent.
Paul Marfleet
"No, his mind is not for rent
To any God or government"
Tom Sawyer - Rush
|
|
|
|
|
Lookup? As in a select case statement?
so far after taking your advice I have the following:
<br />
public string Reverse(string x)<br />
{<br />
char[] charArray = new char[x.Length];<br />
int len = x.Length - 1;<br />
for (int i = 0; i <= len; i++)<br />
if(char.IsNumber())<br />
{<br />
<br />
}<br />
charArray[i] = x[len-i];<br />
return new string(charArray);<br />
}<br />
I suppose my next dilemma is trying to figure out what goes into that if statement, I believe my best bet is some sort of select case statement, though the last time I tried that resulted in error. And I'm still trying to figure out what to about the IsNumber(), or rather what I need to put between those parenthesis.
|
|
|
|
|
BREdwards wrote: Lookup? As in a select case statement?
Select...Case. Array lookup. Hashtable lookup. These are all viable options.
BREdwards wrote: I suppose my next dilemma is trying to figure out what goes into that if statement, I believe my best bet is some sort of select case statement, though the last time I tried that resulted in error. And I'm still trying to figure out what to about the IsNumber(), or rather what I need to put between those parenthesis.
Keep trying and you'll get there. Good luck .
Paul Marfleet
"No, his mind is not for rent
To any God or government"
Tom Sawyer - Rush
|
|
|
|
|
First off, I'd say this should be in the KeyPress event handler.
The replacements can be done with a switch or Dictionary.
I expect the quickest way to do the reversal is to set the insertion point back to the start of the text with SelectionStart=0 after each character is added, but the user could move the insertion point so handle Click as well.
No, wait, set RightToLeft=true 
|
|
|
|
|
Thanks so far. The string reversal part is all taken care of, my problem is having to dynamically replace all number with their word equivalents, here's what I have so far:
<br />
public string Reverse(string x)<br />
{<br />
int i;<br />
char[] charArray = new char[x.Length];<br />
int len = x.Length - 1;<br />
for ( i = 0; i <= len; i++)<br />
if(char.IsNumber(x,i))<br />
{<br />
switch(i)<br />
{<br />
case'0':<br />
x.Replace("0","zero");<br />
break;<br />
}<br />
}<br />
charArray[i] = x[len-i];<br />
return new string(charArray);<br />
}<br />
I have something of an idea of what needs to be done, problem is, I can't seem to use that if statement without breaking the program. I keep getting an "index was outside the bounds of the array error" for both letters and numbers. I simply don't understand what I'm doing wrong, never had to do something like this before.
|
|
|
|
|
Try this for the reversal (not taken care of if you have an error message  ):
public string Reverse(string x)
{
char[] charArray = x.ToCharArray();
Array.Reverse(charArray);
return new string(charArray);
}
|
|
|
|
|
public string Reverse(string x)
{
char[] charArray = x.ToCharArray();
Array.Reverse(charArray);
return new string(charArray);
}
private static class NumericStringRepresentations
{
private static Hashtable _PairsTable = new Hashtable(9);
public static Hashtable PairsTable
{
get { return _PairsTable; }
}
static NumericStringRepresentations()
{
_PairsTable.Add("0", "zero");
_PairsTable.Add("1", "one");
_PairsTable.Add("2", "two");
_PairsTable.Add("3", "three");
_PairsTable.Add("4", "four");
_PairsTable.Add("5", "five");
_PairsTable.Add("6", "six");
_PairsTable.Add("7", "seven");
_PairsTable.Add("8", "eight");
_PairsTable.Add("9", "nine");
}
}
public string NumbersToStrings(string x)
{
string returnString = "";
if (!(x.Length == 0))
{
for (int i = 0; i < x.Length; i++)
{
string thisCharacter = x.Substring(i, 1);
int returnedInt;
if (int.TryParse(thisCharacter, out returnedInt))
{
returnString += NumericStringRepresentations.PairsTable[thisCharacter];
}
else
{
returnString += thisCharacter;
}
}
}
return returnString;
}
|
|
|
|
|
Marvelous! I was planning to use an array, but this works as well. Thank you, I'll be sure to save this so I can study later. However, when compiled, it delivers an error saying: "The Modifier 'static' is not valid for this term."
After a bit of research, I found that my version of VS is too old to have static as a modifier for the class, as I am using 2003 still.
Anyhoo, thanks for eveything.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
