C++

Post Reply New Topic

Really? Templates are, in my opinion, one of the big advantages of C++, because it saves you from a lot of pointer shenanigans, but then again, I'm a big fan of the STL. Operator overloading is one of those "really useful but only under special circumstances" features-it's possible to overload the comma so you can do all kinds of crazy stuff. But again, the real issues for C++ for beginners are "how do I get these confounded header files to work?" and "why is everyone telling me I should be afraid that there's no Garbage collection when I don't know what garbage collection is?"

It is, take note of offset 0x00 in this: http://en.wikipedia.org/wiki/Win32_Thre ... tion_Block

You can set it to point to a custom SEH frame which contains your handler function like this




Sorry if this is way off topic.

Last edited by Burzum on 08 May 2012, 5:46 pm, edited 1 time in total.

Haha, that is something that I did not know. Though why would you want to?

Job security?

If I had a custom ordered pair class and a custom 3d coordinate class, I could use the comma operator like this:

coordinate pointA = (pairB, numberC);

The fact that this is totally insane seems to deter people from actually doing it.

(Edit: the precedence of "=" is greater than ",", so you'd need to put the expression on the right in parentheses or it would be (pointA = pairB) , numberC.)

Thanks, that's interesting, but it's Intel specific. Still intriguing and is probably how MinGW/Cygwin throw a SIGSEGV.

Good lord, I thought I knew almost everything there was to know about ANSI C++. How did I miss this?

Thank you, even though nobody should ever do this in real life.

There are some non-platform-specific ways to do this on windows, though.

Microsoft's CRT actually has signal(), so you can use that to catch SIGSEV on windows. Not sure how it works under the hood, but now I might have to take a look under a disassembler. Only difference from linux to be aware of is that you have to reassign the signal handler after each time it is invoked (it's usually done as the first line in the handler itself).

The other option is to use the asynchronous exception handling model (not the default behavior on Microsoft's compiler, you need to use the \EHa switch), which lets you catch Access Violation exceptions (the windows exception that is raised when the x86 throws a general protection fault, or some other platform throws a similar interrupt like the MemManage fault on ARM) as regular C++ exceptions. With \EHa you could catch all SEH exceptions with a catch(...) but one usually would use _set_se_translator() to map a specific SEH exception to a C++ exception. The comes at a slight cost to executable size since the compiler can't optimize exception code as aggressively.

Microsoft's compiler also has the __try and __except extensions for structured exception handling, which can be used to catch hardware exceptions such as Access Violation even without \EHa. I think it actually works similarly to the code Burzum posted above.

Now that I think about it, Vectored Exception Handling (introduced in Windows XP), can be used to handle structured exceptions without a bunch of stack traversal. Like with signal(), you don't have access to local variables from the frame where the exception was thrown.

But pretty much nobody should be catching segfaults unless they are writing a debugger.

Thank you. This is all good stuff to know, and I tip my hat.

I have no problem with them. It's just that it's a pain trying to learn everything at once, and it is really confusing when it isn't explained well to you in the text you're trying to teach yourself with. When I was first learning and the first sample code I saw contained...

cout << x << " is the number\n";

I was mightily confused. Not that I had any problem seeing that it worked. I just don't like the whole "black box" approach where you're thrown a bunch of weird syntax that doesn't seem to have a logical rhyme or reason for being what it is. Then if you try to look up the meaning of "<<" you'll find the bitshift operator, which is of absolutely zero help .

I also didn't like how there was never any good explanation on the difference between actual arrays and typed pointers. Square brackets are used to access data at a specific offset in both cases so it's natural to assume there's no difference between pointers and arrays. Only you find out you were dead wrong when you try passing them in functions and can't figure out why you're getting errors.

Headers are also a lot less confusing when it's explained in detail exactly what the compiler does and the order in which it does it.

I agree. Master C first, then mess around with C++.

C++ is basically C with classes.

My recommendation is that when learning C++, you learn the procedural aspects of the language first, and then move into the Objected Oriented aspects(classes). Start out by writing programs that consist exclusively of a main() function, then learn how to create functions(prototypes).

Stroustrup does not agree.

Oh yeah? Please present your evidence.

C++11 - A Touch Of Class

http://channel9.msdn.com/Events/GoingNa ... pp11-Style

"When I come into a room, especially these virtual rooms on the web, I seem to be the only one who doesn't quite know what C++ is. Everybody has some kind of simple explanation that fits their view of it and you see a few of them there [there are keywords on the screen]. And the effects is like the blind men and the elephant. If you have only seen the tail of an elephant you know what it's like, if you've only seen a leg you know what it's like. I try to look at the whole elephant and I try to characterize it, but it's hard. There's many bits to the elephant, they're all essential to the elephant, but it's hard to be simple about what it is. [...] I tried to come up with a buzzword, but I'm not particularly good at it. Lightweight abstraction programming language is accurate, but it's probably not good marketing speech."

I have never experienced pointers, but I've heard about them, and have been told they're complete <expletives> to deal with. I briefly programmed in C++ to create a command line audio processing application. I seem to remember that it was a little annoying, but the maths wasn't too hard.

In my recent work with C# I have been able to easily create windows applications with no maths at all, and certainly no pointers. I found it much easier than C++. Is C# not suited to your needs? I'd be happy to help with C# if I could.

Pointers are so fundamental to C++ that it's hard for me to think of them as anything anymore, pain in the ass or otherwise.

Yes, cleaning up after yourself isn't quite as easy as relying on a garbage collector, but it yields smoother performance of the finished app.