|
I think there is an ObsoleteAttribute to handle this situation, isn't it ?
|
|
|
|
|
|
Cool - thanks.
I somehow missed this link earlier.
|
|
|
|
|
So in other words, instead of a "Do not use" comment, it really should say, "Don't forget to cast".
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
|
|
|
|
|
|
Here is a code sample from Q&A. Obviously a beginner (so I won't say where or who to spare the OP's blushes) but "How not to do it: convert from ascii to an array of bits":
array< array< int >^ >^ chartobin(array^arr,int length,int imgsize1)
{
int ascii;
array< array< int >^ >^ messag= gcnew array< array< int >^ >(imgsize1);
for(int i=0;i<imgsize1;i++)>
{
messag[i] = gcnew array(8);
}
for(int x= 0;x<length;x++)>
{
ascii =(int) arr[x];
int* binary_reverse = new int [9];
int* binary = new int [9];
int y = 0;
while(ascii != 1)
{
if(ascii % 2 == 0)
{
binary_reverse[y] = 0;
}
else if(ascii % 2 == 1)
{
binary_reverse[y] = 1;
}
ascii /= 2;
y++;
}
if(ascii == 1)
{
binary_reverse[y] = 1;
y++;
}
if(y < 8)
{
for(; y < 8; y++)
{
binary_reverse[y] = 0;
}
}
for(int z = 0; z < 8; z++)
{
binary[z] = binary_reverse[7 - z];
if(binary[z]==0)
{
binary[z]=-1;
}
}
for(int z = 0; z < 8; z++)
{
messag[x][z]=binary[z];
}
delete [] binary_reverse;
delete [] binary;
}
return messag;
}
You should never use standby on an elephant. It always crashes when you lift the ears. - Mark Wallace
C/C++ (I dont see a huge difference between them, and the 'benefits' of C++ are questionable, who needs inheritance when you have copy and paste) - fat_boy
|
|
|
|
|
Yes a bit of a horror, but, yes there is a but, without knowing what was the driver for this question or what the OP was upto, they might have been forced to do it this way, particularly if they are on a programming course etc.
I am currently doing a degree with the OU, and it is all based around Java. The question papers etc, sometimes tell you must do some things a certain way and not use other methods (or built in libraries/extensions etc.
The last paper I was doing was based around threads, it had the 'main' thread, and 3 other worker threads. We had to use semaphores/countdown latches etc. to ensure the workers were finished before the main thread did something, rather than a simple join.
|
|
|
|
|
I know what you mean, but I think what got me was the way you could see the OP original thought process run through the whole thing:
"Good that works."
"Damn, forgot the last digit. That fixes it"
"Bugger, forgot the zeros if there are any left over...better put them in."
"What do you mean its back to front - sod it!"
"Oh, yes, I had better include it in the output..."
Without at any time wanting to change what the OP already has that is working (sort of)!
I do find that a reluctance to look back and change partly broken code does cause a lot of horrors...
You should never use standby on an elephant. It always crashes when you lift the ears. - Mark Wallace
C/C++ (I dont see a huge difference between them, and the 'benefits' of C++ are questionable, who needs inheritance when you have copy and paste) - fat_boy
|
|
|
|
|
On a different note from my other post on this, i am a hobbyist programmer and do not do it as my day-to-day line of work. As a result of this i have many many times found myself producing completely bizarre code to do a task, only to find out that there a specific classes/methods available within the .net framework, usually resulting in me giving myself a slap.
Its one of those......experience makes a difference.....kind of things i guess.
|
|
|
|
|
One of the first things I did wen I learned C# was to translate a bunch of my C routines -- only to find that a lot of them were already built-in.
|
|
|
|
|
I also loved:
int* binary_reverse = new int [9];
int* binary = new int [9];
...
|
|
|
|
|
I almost read it as "Beginners Suck" 
Two heads are better than one.
|
|
|
|
|
Why did the hair on the back of my neck stand up when I looked at this?
Dim IsPresCheck As CheckBox = CType(FormView1.FindControl("IsPrestigeChkBx"), CheckBox)
If IsPresCheck.Checked = "True" Then
SqlDataSource1.SelectParameters.Add("IsPrestige", System.TypeCode.Int32, 1.ToString)
Else
SqlDataSource1.SelectParameters.Add("IsPrestige", System.TypeCode.Int32, 0.ToString)
End If
Steve Wellens
|
|
|
|
|
Do you have stringy hair?
|
|
|
|
|
Because they couldn't take it sitting down!
*rim shot*
|
|
|
|
|
That reminds me of a coding horror I experienced long ago.
The value of an option was set on the server side, and that should determine if a checkbox on the client side was already checked or not. It worked well on all development computers, only on one terminal server - which was used for testing - that failed. I checked if the value was translated correctly from server to client ("false" was always a 0, but "true" was usually -1, sometimes +1, and rarely something else) - I got the correct bool value. I drilled further down the code and eventually stumbled over a great function (I am not sure if I reproduce that correctly, as I wrote vb code only several years ago):
Sub ApplyOptionValue(Value as String)
Value = Uppercase(Value)
If Value = "WAHR" Then
checkBox1.Checked = 1
Else If Value = "FALSCH" Then
checkBox1.Checked = 0
Else
checkBox1.Checked = 0
End If
When you pass a bool to a function which expects a string, VB just translates that bool to a string. On our development machines, we had the German version of Visual Studio, so a "True" was translated to "Wahr", but on the test machine, the relevant dll was in US English version, and hence the true value was "True", not "Wahr".
Also note that the original programmer already considered such a case where the value was neither true nor false...
|
|
|
|
|
Who came up with the notion that implicit conversions should be anything other than culture-invariant? That's a "coding horror" right there, IMHO.
|
|
|
|
|
You can use GEL to hold your hairs 
|
|
|
|
|
A coworker of mine found this lovely little gem in .NET 2.0 CF.
From the reflected code of ManualResetEvent.WaitOne:
public override bool WaitOne(int millisecondsTimeout, bool exitContext)
{
if ((millisecondsTimeout < 0) && (millisecondsTimeout != -1))
{
throw new ArgumentOutOfRangeException("millisecondsTimeout");
}
if (exitContext)
{
throw new ArgumentException(null, "exitContext");
}
int num = PAL.Threading_Event_WaitTimeout(this.Handle, millisecondsTimeout);
if (num == -2147483623)
{
return false;
}
return base.CheckResultInternal(num == 0);
}
Microsoft only gives you the illusion of having a choice for exitContext.
|
|
|
|
|
The method signature is overridden from the base class, so exitContext has to be in the parameter list, even though it has no meaning in the context of a ManualResetEvent
"An eye for an eye only ends up making the whole world blind"
|
|
|
|
|
It would just seem since all the classes that derive from WaitHandle all throw an exception when exitContext is true that Microsoft would just remove that parameter entirely.
In the Compact Framework, Microsoft was notorious for changing/removing signatures to suit their needs. I didn't see why they couldn't do so as well here. It would surely make the code less horrific.
|
|
|
|
|
Andrew Rissing wrote: It would just seem since all the classes that derive from WaitHandle all throw an exception when exitContext is true that Microsoft would just remove that parameter entirely.
In general, the real question should be whether some future derived object might want to do something with that parameter. It's not unreasonable for some overridable functions to e.g. take a parameter of type Object even if none of the initial implementations make any use of it. The situation may in someways be equivalent to some gvprintf() implementations which accept a function pointer to a character-output function that takes a char and a void pointer, along with a void pointer which will be passed to the character-output function. The gvprintf() function never does anything with the void pointer but pass it on, but implementations of fprintf, sprintf, etc. use the pointer to pass a reference to the output file or destination string.
In this case, my thinking is that Microsoft was thinking they might someday support exiting a Monitor context while within a WaitHandle's wait routine; having the parameter exist would allow them to add such support without breaking existing code, at least in theory. Of course, if code that holds a lock calls some other code that makes use of ExitContext and the code holding the lock isn't expecting that, problems could easily ensue.
|
|
|
|
|
Why not introduce the additional overload when there actually exists at least one implementation of it?
First we'd have this situation:
public abstract class AbstractThing
{
abstract public void Foo(MyOtherThing t);
}
public class ConcreteThing1 : AbstractThing
{
override public void Foo(MyOtherThing t) { ... }
}
Then we'd introduce the additional overload, defaulting to the previously defined behavior when our new exitContext parameter is false:
public abstract class AbstractThing
{
abstract public void Foo(MyOtherThing t);
virtual public void Foo(MyOtherThing t, bool exitContext)
{
if (exitContext)
throw new NotSupportedException();
Foo(t);
}
}
public class ConcreteThing1 : AbstractThing
{
override public void Foo(MyOtherThing t) { ... }
}
At least in this particular case this ought to work fine, and it doesn't break and descendant classes since it doesn't introduce any new abstract members.
|
|
|
|
|
Pay no attention to that code behind the interface.
|
|
|
|
|
While the exitContext bit is indeed a bit icky, I find this line upsetting as well -
if ((millisecondsTimeout < 0) && (millisecondsTimeout != -1))
That should probably be replaced with the functionally equivalent (unless I'm mistaken) and more efficient
if(millisecondsTimeout < -1)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
