|
MFC is (and was) only included with full Visual Studio versions.
So you have to install a full version (e.g. the free Community version) if you need MFC support.
|
|
|
|
|
Well MFC is Crucial to me,
How do I do that.
Thanks,
Bram van Kampen
|
|
|
|
|
|
MFC is included in Visual Studio 2015 community edition which is free.
MFC and ATL[^]
You can create MFC or ATL programs with Visual Studio Community Edition or higher. If you do not select these components when you first install Visual Studio, you will be prompted to install them the first time you attempt to create or open an MFC or ATL project.
The link to download VS2015 community is right there for free.
Visual Studio Community 2015 with Update 3 - Free
Downloads | Visual Studio[^]
In vino veritas
|
|
|
|
|
Well Guys
Got It!! Took me a While
Thanks!
Now I have to learn the Interface!
![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
Bram van Kampen
|
|
|
|
|
Hello there. I am trying to encode some audio to mp3 format using libavcodec. This small utility was working fine untill lately. Now it has started giving me this weird runtime access violation reading location exception. I am showing following code to give you an idea
int ret = avcodec_encode_audio2(mp3_codec_context, &pkt, frame, &got_output);
When I debugged...I can see that none of the specified arguments are NULL. So, how do I know what is wrong and where ? Thanks for any input.
|
|
|
|
|
Well,
Were the Working Dll's Upgraded recently. Because it worked in the past, but no longer now, that is a very distinct possibility.
Regards,
Bram.
Bram van Kampen
|
|
|
|
|
An access violation is not only thrown when a memory pointer is NULL. Often NULL pointers are even allowed as arguments.
In your case you have to check the members of the passed structures. See the documentation for the used function: FFmpeg: Encoding[^]. There is information about the structure members and links to the structure type descriptions. Note that you must not only check the buffer pointer members but also the size members and probably others. An access violation may for example occur when the size member indicates a size larger than the real buffer size.
The above link indicates also that the function is deprecated. If you have upgraded to a new FFmpeg version, consider to use replacement functions.
|
|
|
|
|
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[^]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
