OK first up, I am old knarly programmer who started with FORTRAN / COBOL then going to C and eventually C++. In particular I became pretty damned hot in C and assembly even if I say so my self. However when I come to C++ I simply don't really seem to "get it" I keep asking myself, but why would you want to do that? With the advent of the STL et al, the syntax just looks horrible now.

Now don't get me wrong I am not abusing C++ which I have seen can produce elegant solutions to problems with only a small amount of typing. Also, don't bother to reply with, "that becuase you're thick" I understand that I probably am, but does anyone else struggle with C++, and wonder why should you struggle with the actual language, when the problem you are trying to solve is bad enough without the subtelties and nuances of the actual language getting in the way. Just a thought, you may flame away, my skin is thick.

Personally, I hate C programming. I wouldn't do it unless there were no other jobs available and I was starving to death. What exactly are you trying to "get". Are you saying that you don't get object oriented design or you don't get the syntax of the language? C++ and C are completely different as far as I'm concerned so it wouldn't surprise me that someone with a lot of C experience wouldn't get C++ or vice versa. The number of added features in C++ is pretty overwhelming considering all of the new libraries that are provided, including the boost libraries. On the other hand, once you get used to having all of those tools you could say that switching to C programming from C++ would be equally overwhelming.

I used to be almost the same way -- opting for more C-ish solutions than the C++ alternatives, and ended up writing a sort of C/C++ mash.

I don't know what changed it for me, but one day it just "clicked" and all the reasons for choosing the OO/C++ approaches over the _{[what may seem to be more simple]} C solutions became clear. It does sort of take a different mindset, I suppose.

*shrug*

does anyone else struggle with C++, and wonder why should you struggle with the actual language, when the problem you are trying to solve is bad enough without the subtelties and nuances of the actual language getting in the way.

I can't say I have. You must really be thick. :-)

If you think C++'s syntax is horrible, you should take a look at the Wikipedia article on Objective-C. It's vomit-inducing.
Honestly, I don't see how the syntax used for the STL is that different from C.
Let's take std::vector, for instance:

What's so horrible about that? The only tokens used differently are the <> which are used to pass template parameters at compile time.

You could just write in C++ as though you were C (or almost) and gain access to some of the advantages, like the STL (you can't tell me you never wished C had a built-in map type), but I think if you really want to learn C++, you should approch it as though you never learnt C. Even though C++ has very strong ties to C, it's still a different language.
However, I'd suggest you postpone learning more about the language until sometime next year, when the new standard comes out.

Disch: The exact same thing happened to me a month or so ago. My rite of passage was migrating all the C strings in a complete program to std::wstring. The program was an interpreter, so you can imagine the scope of the task.

The thing with C++ is that the STL combined with the boost libraries make the problems you're trying to solve easier. Whereas in C land programmers have to worry about the details of memory management and even the algorithms when implementing a linked list, std::list<> frees me from all the details.

It's not about learning it, I've used C++ since before it was an ANSI standard and before the STL was invented. I just don't really "get it". Don't worry, this is no attempt to bring C++ down, I fully understand it's me. I don't expect any of you to suddenly go "OMG he's right it's all been rubbish all along, the king has no clothes!!" I just wondered if anyone else had severe difficulties adjusting to C++ that's all, no malice intended.

built in map types, yeah, ok, would have been nice, used to write them in C ! Balanced binary trees, red black trees, double extensible hashes, linked lists, double linked lists lovely stuff!!

Myes. STL makes fast programming.

But I don't like it because it does a whole lot of unnecessary stuff to get there - it's not problem specific (don't get me wrong I do use map and vector allot, specially for bigger types of data, but you wont see me using std::string ).

Knowing myself I wont program pure C++ until I get more knowledge 'bout the subject, specially the overhead...Every time I try to use the fast programming I simply end up writing my own containers or something like that, I guess I need to know what happens under the hood, and I didn't take the time to fully find that out jet.

You might assure me that the compiler does a gr8 job and there isn't much difference, but my mind just cant get it-.- that is why I cant solve a simple problem w/out writing a custom lib.

I have another theory - I might want to learn about stuff and this will stop when I do. Fuck I hope so.


a shitload of selftalk. I R sorry, promise I wont do it again for a week

meh out

Oh, well a good day today perhaps, got a job managing a large team of c++ dev, maybe I can forget about it all now, and let the faster smarter guys take over, it would frankly be a relief.

Managing coders is a lot harder than coding. Way more bugs to deal with.

simulator;)...

It's (what used to be called) the paradigm shift.

If you're still writing procedural code, the OO facilities seem unhelpful, but once you start implementing OO designs, the OO facilities do kick in and become invaluable.

But it helps with data abstraction too. The class can be used as a black box with a hidden implementation and public interface, and be just as fast as C, but will compile time support for information hiding.

And then there's generic programming. By almost sheer fluke, the template mechanism in C++ turns out to be extremely flexible, enabling libraries to be very generic with template meta-programing.

Even with plain old procedural programming, C++'s declare variables beside use approach, reference types, and so on can make it a little nicer. After all function prototypes, void* in C come from C++.

and that's the rub because I cannot abide using a black box and not knowing what's going on. I hate hidden implementations with public interfaces. I'd love to know what the phrase "template meta-programing." means.

"After all function prototypes, void* in C come from C++." eh ?
|

and that's the rub because I cannot abide using a black box and not knowing what's going on

The reason why the implementation is hidden is because it allows it to be flexible. If outside source needs to know what the code is doing, then it can only use 1 kind of object. On the other hand, if the interface is abstracted, the same code can be used with an infinite number of objects, as long as those objects share a common interface.

As an example, I'm working on a library which abstracts pretty much everything. One of the simpler examples is a HashBase class I made, which simply has a "Hash" pure virtual functions. Derived from this class would be classes which do things like MD5, CRC32, etc. Because the interface is abstracted, and the internal workings hidden, outside code can simply call myhash->Hash(foo,bar); and the appropriate calculations can be performed. The code need not know what calculations it's actually doing.

Another example would be to abstract something like a File or Stream (which is sort of already done in C++ and even in C's stdio). Code can read from a source without needing to know exactly where the data is coming from. Is it a file on the disk? Is it user input? Is it from a block of memory? Is it from a chunk of compressed data that's being decompressed on the fly? It doesn't matter -- if the interface is abstracted, the code for all is the same.


Another more complciated example of something I'm working on is an abstracted FileSystem class, with things like CreateDirectory, OpenFile, etc, etc. Benefits to making this abstracted are twofold:

1) Platform specific methods can be isolated (ie: the FileSystem class can be rewritten for multiple platforms, but code elsewhere in the program doesn't care what platform it's on because FileSystem has the same interface regardless)

2) More complex things can be abstracted as a simple file system... like say... a .zip file or some other kind of archive. Code can open and modify files, create directories and whatnot with a FileSystem pointer, totally oblivious to the fact that it's actually modifying a .zip file.


It just makes it so much easier to separate what you're doing from how you're doing it. Because the what never changes, but the how can change greatly depending on the circumstances. This is why OO and abstraction are so important/useful.

Also ... if you are manipulating "protected" data members directly relying on the fact that you know how the underlying implementation works - what happens if the implementation needs to change (new feature added or somesuch). All of that code now falls apart and you have to redo everything.

The advantage of using language support to enforce information hiding (rather than relying on programmer etiquette) is to constrain how the implementation is accessed. Once you constrain access to a defined set of methods, you can test it to death and be sure that it won’t break while using the public interface.

We do it all the time. A C string’s implementation is bare, it’s a zero terminated contiguous block of chars. There are methods for handling them, but you’re always exposed to the implementation, which is good because you can add your own parsing an so on when necessary, but bad because you need to get involved with the implementation in your code in certain boundary conditions. For example, you need to know that strncpy and snprintf can fill a buffer without writing the null terminator. Ok, we’ll chalk that up to experience.

How about another one, FILE*. How many times do we look at the implementation of FILE? Almost never, in fact in C we learn NOT to look into system header files least you do start using the implementation. In these cases where the implementation is non-trivial, you don’t want programmers poking around in the implementation.

Classes offer guaranteed initialisation and deinitialisation in the language. Don’t tell me that as a C programmer you’ve never wanted this.

You don’t have to go for inheritance, just because you use a class. C++ classes are just as efficient in space and time as C functions managing the implementation of an abstract data type. That was the first hurdle C with Classes faces, no less efficient than C.

And yes, void* and function prototypes came from C with Classes.

And yes, void* [...] came from C with Classes.

I can't confirm whether this is true or not. Wikipedia states that pre-ANSI C used char * as a generic pointer, and since C++ appeared before C89, it's not impossible that C++ introduced void * originally.
What's your source?

I can't remember the source, but when I started using C, it was all K&R (no prototypes, no void*, old parameter lists ...). I remember when ANSI C was introduced and I remember reading somewhere about C++'s influence on C. These features were not simultaneously introduced into C and C++ at the same time.

Here's another reference to C adopting prototypes from C++. But's not my source.
ANSI C borrowed prototyping from C++, but the two languages do have some differences. The most important is that ANSI C, to preserve compatibility with Classic C, made prototyping optional, whereas C++ makes prototyping mandatory.
C++ Primer Plus, Stephen Prata

http://books.google.co.uk/books?id=zuyAIZ9ZIskC&pg=PA249&lpg=PA249&dq=ANSI+C+protoypes+C%2B%2B&source=bl&ots=mbu1R2s0H_&sig=IxAwMbx1DtC7XA6U9OawWsyiu8s&hl=en&ei=n-dRSr62EYasjAe-9pTGBQ&sa=X&oi=book_result&ct=result&resnum=8

but C++ doesn't make prototyping mandatory?

It does, it's an error to call a function that hasn't previously been declared. You declare a function by presenting the prototype.

In K&R C, it will assume defaults: returns int and takes a variable number of parameters. That is, it'll do the call and assume you've used it correctly.

Ah okay. I misunderstood.