|
|
looooooooooooooooooooooooooooool
Oh my god!!! Two questions come to my mind: How many times did you come and go from designer view to code view and vice versa? How many mouses did you wreck?
|
|
|
|
|
Check to see if the day defined by "year", "mon" and "day" is between dtStart and dtEnd:
if (year >= dtStart.Year && year <= dtEnd.Year &&
mon >= dtStart.Month && mon <= dtEnd.Month &&
day >= dtStart.Day && day <= dtEnd.Day)
{
ok = true;
}
else
{
ok = false;
}
He said, "Boy I'm just old and lonely,
But thank you for your concern,
Here's wishing you a Happy New Year."
I wished him one back in return.
|
|
|
|
|
Ah, a false false generator in disguise.
|
|
|
|
|
On a previous job, we had a small bug in a date validation routine... it was supposed to ensure that the date (year and month) was in the future. It checked the year, if it was greater than this year it returned true, if it was the same year it checked the month*. We encountered some data with a future year and a month of zero... 
* Further details omitted for brevity.
|
|
|
|
|
I have far too much legacy code that does not check for data being in a valid range. 
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
Hm. When setting dtStart to Dec 31, 2000 and dtEnd to Jan 1, 2100, there seems to be no date in this century which is ok. In case that there was nobody whom that guy wanted to date, that does not matter either.
|
|
|
|
|
An example of how the World SHOULD work...
|
|
|
|
|
At first glance I thought it was just an awkward way to do it, as in why not just create a date from the MDY, then compare. Then I saw the real problem...
|
|
|
|
|
same happened to me, I just couldn't see what was wrong
|
|
|
|
|
in order to fix the bugs, you could write:
ok=!(year<dtStart.Year||(year==dtStart.Year&&(month<dtStart.Month||(month==dtStart.Month&&day<dtStart.Day)))||
year>dtEnd.Year||(year==dtEnd.Year&&(month>dtEnd.Month||(month==dtEnd.Month&&day>dtEnd.Day))))
which still sits in the right forum.
|
|
|
|
|
Minor correction. Try:
ok=!(year<dtStart.Year||(year==dtStart.Year&&(month<dtStart.Month||(year==dtStart.Year&&month==dtStart.Month&&day<dtStart.Day)))||
year>dtEnd.Year||(year==dtEnd.Year&&(month>dtEnd.Month||(year==dtStart.Year&&month==dtEnd.Month&&day>dtEnd.Day))))
Else you'll end up with 'valid' dates that are well within the month/date bracket, but in the wrong year(s)!
hth 
|
|
|
|
|
I disagree.
|
|
|
|
|
Or (in no particular language):
long ymd = (year * 12 + month) * 31 + day
bool ok = ymd >= (dtStart.Year * 12 + dtStart.Month) * 31 + dtStart.Day
&& ymd <= (dtEnd.Year * 12 + dtEnd.Month) * 31 + dtEnd.Day
This is still in the right forum as it permits 31st Nov and 33rd Feb and 0th May, -9th day of the 17th month etc. without fixing them properly; but valid dates work.
An even more horrible way with similar failings, but much faster would be (using << as a shift left logical operator and | as a bitwise OR):
long ymd = year << 9 | month << 5 | day
bool ok = ymd >= (dtStart.Year << 9 | dtStart.Month << 5 | dtStart.Day)
&& ymd <= (dtEnd.Year << 9 | dtEnd.Month << 5 | dtEnd.Day)This assumes less than 32 days per month (2^5) and less than 16 months per year (2^4). The year << 9 bits are year * 32 * 16. So 33rd Feb and -9th day of the 17th month would be somewhat disasterous.
|
|
|
|
|
the shifting way is what I would actually do when DateTime were not available; with a little optimization:
int ymd = (((year<<4)+month)<<5)+day;
eyc.
IMO it is the cheapest mapping from dates to integers that supports chronological ordering. I do add parentheses, for readability if nothing else.
|
|
|
|
|
DateTime dt = new DateTime(year, month, day);
return (dt <= dtEnd & dt >= dtStart);
How about this one?
Enclosing it in try catch will cop with invalid dates too.
|
|
|
|
|
Sadly, I've written code like that.
Marc
|
|
|
|
|
Yes, but you only do it once, and then when you realize your blunder, you promise yourself to never go there again. Right? 
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
Jörgen Sigvardsson wrote: , you promise yourself to never go there again. Right?
Exactly. And generalizing the blunder, you realize how evil "if" statements actually are and carefully consider the use of them!
Marc
|
|
|
|
|
I stopped using branches years ago. It's my way or the highway!
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
Remembers me to some date comparisons I have done with plain C - long ago 
(but mine were at least correct )
I was very happy when I had to do it the first time with C# and found out I can do it like this:
DateTime dtPast = new DateTime(2009, 9, 9);
DateTime dtNow = new DateTime(2010, 10, 10);
DateTime dtFuture = new DateTime(2011, 11, 11);
bool bIsBetween = dtNow > dtPast && dtNow < dtFuture;
|
|
|
|
|
So I was looking at some code I wrote a few years back, when I was first learning objective-C. I found many places where I did something like this:
char buffer[100];
sprintf(buffer, "the value: %d", someValue);
NSString* string = [NSString stringWithCString:buffer];
of course, with more useful text and values. I think there may have even been some times when I malloc'd buffer rather than having it on the stack... for those who aren't familiar with obj-C, this could be more sanely/appropriately written as:
NSString* string = [NSString stringWithFormat:"the value: %d", someValue"];
|
|
|
|
|
I constantly observe the same type of constructions with the MFC CString, when the programer does not realize there is a .Format() function to do the same thing.
I also crack up at the use of strlen and its variants to detect if the string is empty. How about just chekcing the first array slot for a zero! Or maybe they weren't after any kind of performance after all...
|
|
|
|
|
I have known programmers who say that readability is more important than small performance gains. This doesn’t sound too bad until you realize that by “readable” they mean “using what they are familiar with” and not learning new, faster and better ways of doing things. Also the performance of their code is abysmal.
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
The real horror here is that you don't check for the possibility of buffer overrun.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
