Irrational fear of C++

I have an irrational fear of C++. More than once have I swayed away from useful libraries because all they offered was a C++ API. I have perused several books on C++, but they have done nothing but strengthened the feeling that C++ is too complex to reasonably handle. What to do?

Read SICP.

>>2
Thank you for your effort, but I've already read SICP.

The fear of C++ is perfectly rational

>>4
Pretty much this.

>>1
More than once have I swayed away from useful libraries because all they offered was a C++ API.

and you acted right these fucking nigger could have offered a nice and clean C interface, but no it has to be C++.

man i hate such assholes.

>>6
What's the matter? Too powerful for you?

>>7
AAAAHAHAHAHAHAHAAHAHAHAHAHAHAHAHAHAHAHAAHAHAHAHAHAHAHAAHAHAHAHAHAHAHAHAHAHAHAAHAHAHAHAHAHAHAAHAHAHAHAHAHAHAHAHAHAHAAHAHAHAHAHAHAHAAHAHAHAHAHAHAHAHAHAHAHAAHAHAHAHAHAHAHAAHAHAHAHAHAHAHAHAHAHAHAAHAHAHAHAHAHAHAAHAHAHAHAHAHAHAHAHAHAHAAHAHAHAHAHAHAHAAHAHAHAHAHAHAHAHAHAHAHAAHAHAHAHAHAHAHAAHAHAHAHAHAHAHAHAHAHAHAAHAHAHAHAHAHAHAAHAHAHAHAHAHAHAHAHAHAHAAHA!

>>8
Don't break the horizontal hold.

I would hope you at least know C, which is reasonable given its intended use.

I only know a subset of C++ -- I'm barely familiar with the standard API (I am a Qt faggot), and I don't know how magical automagic pointers work.  I plan to learn C++ properly some day, but right now I just need it to get a particular job done.

>>10
I know C very well, it's C++ I have a problem with. Now that you mention it, Qt is one of the things that makes me feel like I should know something about C++.

You shouldn't be afraid of C++: it can't hurt you, even though it wants to. You just need to realize these three things.

1. You can get work done in any language, no matter how laughably bad it is.

2. You don't need to be an expert on C++ to do that. You just need to know it well enough that you aren't basically writing C. Most programs won't require template magic (which isn't really all that tricky in the simple case), and some of its "features" like operator overloading are best ignored completely and were just included to throw you off the trail (busy work).

3. You're just as capable of writing decent code, by C++ standards, as the next guy, modulo practice. Nobody gets off easy with C++. You'll perform up to standards.

It might help you to call it Sepples, too.

>>12
2. You don't need to be an expert on C++ to do that. You just need to know it well enough that you aren't basically writing C. Most programs won't require template magic (which isn't really all that tricky in the simple case), and some of its "features" like operator overloading are best ignored completely and were just included to throw you off the trail (busy work).
This is a lie. You need to know a shitload about C++, otherwise sooner or later you will get caught by a Gotcha!

Also, no, you can't just ignore the parts you don't like, because some C++ library will ALWAYS use it (STL alone uses 90% of the damn language).

The only part that isn't a lie is that you don't need to be an expert. That's true, because people actually do get work done in C++, even though it's not possible to be an expert at it.

>>13
So it's a lie, except it's true?

>>13
Buggy, memory-leaking, unoptimized, program-crashing work, sure.

>>10
and I don't know how magical automagic pointers work.  I plan to learn C++ properly some day
No time like the present! I'm feeling helpful today, so here's a hand crafted zero-overhead non-transferable scoped smart pointer, written thirty seconds ago, just for you anon. Paste this sucker into your void.h:

template <class T>
class scoped_ptr {
public:
  explicit scoped_ptr(T* t) : t(t) {}
  ~scoped_ptr() {delete t;}
  T* operator->() {return t;}
  T& operator*() {return *t;}
private:
  T* t;
  scoped_ptr(const scoped_ptr<T>& other);   // unimplemented; not allowed
  T& operator=(const scoped_ptr<T>& other); // unimplemented; not allowed
};

This is the basis of a smart pointer. It's just a container that you put a pointer into; when the container is destroyed, it deletes the pointer. The idea is that you stack-allocate or field-allocate the container, so it automatically frees the pointer when it goes out of scope. That way the object can't leak if an exception goes by, if you return in the middle of a function, etc.

However it overloads operator-> and operator*, so you can use it like a regular pointer. It also disallows copy and assignment, so it can't be transferred. So to use it, instead of Foo* foo(new Foo()), you write scoped_ptr<Foo> foo(new Foo()) (notice I've stack-allocated scoped_ptr, which internally has a foo pointer).

Here's some test code, try it out:

#include <cstdio>

struct tester {
  tester() {printf("constructor\n");}
  ~tester() {printf("destructor\n");}
  void hello() {printf("hello\n");}
  void world() {printf("world\n");}
};

int main(void) {
  scoped_ptr<tester> obj(new tester());
  obj->hello();
  (*obj).world();
}

More typically though, smart pointers are transferable in special ways. For example shared_ptr internally keeps a reference count, so it knows how many copies you have about and frees the object when the last shared_ptr is destroyed. There's overhead for this though. auto_ptr and unique_ptr are transferable, and only one of them holds the real reference (it moves instead of copies); this is how you return smart pointers from functions. These get very complicated in order to implicitly convert smart pointer types based on the inheritance tree of their contained pointer. And of course you need a special smart pointer for arrays, because you have to use delete[] instead of delete.

>>16

I have been enlightened by a sepples EXPERT

This tutorial is indeed superior to most anything else out there

>>16
*_*

>>16
So, when you overload operator*, what happens if you do *ptr1 * *ptr2, for example, assuming they're both scoped_ptr instances? Or *ptr * ptr, for example, even though it's probably rare that you would want to do that? How come that isn't a conflict? Would it fail as unimplemented in both cases?

>>19
in the second example, slight typo: assume the ptrs are two separate instances (like ptr1 and ptr2).

>>19
Because the signatures of those operations are different. One is a unary operator used on the object itself and one requires a right-hand side.

Overloading the multiplication operator: T operator *(const T &);
Overloading the unary dereference operator: T & operator *();

>>21
Probably should've returned a T & for the multiplication operator. Whatever, that's not the point of the example.

>>21
As you might notice from this example, it's entirely possible to overload operators with multiple operands. For example:

T & operator *(const T &);
T & operator *(int);
T & operator *(const U &);

This allows you to, for example, have a Product object that expresses multiplication. Then you can use primitive integers on it as though it was normal multiplication, as well as being able to use other Products. You wouldn't be able to achieve this effect any other way. You could also have an Exponent object, which would represent U and allow you to modify the Product accordingly.

This is what's meant by "exploit the intuitive properties of a class." The problem with this is that for any non-trivial function, it's rare that people agree on what the correct operator is. It's obvious enough for string and maybe vector, but after that, it gets a little hazy.

Actually, speaking of vector, that's a good way of expressing the operator overloading. You might want to add an element to a vector or you might want to add entire vectors:

vector<T> & operator +(const T &);
vector<T> & operator +(const vector<T> &);

If you do use operator overloading, be certain to document what the operators actually do, because what seems obvious to you might seem completely illogical to someone else: Like jumping off a building to learn how it feels to hit the ground.

EXPERT SEPPLES BAMP