循环遍历出 2个时间段所有时间 C#能提供思路或者是任意解决方案的也行,我感激不尽!如：Time1 =""Time2=""则取出所有time1与time2间的日期_百度作业帮
循环遍历出 2个时间段所有时间 C#能提供思路或者是任意解决方案的也行,我感激不尽!如：Time1 =""Time2=""则取出所有time1与time2间的日期
循环遍历出 2个时间段所有时间 C#能提供思路或者是任意解决方案的也行,我感激不尽!如：Time1 =""Time2=""则取出所有time1与time2间的日期
晕,如此简单,怎么都搞这么复杂,for 会用吗?for (DateTime dt = new DateTime(); dt < new DateTime(); dt=dt.AddDays(1)){Response.Write(dt.ToShortDateString());}不就一个循环而已嘛?
protected ArrayList ToFilter(DateTime StartTime, DateTime ENdTime)
ArrayList al = new ArrayList();
TimeSpan ts = ENdTime.Subtract(StartTime);
这个才是啊！你自己运行看试！using Susing System.Collections.Gusing System.Tnamespace ConsoleApplication6{
class Program
static void Main(strin...
你原始的Time1 =""指的是string吧?先把所有string倒进datetime里面去,然后比对就很简单了,直接支持的比对出来再toshortdatestring()09:10 提问
android中循环遍历几个EditText怎么取到动态遍历的ID或文本框的值
TableLayout tableLayout = new TableLayout(this);
for (i = 0; i & 5; i++) {
TableRow row1 = new TableRow(this);
tableLayout.addView(row1);
edit1.setWidth(300);
edit1.setHeight(50);
edit1.setPadding(3, 3, 3, 3);
row1.addView(txtView3);
其他相似问题
相关参考资料hash_map遍历导致无限循环问题解决
机器环境如下，在使用hash_map的时候，进行遍历的时候 迭代器pos 和 end() 函数比较时候出现死循环，通过gdb调试发现pos++在最后一个元素的时候，pos++出现问题。机器配置如下：最后附网上收集资料。
出现问题代码：
typedef __gnu_cxx::hash_map&std::string,& int, str_hash& StrHashK& // hash_key -& mon_ key_idtypedef __gnu_cxx::hash_map&std::string,& int, str_hash&::iterator StrHashIt;
class CStrHash{&& StrHashKey m_buf_to_}
int CStrHash::insert(BYTE *buf, int size){&&&& &　　// size must be & 32, ommit extra compare&&&& char&tmp[32];&&&& memcpy(tmp, buf, size);&&&& tmp[size] = '\0';&&&&&&&&& m_buf_to_key[tmp] = key_}
遍历函数：&&&&&&& for ( m_hash_it = m_buf_to_key.begin(); m_hash_it != m_buf_to_key.end(); ++m_hash_it )&&&&&&& {
&&&&&&&&&&&&&&&&&& 。。&&&&&&& }
出现了无线循环。
后来经过测试，如果简单的例子，使用
&str_hash[&efexdf&] = 11;&str_hash[&efed&] = 222;&str_hash[&ed45&] = 3333;
&for ( it = str_hash.begin(); it != str_hash.end(); it++ )&{&&printf(&%s -& %d\n&, it-&first, it-&second);&}显示正常。
问题出在我们传入的是char *指针，但是该指针已经在我们传入后临时丢失了，所以会导致出现错误。改正的方式是传入string类型，由于默认的hash_map没有提供默认的构造函数，所以我们要自己定一个，正确代码如下：
struct str_hash{&&&&&&& size_t operator()(const std::string& str) const&&&&&&& {&&&&&&&&&&&&&&& return& __gnu_cxx::__stl_hash_string(str.c_str());&&&&&&& }};
typedef __gnu_cxx::hash_map&std::string,& int, str_hash& StrHashK& // hash_key -& mon_ key_idtypedef __gnu_cxx::hash_map&std::string,& int, str_hash&::iterator StrHashIt;
int CHBufToKeyId::insert(BYTE *buf, int size, int key_id){&if ( size & MAX_SIZE_KEY - 1)&{&&return -1;&}
&memcpy(m_key_buf, buf, size);
&m_key_buf[size] = '\0';&& return (m_buf_to_key[std::string(m_key_buf)] = key_id);}
当遍历函数时候，也一切正常了。
[root@mos37 bin]# cat /proc/version Linux version 2.4.21-27.EL (bhcompile@bugs.) (gcc version 3.2.3
(Red Hat Linux 3.2.3-47)) #1 Wed Dec 1 22:08:15 EST 2004
[root@mos37 bin]# lsb_release LSB Version:&&& 1.3[root@mos37 bin]# lsb_release -aLSB Version:&&& 1.3Distributor ID: RedHatEnterpriseASDescription:&&& Red Hat Enterprise Linux AS release 3 (Taroon Update 4)Release:&&&&&&& 3Codename:&&&&&& TaroonUpdate4
http://gcc.gnu.org/ml/gcc-help/2005-05/msg00087.html
Re: g++ 4.0.0: hash_map hangs when compiled with -O3 on AMD64
From: &Paul C. Leopardi& &leopardi at bigpond dot net dot au&
To: gcc-help at gcc dot gnu dot org
Date: Sun, 8 May :50 +1000
Subject: Re: g++ 4.0.0: hash_map hangs when compiled with -O3 on AMD64
References: && &&
Reply-to: paul dot leopardi at unsw dot edu dot au
I've isolated the problem to some extent. See below.
Best regards, Paul Leopardi
On Wed, 4 May
am, Paul C. Leopardi wrote:
& I'm seeing the following behaviour with GluCat 0.1.8 on AMD64.
& ./configure --with-hash-map --enable-debug=no: compiled program hangs
& (this uses __gnu_cxx::hash_map and -O3)
& gdb on the compiled program: bt results in hundreds of stack frames.
& Looks like the stack has been corrupted.
& Also it looks like the hang or corruption happens when using iterators with
& hash_map. I've looked at the test suite and I don't see a test where
& iterators are used with hash_map.
I've now done extensive testing with the optimization options of g++ 4.0.0,
and see that the problem only happens when both of the following flags are
used: -fstrict-aliasing -finline-functions.
The -O2 flag implies -fstrict-aliasing and
the -O3 flag implies -fstrict-aliasing -finline-functions.
Since it seems that these flags are incompatible when used with GluCat and
__gnu_cxx::hash_map, I did some performance testing and found that the GluCat
gfft_test is faster with -O3 -fno-inline-functions than it is with
-O3 -fno-strict-aliasing.
In gdb, using GluCat gfft_test compiled with -O3, I do not get stack
corruption. I don't understand this. The test programs test02, test03 and
test04 do get stack corruption.
What I see instead with gfft_test is that in a for loop which compares an
iterator of type __gnu_cxx::hash_map::const_iterator with end(), the loop
runs forever.
It looks like for __gnu_cxx::hash_map::const_iterator, operator++ no longer
works correctly when both -fstrict-aliasing -finline-functions are used.
In particular, the following routine in hashtable.h looks like it is failing
to incement the const_iterator.
operator++()
const _Node* __old = _M_
_M_cur = _M_cur-&_M_
if (!_M_cur)
size_type __bucket = _M_ht-&_M_bkt_num(__old-&_M_val);
while (!_M_cur && ++__bucket & _M_ht-&_M_buckets.size())
_M_cur = _M_ht-&_M_buckets[__bucket];
I tried changing the routine to the following
operator++()
const _Node* __old = _M_
_M_cur = _M_cur-&_M_
if (!_M_cur)
for( size_type __bucket = _M_ht-&_M_bkt_num(__old-&_M_val) + 1;
!_M_cur && __bucket & _M_ht-&_M_buckets.size();
++__bucket)
_M_cur = _M_ht-&_M_buckets[__bucket];
In gdb it looks like the same error is happening, but it is now a little
easier to see what happens to __bucket. In my particular case, at the
initialization of the for loop, the expression
_M_ht-&_M_bkt_num(__old-&_M_val) should have the value 1, but when I examine
__bucket, I see that it has the value 1, not 2 as I expected.
Unfortunately, I still don't have a short test case. I tried adding a loop
with __gnu_cxx::hash_map::const_iterator to the libstdc++/14648 test program,
and failed to reproduce the problem.
Do I have enough info to file a bug report or do I still need to try to create
a short test case?
&&最后修改于
请各位遵纪守法并注意语言文明