|
It depends on the compiler and the optimization options.
But in this simple case the generated code should be identical. You can check this by specifying a compiler option to generate assembly code (e.g. /Fas with Microsoft compilers) and compare the generated code.
|
|
|
|
|
I agree with you!
In general, two cases are identical!
|
|
|
|
|
You don't need to care; write readable code, the compiler will be more than sufficient to optimize it.
They will be compile to the same thing.
I'd rather be phishing!
|
|
|
|
|
I think the first one is faster.
because, the in second
- variable first ! converted
- the newly converted variable is converted to 1/0 for if statement
but in first-
-the == operator check bit wise datas of 2 numbers, if matched 1/if not 0.
so i think the first one is faster. Whats your view..
|
|
|
|
|
THERE IS NO DIFFERENCE.
For such simple code, the compiler will generate the same code.
compile and generate the assembly code for both versions, and you will see that the code is the same.
(testes with debug version on VS2012).
I'd rather be phishing!
|
|
|
|
|
shaktikanta wrote: I think the first one is faster.
The compiler need do nothing more than test for zero which the target CPU almost certainly has a single opcode for.
|
|
|
|
|
The second one is faster to type. 
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Entropy isn't what it used to.
|
|
|
|
|
With something this trivial, it doesn't matter. If you want to write fast code, there are a ton of other bottlenecks that are more important than this.
|
|
|
|
|
Statement 2 should be faster.
- no need to do parsing and comparison, just go to memory to negate, and see if it's above 0 or not.
- compiler can generate machine code that would take less clock circles to execute the if() statement
The speed differences between the 2 statements are negligible,
- but statement 1 reads better, easier to understand and for better documentation.
|
|
|
|
|
ptse wrote: Statement 2 should be faster.
They will both be the same; each being a machine code instruction that tests for zero.
|
|
|
|
|
Reposting as thread has grown
#include <<windows.h>> // remove extra angle bracket for compilation
#include <<tchar.h>>
#include <<stdio.h>>
#include <<strsafe.h>>
void FreeMemory(char** myArray, int row);
void FileCountInDir(const TCHAR* dirpath, int * filescount, int* filesize);
void FindFilesInDirectory(const TCHAR* dirpath, char** filelist);
int _tmain(int argc, TCHAR *argv[])
{
int i =0;
TCHAR szDirpath[MAX_PATH];
//TCHAR Filelist[100][MAX_PATH];
char ** Filelist;
int iFileCountInFolder=0;
int iFileSize = 0;
_tcscpy(szDirpath,_T("C:\\BMPread_W\\TransitionEffects\\Images"));
FileCountInDir(szDirpath,&iFileCountInFolder,&iFileSize);
Filelist = (char**)malloc(iFileCountInFolder * sizeof(char *));
if(Filelist == NULL)
{
fprintf(stderr, "out of memory\n");
return 0;
}
for(i = 0; i < iFileCountInFolder; i++)
{
Filelist[i] = (char*)malloc((iFileSize * sizeof(char))+1);
if(Filelist[i] == NULL)
{
fprintf(stderr, "out of memory\n");
return 0;
}
}
FindFilesInDirectory(szDirpath, Filelist);
for(i =0;i 0)|| ((*filesize) < _tcslen(ffd.cFileName)))
{
(*filesize) = _tcslen(ffd.cFileName);
}
}
}
while (FindNextFile(hFind, &ffd) != 0);
FindClose(hFind);
}
void FreeMemory(char** myArray, int row)
{
int i;
if(myArray != NULL)
{
for (i = 0; i < row; i++){
free (myArray[i]);
}
}
|
|
|
|
|
Please edit your question and put <pre> tags around it all, not just the last line; i.e the opening tag should be before the first line, and the closing tag after the last.
How does this even compile, since szDirpath is not declared in your code?
_tcscpy(szDirpath,_T("C:\\BMPread_W\\TransitionEffects\\Images"));
FileCountInDir(szDirpath,&iFileCountInFolder,&iFileSize);
You could also simplify it to:
FileCountInDir(_T("C:\\BMPread_W\\TransitionEffects\\Images"), &iFileCountInFolder, &iFileSize);
As to the rest, it seems to be missing major portions of code so it's difficult to tell what is happening.
|
|
|
|
|
Have you stepped through the code and inspected the values of myArray and i? That might tell you why it's failing.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Okay that rubbish won't even compile
No compiler is going to let this line thru
for(i =0;i 0)|| ((*filesize) < _tcslen(ffd.cFileName)))
I am also suggesting that this line was also supposed to be that function defined but it has ";" rather than open brackets
FindFilesInDirectory(szDirpath, Filelist);
The other function is not provided anywhere
void FileCountInDir(const TCHAR* dirpath, int * filescount, int* filesize);
Can I suggest you give us some code that actually compiles if you want help
There is also some house cleaning you didn't release the pointer array in FreeMemory. To make you life easier can I suggest you make a CreateMemory function to add to your FreeMemory function here is what they look like
char** CreateMemory(int rows, int stringsize) {
int i;
char** p;
p = (char**) malloc (rows * sizeof (char*));
if(p != NULL){
for (i = 0; i < rows; i++){
p[i] = (char*) malloc(stringsize * sizeof(char));
}
};
return (p);
};
void FreeMemory(char** myArray, int row) {
int i;
if(myArray != NULL){
for (i = 0; i < row; i++){
free (myArray[i]);
}
};
free(myArray);
};
This is how you use them
char** q;
q = CreateMemory(10, 256);
strcpy(q[0], "row 1\0");
strcpy(q[9], "row 10\0");
FreeMemory(q, 10);
|
|
|
|
|
There was no need to repost. It could be spamming. I suggest you read the existing responses carefully before going any further. They may be from members who know something.
Peter Wasser
"The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts." - Bertrand Russell
|
|
|
|
|
I am trying to change the filter properties (Ezrgb24). I can read the property page – using IspecifyPropertyPages. I get all tabs of the property page, but getting “memory could not be written “error when I try to update it. I am working on that.
SOLVED
The filter .ax file was not being updated in System32 during debugging. Added to Post build proccess.
I have noticed when I access the property page using GrapEdit it is missing the first tab – only the input and output pins tabs are there. It is same on another DirectShow base filter.
I did not have this issue, I could read all tabs on unconnected Ezrgb24.
But I could not get the property page when the filter was connected in graph and running until I registered proppage.dll.
It sure looks as a problem with proppage.dll.(I'll look for a different version ).
Anybody have a knowledge about this issue?
I sure would like to know what is going on.
UNRESOLVED still cannot access Options sheet, only pin properties sheet. Since using GraphEdit for debugging only it does not effect application.
Thanks for reading.
Cheers
Vaclav
-- modified 25-Mar-14 22:15pm.
|
|
|
|
|
You need to post your property page initalisation code for us to be able to help you.
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Entropy isn't what it used to.
|
|
|
|
|
Thanks for reply.
I did not specify which issue I need help with. Sorry.
As I said, I'll figure out the update "problem".
I feel the property sheet dialog should do the update just fine.
But I am just curious why the difference between GraphEdit using "off the shelf" filters both Ezrgb24 and Color Conversion Filter.
I did some search and found some discussions to the effect that GraphEdit does some extra work when displaying property sheet.
I think I found my problem, but it will take some undooing to fix it.
For safety reasons I did make copies of both filters and compiled them.
For so far unknown reason the options tab page in property sheet is gone, only the pins pages
are there. I assume this page code is external to the filter code.
That is why it works when filters are added manually in GraphEdit - it uses the original source.
-- modified 25-Mar-14 15:22pm.
|
|
|
|
|
Can anyone help what is wrong in the following code snippet.
free (Filelist[i]); fails with access violation error.
Thanks in advance.
int _tmain(int argc, TCHAR *argv[])
{
int i =0;
char ** Filelist;
int iFileCountInFolder=0;
int iFileSize = 0;
_tcscpy(szDirpath,_T("C:\\BMPread_W\\TransitionEffects\\Images"));
FileCountInDir(szDirpath,&iFileCountInFolder,&iFileSize);
Filelist = (char**)malloc(iFileCountInFolder * sizeof(char *));
if(Filelist == NULL)
{
fprintf(stderr, "out of memory\n");
return;
}
for(i = 0; i < iFileCountInFolder; i++)
{
Filelist[i] = (char*)malloc((iFileSize * sizeof(char))+1);
if(Filelist[i] == NULL)
{
fprintf(stderr, "out of memory\n");
return;
}
}
FindFilesInDirectory(szDirpath, Filelist, &iFileCountInFolder);
if (Filelist != NULL) {
for ( i = 0; i < iFileCountInFolder ; i++)
free (Filelist[i]);
free (Filelist);
}
return 0;
}
modified 24-Mar-14 19:50pm.
|
|
|
|
|
First, put your code between <pre></pre> tags so that it's readable.
Second, the code you cite as causing the error is not even in the snippet you show. 
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
|
The mallocs and frees are fine in concept the issue is deeper
I suspect this is the problem
Filelist[i] = (char*)malloc((iFileSize * sizeof(char))+1);
iFileSize is initially set to zero and then passed in as a parameter to FileCountInDir which I guess is supposed to fill it in.
But I find it really strange because that function is counting the directory entries from it's function name.
Really the string space allocation should be the length of each individual directory entry name so I am not sure it should be a single value.
For example a file "fred.bmp" should allocate 9 bytes (8+asciiz 0) while "afred.bmp" should allocate 10 bytes (9+asciiz 0)
I fail to see how you are allocating them all as iFileSize unless that is the largest filename in the directory.
And that leads to the answer for your fail that iFilesize must be coming back from FileCountInDir as -1 and that means you are allocating -1+1 = 0 bytes of memory which will fail in malloc returning NULL.
Hence Filelist[i] would indeed be carrying NULL
You can put protection to stop the error by doing this
if (FileList[i] != 0) free (Filelist[i]);
But as discussed I think you have serious issues with iFileSize
|
|
|
|
|
I think you are on to it as the mallocs and frees seem OK. Unfortunately not enough information provided.
Peter Wasser
"The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts." - Bertrand Russell
|
|
|
|
|
malloc()-ing 0 bytes doesn't return NULL when I test.
This appears to be implementation dependent.
Peter Wasser
"The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts." - Bertrand Russell
|
|
|
|
|
If you are posting a lump of code a compile ready snippet helps everybody.
Peter Wasser
"The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts." - Bertrand Russell
modified 24-Mar-14 21:28pm.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
