|
New values are time dependant. So, the first entry in the array is always the oldest.
Regards,
Dave
|
|
|
|
|
A queue will be best here, refer to Ashfield's reply.
|
|
|
|
|
|
int i=0;
try // you can try if there is an array index and catch it if you are going out of your array bound
{
for(i=0;i<doublearray.legnth;i++)>
{
//it replaces the next index with the current index
doubleArray[i]=doubleArray[i+1];
}
}
// if you call doubleArray[doubleArray.Legnth], actully you have called an out of bound index, so you have made an exception and you can solve it with a try-catch statement
catch
{
//now your newValue is replace as doubleArray[doubleArray.Legnth-1]
doubleArray[i]=newValue;
}
|
|
|
|
|
Sajjad Izadi wrote: for(i=0;i
{
//it replaces the next index with the current index
doubleArray[i]=doubleArray[i+1];
}
Urgh!
It definitely isn't definatley
|
|
|
|
|
Is it just me or is this a REALLY bad idea - deliberatley causing an exception to be thrown?
Throwing an exception in an object is acceptable if a value passed is outside acceptable limts or whatever (although it's normally better to revert to a defalut value and raise an event), but deliberately causing an exception? Yuck!
Dave
|
|
|
|
|
DaveyM69 wrote: Is it just me or is this a REALLY bad idea - deliberatley causing an exception to be thrown?
No, It is not just you. I think it is bad design to use exceptions to handle the "normal and expected" flow of execution. When exceptions where first added to the C++, I started seeing code like:
open file;
try
{
loop forever:
read line from file;
}
catch
{
}
It not usually a good idea to use exceptions to manage the normal flow of execution for a couple of reasons. First, exceptions are expensive to handle so you will almost certainly degrade performance. Also, sprinkling try statements all over the place makes code difficult to read. Conceptually, the whole point of an "exception" is to indicate an exceptional condition (i.e. Out-of-memory) that cannot be easily handled at the time/place the error condition is reached. The whole idea of an exception should be to pass control of the program to a place that can handle the error condition.
If you are using exceptions in lieu proper bounds checking or verifying the return value of a method or API call, then, in reality, exceptions are just a high-tech way of implementing a GOTO which can leave your system in an undefined state. These are generalizations and "exception-neutral programming" outlines acceptable techniques for the best use of exceptions (See Exceptional C++, Herb Sutter).
|
|
|
|
|
thanks friends. i didn't know them.
there are always better ways that i offer  .
|
|
|
|
|
You can use a cyclic buffer by keeping a start index pointing to the first item in the array. When adding an item you just advance the start index to shift all items in the array.
You can wrap it in a generic class, something like this:
public class CyclicArray<T> {
private T[] _data;
private int _start;
public CyclicArray(int size){ _data = new T[size]; _start = -1;}
public int Length { get { return _data.Length; } }
public T this[int index] { get { return _data[(index + _start) % _data.Length]; } }
public void Add(T item) { _start++; this[-1] = item;}
}
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Why don't you use a generic list? When you add a new item, simply remove the 0th one.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Now that would not be very efficient! But it will work
|
|
|
|
|
leppie wrote: Now that would not be very efficient! But it will work
All the good answers were taken.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
HAHAHA
|
|
|
|
|
There is no need to rebuild an array each time.U do one thing u take stringbuilder class's object and use it. Which will allow you to take an array of any length.
Bhumika
|
|
|
|
|
Hi,
I'm during numerical calculations here. The array is comprised of doubles and not strings.
Regards,
Dave
|
|
|
|
|
hi friend i want to add windows service but this time i want to add it using C# code can any body have tell me how i can do that or there is no way to that
wasim khan
|
|
|
|
|
|
|
Hello everyone,
I have made tests, just want to confirm here since I am new to this method.
1.
HttpListener.BeginGetContext is never blocked?
2.
If we wait on the handle, like this, then the wait handle will be signalled immediately when we call EndGetContext, like this "listener.EndGetContext(result)"?
IAsyncResult result = listener.BeginGetContext(new AsyncCallback(ListenerCallback),listener);
result.AsyncWaitHandle.WaitOne();
thanks in advance,
George
|
|
|
|
|
George_George wrote: HttpListener.BeginGetContext is never blocked?
Methods starts with BeginXXX are considered to be assynchronous and won't block.
2 - I guess you won't be able to call EndGetContext() until the operation finishes as result.AsyncWaitHandle.WaitOne(); blocks.
|
|
|
|
|
Thanks ForumExpertOnLine,
I am confused why I can not call EndGetContext? I think I am free to call it at any time. I have posted my code here to clarify.
In my code, I pass a delegate as the 1st parameter for method BeginGetContext as callback when a client request is available, and in the callback, I call EndGetContext.
Could you clarify what do you mean "won't be able to call EndGetContext()" please?
http://www.codeproject.com/script/Forums/View.aspx?fid=1649&select=2582942&tid=2580144[^]
regards,
George
|
|
|
|
|
George_George wrote: why I can not call EndGetContext? I think I am free to call it at any time.
1 - It calls BeginGetContext() which immediatly returns with a IAsyncResult instance.
2 - You are calling WaitOne() on this, which will block the thread until it gets a signal. It gets a signal when the processing is over. That is why you are not able to call EndGetContext until it finishes the operation.
|
|
|
|
|
Thanks N a v a n e e t h!
"when the processing is over" -- what processing? You mean receiving an underlying client Http request from socket layer or the processing of the delegate as the first parameter I passed to BeginGetContext or something else?
regards,
George
|
|
|
|
|
George_George wrote: what processing?
Until BeginGetContext() finishes.
|
|
|
|
|
Thanks N a v a n e e t h,
1.
You mean if we provide a callback as the first parameter to BeginGetContext, then the asynchronous operation will be done at first, until it is completed, the callback is called and we are able to call EndGetContext, correct?
(I think it is a general description of how asynchronous call works in C#)
2.
What is the underlying work between we begin to call BeginGetContext and the callback is called?
regards,
George
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
