C / C++ / MFC

3-Jul-16 14:15

The Free Compiler package offered by Microsoft, appears not to include MFC. Any ideas as to get access to MFC.

Regards,

Bram

Bram van Kampen

Daniel Pfeffer3-Jul-16 20:50

Daniel Pfeffer

3-Jul-16 20:50

Google is your friend: MFC MBCS DLL Add-on[^]

If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.

--Winston Churchill

Bram van Kampen4-Jul-16 14:19

4-Jul-16 14:19

Thanks,

It only suggests what I should have done at Install Time!

Tried again

a five hour re- install did not offer this option!

Bram van Kampen

Jochen Arndt3-Jul-16 21:12

Jochen Arndt

3-Jul-16 21:12

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.

Bram van Kampen4-Jul-16 13:59

4-Jul-16 13:59

Well MFC is Crucial to me,

How do I do that.

Thanks,

Smile | :)

Bram van Kampen

Jochen Arndt4-Jul-16 21:34

Jochen Arndt

4-Jul-16 21:34

To get the free Visual Studio Community visit Free Developer Offers | Visual Studio[^]. See also Leon's post below.

leon de boer4-Jul-16 20:55

leon de boer

4-Jul-16 20:55

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

Bram van Kampen10-Jul-16 16:49

How to handle runtime access violation exception

10-Jul-16 16:49

Well Guys

Got It!! Took me a While

Thanks!
Now I have to learn the Interface!

Rose | [Rose]

Bram van Kampen

Django_Untaken3-Jul-16 11:18

Django_Untaken

3-Jul-16 11:18

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);

// WHERE
// typeof(mp3_codec_context) = AVCodecContext
// typeof(pkt) = AVPacket
// typeof(frame) = AVFrame
// typeof(got_output) = int

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.

Re: How to handle runtime access violation exception

Bram van Kampen3-Jul-16 14:32

Re: How to handle runtime access violation exception

3-Jul-16 14:32

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

Jochen Arndt3-Jul-16 21:29

Jochen Arndt

3-Jul-16 21:29

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.

Re: How to handle runtime access violation exception

leon de boer4-Jul-16 20:46

leon de boer

4-Jul-16 20:46

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

Problem with C++ arrays.

Ratul Thakur30-Jun-16 3:15

Ratul Thakur

30-Jun-16 3:15

im my textbook , i was told that you daclare an array as follows:

C++

type var[size];

where size is constant and cannot be changed later.
but if i run this :

C++

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.

jeron130-Jun-16 4:17

jeron1

30-Jun-16 4:17

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

k505430-Jun-16 4:29

k5054

30-Jun-16 4:29

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.

Ratul Thakur30-Jun-16 5:47

Ratul Thakur

30-Jun-16 5:47

okay thanks

k505430-Jun-16 6:06

k5054

30-Jun-16 6:06

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.

Patrice T2-Jul-16 13:14

Patrice T

2-Jul-16 13:14

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.

C++

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

leon de boer2-Jul-16 22:31

leon de boer

2-Jul-16 22:31

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