|
You have pointers to structures AVPacket and AVFrame and got_output
You may have
1.) Changed the structures
2.) Changed the compiler settings for packing of structures. Making the structure not what the DLL expects
You sort of say get_output is an int but that isn't what the documentation says.
Finally you have a return error in ret .... what does it return? Things like invalid parameter will tell you more.
In vino veritas
|
|
|
|
|
im my textbook , i was told that you daclare an array as follows:
type var[size];
where size is constant and cannot be changed later.
but if i run this :
int a[2];
a[3]=10;
cout<<a[3]<<endl;
it does not give any error and prints:
10
how is this possible.. because the size of the array was 2!! ??
please help me understand.
|
|
|
|
|
Maybe take a look at this[^] thread, as they talk about out-of-bounds array indexing, it's undefined behaviour.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
C/C++ does not enforce arrays bounds checking. Your code invokes "Undefined behavior", which means what it sounds like - the C/C++ standards don't say what will/can happen. The compiler may do anything, including make demons fly out your nose! (see Undefined behavior - Wikipedia, the free encyclopedia[^]).
This is often the root of subtle, and often hard to find bugs.
|
|
|
|
|
|
I can recommend the link that jeron1 gave you. The top voted answer top the question is a very good explanation of what's happening behind the scenes.
|
|
|
|
|
It is possible because C and C++ do not check array boundaries, this behavior make them fast at cost of security.
In such a small program, you see no consequences, but bigger program, you will see another variable suddenly changing of value when it is not supposed to.
int a[2];
int b;
b= 0;
a[3]=10;
cout<<a[3]<<endl;
cout<<b<<endl;
In this example, b may end up with 10 depending on compiler details
Patrice
“Everything should be made as simple as possible, but no simpler.” Albert Einstein
|
|
|
|
|
Actually the behaviour has nothing to do with speed, its a legacy of dereferenced pointers in C
p[i] is EXACTLY the same as writing *(p+i), most novice programmers will recognize the first form but not the second. The two codes are literally identical and will almost always produce the same code. The second however makes it clear that applying bound checking as a generic behaviour would break all dereferenced pointers. Some C compilers recognize the first form as a special case and will do bound checking and give a warning, but even they will not detect a bound error if the second form is used because p+i is just a pointer with an offset. That may well be, and often is intended behaviour.
So array bounds has always been and will always remain the responsibility of the C programmer. A pointer can exist to a memory that is non existent, invalid or has been previously released anyhow, so the array bound situation is no more dangerous than any of those all of which are the C programmers responsibility.
In vino veritas
|
|
|
|
|
I hate C++  it 's so difficult
|
|
|
|
|
And an easy language would be?
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
C#! 
|
|
|
|
|
Of course! nothing bad happens when you go out of range on an array in C#! 
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Not sure if it's an agreement or not...
Let's say: no memory corruption occurs!
|
|
|
|
|
Hy,
i am using CFileStatus to get the date and time when the file was last modified.
By some files time is one hour earlier or later, but only by some files?
Does anybody have a clue why this happens?
cfile.GetStatus(m_filepaths[i], m_status);
Date=m_status.m_mtime.Format( "%d.%m.%Y %H:%M " );
|
|
|
|
|
I would guess "summertime".
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Do you have any idea how to fix this?
|
|
|
|
|
Not before you can confirm that it is broken; are the files that lack an hour created during the same period, or is it distributed randomly?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
I have a little bit check files. Files that where modified round in period betwen November and April have time one hour later.
|
|
|
|
|
The m_mtime.Format method returns a time formatted according to the local timezone, so it may well be one hour out. You should use one of the alternative methods (see CTime Class[^]) to get the absolute time.
|
|
|
|
|
This can occur when files are stored on FAT file systems. NTFS stores all dates in UTC while FAT uses local times. The local time from FAT file systems is converted when getting the time. But this will return wrong values when the time stamp has been written by a system that uses a different time zone than the one used to read the time stamp.
See also File Times (Windows)[^].
|
|
|
|
|
|
Hi, I just need instructions to build my working source code in C++ into a dll that is compatible with Windows 7.
Thanks.
|
|
|
|
|
|
Assuming that your code has no linux OS calls in it and is just generic stuff you just define an interface for it and compile it like Jochen's answer.
If you have linux OS calls you will need to build windows replacements or use a framework.
In vino veritas
modified 29-Jun-16 13:29pm.
|
|
|
|
|
Hi, I need your help a bit in C++.
I am coding a dll but my source code has 2 errors.
Both issues stem from the same declaration in my header file.
void execute_assert(bool expr, std::string str);
When I do the function calls...
v_assert(s = MAX_ACL_DEPTH, "MAX_ACL_DEPTH too small");
and
v_assert(s < 1, "Illegal acl size (" + deb + ")");
I get the error message...
Error: too many arguments to function ‘void execute_assert(bool, std::string)’
On both counts, the parameter count is ok, so what's the problem?
Please help.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
