|
Hey Superman_,
thanks for this.Now if i write
#include <dirent.h>
#include <stdio.h>
int main(void)
{
char array[1024];
DIR *d;
struct dirent *dir;
d=opendir("C:\\");
printf("Directories in C:\\ \n");
while((dir=readdir(d))!=NULL)
{
strcpy_s(array,dir->d_name);
}
closedir(d);
return(0);
}
will it works?actually at this time i can n't check the code.can you please help me?
|
|
|
|
|
ravi 12 wrote: will it works?
No, you are writing all your strings into one string, so you will keep only the last one. The problem you have is that you don't know upfront how many directories you will get, so you don't know how large you have to make your array. You could choose the brute force and use an array which is large enough (e.g. char array[1024][1024]: max 1024 directories of max 1024 characters). And then in your while loop you keep an index of where to store the current directory name (simply increment it each time).
Is it a C or C++ project ? Because if it is C++, I strongly suggest you to use stl containers (std::list for instance) and std::string, this will avoid to create an array with a fixed size upfront.
|
|
|
|
|
hey Cédric Moonen,
yes.it is C++ project.can you please give me the whole correct code ?
|
|
|
|
|
ravi 12 wrote: can you please give me the whole correct code ?
No because that wouldn't serve any purpose. Instead, I'll point you to some good articles about STL, you can check this section[^] on codeproject.
Of course, that will require some time to learn but it is definitively something that you will use a lot in the future, so the time investement will pay back later.
I suggest you document yourself about std::string and std::list, that's what you will need for this project. Don't forget that google is your friend and you can search for tutorials on the net.
|
|
|
|
|
thanks Cedric Moonen.....for your suggestion
|
|
|
|
|
Cedric Moonen wrote: Of course, that will require some time to learn
He seems to have lots of time considering he spent 11 days figuring out that he's unable to use FindFirstFile()/FindNextFile(). See his previous posts.
|
|
|
|
|
This has been painful to watch.  On the flip side, it has given me an idea for an article.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
unsigned long i;
short s;
signed char c;
i = (s<<15) + (c <<9);
How will type conversion take place in this case?
Is it that:
1. s will remain short(2 bytes) thus shifting the LSB into the MSB and remaining bits turn 0; c is promoted to short then left-shift 9 performed. The final R-value is promoted to unsigned long and saved into i.
or
2. s and c both get converted to unsigned long before performing the shift operation (thus we do not lose any of the left-shifted bits)
or something else happens.
I tried it in VS6.0 and the result seem to indicate that in both s and c I did not lose any bit upon left-shifting as if s and c acted as if they were a 4-byte data type (long or int)
|
|
|
|
|
All shifts take place in a register.
The registers are 32-bit in a 32-bit OS.
So even though the shift overflows the variable, it will still remain in the register.
That's the reason you don't loose any bits.
|
|
|
|
|
I understand that the shifts take place in registers but then the evaluated values have to be stored back into their respective variables, which are of type short and char, which cannot hold 4-byte values.
|
|
|
|
|
Ralph_2 wrote: but then the evaluated values have to be stored back into their respective variables
Nope. Why do you think that?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
If I have a char variable and I perform left-shift 4 times I lose the 4 MSB bits
For instance,
unsigned char c = 4;
c= c<<2;
c= c<<4;
So here 1 gets shifted outof the MSB
|
|
|
|
|
Do you mean to say that since these are R-values they themselves do not get modified.
Well, yes, my mistake. R-values will not be altered. My statement is incorrect. So now that we are talking at register-level then where and how does C's rules of type conversion come into picture?
|
|
|
|
|
Without talking about registers, types promotion occurs because of (in the original expression) the assignment was done to an integer.
[edit]
actually, running the following code
unsigned int u = 0xFFFFFFFF;
unsigned long long ul = (u << 8);
make me think the above expression cannot be true 
[/edit]
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
modified on Thursday, October 22, 2009 4:08 AM
|
|
|
|
|
In the book C-The Complete Reference by Herbert Schildt theree is an example
char ch;
int i;
float f
double d;
result=(ch/i)+(f*d)-(f+i)
Here it does not talk about the data type of the variable "result". In any case, the conversion here is as follows: First ch is converted to int since i is int, then ch/i is performed. The result of ch/i is then converted to double as f*d is double. The final value is a double.
Now if "result" is type float then the final value will be truncated to float and stored in "result", isnt it?
CPallini wrote: types promotion occurs because of (in the original expressio) the assignment was done to an integer.
As we see in the above example the variable to which the final value is assigned, its type matters only when we have solved the expression on the right side.
Please correct me if wrong anywhere.
The mentioned book also says:
"First, all char and short int values are automatically elevated to int"
This seems to be the reason why I don't lose the shifted out bits and also because I store the value back in an unsigned long
modified on Thursday, October 22, 2009 4:51 AM
|
|
|
|
|
Ralph_2 wrote: Now if "result" is type float then the final value will be truncated to float and stored in "result", isnt it?
Yes (and the compiler warns about).
Ralph_2 wrote: As we see in the above example the variable to which the final value is assigned, its type matters only when we have solved the expression on the right side.
Yes. As I added in my previous post, you're right and looks like registers matter...
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Ralph_2 wrote: "First, all char and short int values are automatically elevated to int"
Yes, and it is also explained here [^].
I didn't know int had such a special role.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Thanks for your assistance.
So the answer to my question is "Integral promotion"
Now, if only int were 2-bytes then I lose the left-shifted bits and will have a different result for unsigned long = (short<<15) + (char<<9).....Ahem, i hope this is right now 
|
|
|
|
|
This is the assembly output for the statement i = (s << 15) + (c << 9);
movsx eax, WORD PTR _s$[ebp]
shl eax, 15 ; 0000000fH
movsx ecx, BYTE PTR _c$[ebp]
shl ecx, 9
add eax, ecx
mov DWORD PTR _i$[ebp], eax
So as you can see nothing is stored back into any variable.
The two shifts happen in the eax and ecx registers.
It is then added together and the stored into the variable i, which is also 4 bytes in length.
|
|
|
|
|
please have look on the msdn [^]
Величие не Бога может быть недооценена.
|
|
|
|
|
It's little strange for me. I m using CInternetSession, CHttpConnection, CHttpFile classes to make an http request.
It works fine most of time and response comes with status code 200.
But few times response comes with status code -1 (a negative value)
When this happens then it continue to happen for some time so I get -1 for some time.
Can any one tell me when -1 comes, so that I can handle it accordingly.
|
|
|
|
|
Hi,
Negative 1 is not a valid HTTP response code. I would be willing to bet that SendRequest or OpenURL is failing beforehand.
Best Wishes,
-David Delaune
|
|
|
|
|
Thats why I am also surprised. I know, it is not a valid response. I will try to give more info when it will be available. I am currently digging that. This happens occasionally so it is hard to debug and detect.
|
|
|
|
|
Hi,
Did you solve this issue? I would suggest wrapping your CInternetSession code in a try/catch block.
<pre>try
{
}
catch (CInternetException* pEx)
{
switch(pEx->m_dwError)
{
case ERROR_INTERNET_TIMEOUT:
break;
case ERROR_INTERNET_NAME_NOT_RESOLVED:
break;
case ERROR_INTERNET_CANNOT_CONNECT:
break;
default:
break;
}
pEx->Delete();
}</pre><br />
<br />
<br />
Best Wishes,<br />
-David Delaune
|
|
|
|
|
Thanks Randor! I will sure do that. Currently I am not getting that -1.
My new problem is that my program(exe) in not able to connect to internet if it is inside a proxy. How can I deal with proxy?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
