Transferring from java to C++

[vaironl]

Hello Everyone,

I'm transferring from Java to c++, and I know that it sounds off-topic but I do come to ask some questions SFML related as well. I actually asked this same question, in some way, in another forum and got suggested to start with SFML rather than openGL or SDL.

I also got suggested to do console c++ programs. But let me explain more about my background and the situation.

I've been programming in Java for about 1.5 year. I actually started learning c++ but had to stop, because my IB Computer Science required Java. Lately I've gotten interested in video games and similar graphic applications. I understand I can do it in Java, and did so. But I want to try it in c++ for fun and to see performance differences.

Any advice that can be given on whether I should first make those "Beginner" applications.. relearn about using classes, and core topics in c++ (Which I will obviously have to do sooner or later)... or could I just jump straight into making graphic applications?

Thanks, for any advice.

[masskiller]

I'm transferring from Java to c++, and I know that it sounds off-topic but I do come to ask some questions SFML related as well. I actually asked this same question, in some way, in another forum and got suggested to start with SFML rather than openGL or SDL.

And you got a good suggestion, but an even better one would be to start learning only C++ first, I come from Java myself and the change is incredibly big, since you don't use destructors, pointers, references and no garbage collection means that you have to be careful with scopes of variables and what you send to heap memory.

Java is a higher level language than C++, which pretty much abstracts you from a lot of what goes on underneath and learning all that takes time. In my opinion it's too much to learn C++ while trying to learn SFML as well. Also note that SFML tutorials and most material require you to know your basic C++, so I'd suggest you take your time with a C++ book first and then once you have a handle of things you can use SFML without as many problems or doubts later.

Lately I've gotten interested in video games and similar graphic applications. I understand I can do it in Java, and did so. But I want to try it in c++ for fun and to see performance differences.

Performance will be better, don't doubt it, C++ is much faster than Java.

Any advice that can be given on whether I should first make those "Beginner" applications.. relearn about using classes, and core topics in c++ (Which I will obviously have to do sooner or later)... or could I just jump straight into making graphic applications?

As stated above, you better avoid it and learn C++ well before going into graphic applications.

http://en.wikipedia.org/wiki/Comparison_of_Java_and_C%2B%2B#Design_aims

Most of the examples there are reliable, I haven't read it all so I can't tell if there's anything that's not, but it seems like a good read to get into C++ from Java. Good luck.

[vaironl]

I'm transferring from Java to c++, and I know that it sounds off-topic but I do come to ask some questions SFML related as well. I actually asked this same question, in some way, in another forum and got suggested to start with SFML rather than openGL or SDL.

And you got a good suggestion, but an even better one would be to start learning only C++ first, I come from Java myself and the change is incredibly big, since you don't use destructors, pointers, references and no garbage collection means that you have to be careful with scopes of variables and what you send to heap memory.

Java is a higher level language than C++, which pretty much abstracts you from a lot of what goes on underneath and learning all that takes time. In my opinion it's too much to learn C++ while trying to learn SFML as well. Also note that SFML tutorials and most material require you to know your basic C++, so I'd suggest you take your time with a C++ book first and then once you have a handle of things you can use SFML without as many problems or doubts later.

Lately I've gotten interested in video games and similar graphic applications. I understand I can do it in Java, and did so. But I want to try it in c++ for fun and to see performance differences.

Performance will be better, don't doubt it, C++ is much faster than Java.

Any advice that can be given on whether I should first make those "Beginner" applications.. relearn about using classes, and core topics in c++ (Which I will obviously have to do sooner or later)... or could I just jump straight into making graphic applications?

As stated above, you better avoid it and learn C++ well before going into graphic applications.

http://en.wikipedia.org/wiki/Comparison_of_Java_and_C%2B%2B#Design_aims

Most of the examples there are reliable, I haven't read it all so I can't tell if there's anything that's not, but it seems like a good read to get into C++ from Java. Good luck.

As said in the post I asked this before and got very similar answers, but wanted to make sure I headed the right way.
I have a c++ book made by the creator of c++ himself I will learn as much as I can from it, thanks again for the advice.

[fallout]

vaironl, I hope you're not reading "The C++ Programming Language". That's a reference book by Bjarne. "Programming: Principles and Practice Using C++" is the better choice.

[Nexus]

Learning the C++ basics before delving into graphical applications is certainly a good idea. Even though both languages look similar at first glance, the programming paradigms and concepts are fundamentally different in C++ and Java.

And you got a good suggestion, but an even better one would be to start learning only C++ first, I come from Java myself and the change is incredibly big, since you don't use destructors, pointers, references and no garbage collection means that you have to be careful with scopes of variables and what you send to heap memory.

And one should especially learn what RAII is, as it will make memory and resource management a lot simpler. Using manual memory management with new and delete is mostly bad practice.

Java is a higher level language than C++, which pretty much abstracts you from a lot of what goes on underneath and learning all that takes time.

This is only partly true. While I agree that C++ contains still a lot of low-level mechanisms that one is supposed to be aware of, it also offers powerful abstraction mechanisms, more than Java (template, typedef, global functions, multiple inheritance for example). In Java, as a beginner you will reach your goals faster, but in C++, you have more possibilities, but also more responsibility.

[vaironl]

vaironl, I hope you're not reading "The C++ Programming Language". That's a reference book by Bjarne. "Programming: Principles and Practice Using C++" is the better choice.

Good for me I have "Programming: Principles and Practice Using C++"   

[masskiller]

vaironl, I hope you're not reading "The C++ Programming Language". That's a reference book by Bjarne. "Programming: Principles and Practice Using C++" is the better choice.

Good for me I have "Programming: Principles and Practice Using C++"   

The reason for this is because the book "The C++ Programming Language" is a good book if you know some C++ or at least C, if you don't then all you will do is get confused with it.

And one should especially learn what RAII is, as it will make memory and resource management a lot simpler. Using manual memory management with new and delete is mostly bad practice.

I forgot to cite RAII, thank you for pointing it out.

As a side note, if you get into RAII then try to learn normal pointer and memory management first, not for using them in a practical way (that's pretty much the reason why RAII is awesome), but to know how they work and what RAII does underneath.

[vaironl]

vaironl, I hope you're not reading "The C++ Programming Language". That's a reference book by Bjarne. "Programming: Principles and Practice Using C++" is the better choice.

Good for me I have "Programming: Principles and Practice Using C++"   

The reason for this is because the book "The C++ Programming Language" is a good book if you know some C++ or at least C, if you don't then all you will do is get confused with it.

And one should especially learn what RAII is, as it will make memory and resource management a lot simpler. Using manual memory management with new and delete is mostly bad practice.

I forgot to cite RAII, thank you for pointing it out.

As a side note, if you get into RAII then try to learn normal pointer and memory management first, not for using them in a practical way (that's pretty much the reason why RAII is awesome), but to know how they work and what RAII does underneath.

By the way I know is a stupid question, but what would be "The stuff" I'd have to learn?
Collection of data, memory management, classes, garbage collection, windowing system, polymorphism, inheritance?

I already want to get started , really bad .

[FRex]

Collection of data, memory management, classes, garbage collection, windowing system, polymorphism, inheritance?

Not sure what you mean by first, second and third - yes, but use smart pointers for your memory managment, 99% chances are that you won't implement better memory managment no matter how hard you try, last two too. But c++ doesn't contain built in garbage collector and windowing system(??)/gui of any kind.
Read these two FAQs from Bjarne Stroustrup(original designer and crator of c++), they're great and contain important information about macros, casts and (lack of) garbage:
http://www.stroustrup.com/bs_faq.html
http://www.stroustrup.com/bs_faq2.html

[vaironl]

Collection of data, memory management, classes, garbage collection, windowing system, polymorphism, inheritance?

Not sure what you mean by first, second and third - yes, but use smart pointers for your memory managment, 99% chances are that you won't implement better memory managment no matter how hard you try, last two too. But c++ doesn't contain built in garbage collector and windowing system(??)/gui of any kind.
Read these two FAQs from Bjarne Stroustrup(original designer and crator of c++), they're great and contain important information about macros, casts and (lack of) garbage:
http://www.stroustrup.com/bs_faq.html
http://www.stroustrup.com/bs_faq2.html

Sorry... I have a tendency to not explain myself very well.
By collection of data I mean vectors.
I thought I had to do memory management myself, which I guess in a way I do, but the other post and your own have answered this.
What I meant was that before I start learning something like SFML, should I learn how to use a windowing library (Pardon me if that is not the correct term)?
Garbage collection is something I seen in other post that must be done although I have no idea of how it works.

Thanks for the information!

[Nexus]

I thought I had to do memory management myself

That is a common misbelief about C++. People concluce from the non-availability of a GC that they would have to manage memory on their own. In fact this is only in rare cases necessary, thanks to the RAII idiom.

You should first learn how new and delete work and build a few data structures on your own, just for the understanding. Later, for productive code, try to avoid them and let your memory be managed automatically.

By collection of data I mean vectors

In C++, the STL (standard template library) with its containers, iterators and algorithms is the pendant to Java's collections. The design is quite different, the STL uses static polymophism with templates. There is no inheritance or dynamic polymorphism with virtual functions.

[masskiller]

What I meant was that before I start learning something like SFML, should I learn how to use a windowing library (Pardon me if that is not the correct term)?
Garbage collection is something I seen in other post that must be done although I have no idea of how it works.

Garbage collection in C++ doesn't exist, instead there's RAII, which is a sort of garbage collection (works kind like it, but it certainly is not), but much faster and depending on the usage of C++ 11 (current approach) or an external library (boost, as it was done before C++ 11). C++ 11 is the new standard btw, as it's new you may not find as much of it as common C++ in the web, so learn the older standard first and then learn what's new in C++ 11.

There's no real need to learn to use a GUI (AKA windowing library) to know SFML, but it is something good to know. I'd suggest you start with console applications, mainly by the use of simple logic and lots of std::cout to get into the language. C++ unlike java hasn't a native GUI library.

The list of what to learn is HUGE, there's classes, destructors, memory management (very linked to destructors, pointers and references), templates, operators (you can program your own), c++ style inheritance and polymorphism (multiple inheritance as a posibility, the concept of a vtable if you will), preprocessor, structs, unions , enums. Even the use of const (java's final) and unsigned types, as the former doesn't work well in java and the latter ones don't even exist.

The way c++ compiles is via two files and not just one, a header (.h/.hpp) and a source file (.cpp). You declare everything in the header and you implement it in the source file. This difference can cause a huge confusion if seen from a bad angle. And most of my pain in starting with C++ was to get used to that notation.

Strings not being a primitive type can be quite a shock as well, since the native strings in C/C++ are char*.
To use strings in a friendly way there's std::string.

Note that that was the summarized list and there's much more to add.

Try to learn from scratch, you surely know OOP and many more things, but to get used to the language there's no choice but that, mainly because you need to handle many things that you don't control in java, in exchange you get better performances.

By collection of data I mean vectors.
I thought I had to do memory management myself, which I guess in a way I do, but the other post and your own have answered this.

Yes and no, while it's good to know how a std::array or std::vector work inside, you can perfectly use them without knowing what they are beneath. However it's highly recommended that you implement your own structures first.

Just as a side note: the out of bounds error is non-existent in c++ and if you are not careful you may end up with a SIGSEV error in run-time (doesn't exist in java I think).

Check this: http://www.cplusplus.com/reference/stl/

It will be your best friend for long time.

And well, there isn't an exact guide of what to learn first, just a whole bunch of things to learn.

[FRex]

This may not be accurate, sorry if it isn't.

The way c++ compiles is via two files and not just one, a header (.h/.hpp) and a source file (.cpp). You declare everything in the header and you implement it in the source file. This difference can cause a huge confusion if seen from a bad angle.

That IS even more confusing.
c++ doesn't compile headers, compilers turn source files(.cpp, .c, .cxx, .c++, .cc) into .o that will get linked into final executable, headers(.h,.hpp) are more of a way to tell certain part of program: don't worry, somwhere in the final exe you'll be able to call function with this name. Also names in c++ are mangled, that's what extern C is for if you link to something compiled as C, to disable mangling, so the .o in final executable will not try to call a c++ function that doesn't exist but instead call the existing C function, so that adds some confusion to the mix.
What IDE does is call compiler to compile changed source files, by changed it means : those whose contents changed or contents of one of their includes changed(since include is just glorified copy paste) and then call linker to link the .o files, shared libraries and static libraries into final executable.
Dirty example of steps and how they are not tied to each other:
g++ -c *.cpp
will take all the .cpps in current directory and compile them into .os, this doesn't get you anything you can use yet
g++ -o FinalName *.o -lsfml-graphics -lsfml-window -lsfml-audio -lsfml-system
will link all the .os into final file named, FinalName and linked to graphics, window, audio and system of SFML.

[Nexus]

c++ doesn't compile headers, [...] headers(.h,.hpp) are more of a way to tell certain part of program: don't worry, somwhere in the final exe you'll be able to call function with this name.

That's quite vague. The code of header files actually is compiled, otherwise inline functions could not be executed.

Headers are nothing special. Every #include directive is replaced with the content of the file being included, thus after the preprocessor pass we have multiple, big .cpp files which also contain the code of the headers. Every .cpp file is compiled on its own (which implies that the header source code is compiled, too) to an object file, the linker then connects the object files. Things may be more complex when looking at techniques like LTCG, but this is the general principle.

[masskiller]

That IS even more confusing.

For anyone with knowledge of C++ my description was a vague useless babble, since if you have the knowledge you know that it's not enough, however if you come from another language those two lines can summarize it enough as to show that compilation is entirely different and that one should learn to handle those differences before anything else. That was my approach with what I wrote.

I do agree that my explanation wasn't actually accurate nor complete, but at least enough for someone who hasn't heard of it before at all to start with something, when a person has little or no knowledge telling them the whole process right up front may confuse them more than a small, nearly half-assed explanation will, and as they learn they will clarify what was left unsaid on their own, whereas the big explanation may leave a bad mental mangle. Learning takes it's time.