|
Hello TL,
As a long-time Java programmer, both professionally and as a past time, I figured I ought to finally break down and learn C/C++. Boy, it seems inefficient! It seems like you have to write so much code to do object oriented stuff than in java. Really? Every time I make a new class I need a .cpp file AND a .h file? Really? every time I add a new method, I have to also add its def to the .h? Bizarre.
Then I noticed, all these tutorials mention as a side note, that you can directly implement stuff in the .h file. Well, fuck. Why not just implement the whole class in there? If I want to make something like a (java) abstract class or a (java) interface, I'll do that separately, but if I can build a concrete class in a single file, why not?
What am I missing here?
Also, what editor do you guys use for C++? As an old java salt, I immediately set up Eclipse with c++, but it is... lackluster. The quick fix suggestions are non existent, and I'd like to think that any good editor should just build the .h file for you.
Also, after writing this, I realized, that it may fall in the category of "TL is not yahoo answers." if so, apologies are in order.
( I very nearly gave up on c++ syntax when I shifted cout "hello world" bits to the left... that looks so wrong)
 
|
The idea is to separate the declarations from their implementation. Your header file (.h) will be included in every file that uses or references your classes. On the other hand, the implementation (.cpp file) should only be compiled once.
So, to answer your question:
- You need to put declarations in the .h file, so that other .cpp files besides the main one can reference those classes and functions.
- You can't just implement functions in the .h file, because if that file gets included in two different .cpp files (for instance) your build will fail when the linker notices that the same function is defined in two places.
|
|
|
On December 05 2011 03:24 tarpman wrote:
- You can't just implement functions in the .h file, because if that file gets included in two different .cpp files (for instance) your build will fail when the linker notices that the same function is defined in two places.
Worth pointing out that you should avoid this anyway, because this will happen to anything, not just a function (I believe).
You avoid this by having this wrapping around the contents of your .h file:
#ifndef myfileH
#define myfileH
... header contents ...
#endif
This means that if you include the same header twice (over a variety of headers that all include each other in complex ways, for example), the first time it reads during precompilation (when it deals with includes, defines, etc) it it'll create a define called "myfileH", and then the next time it comes across the file, it will fail the "ifndef" (if not defined) rule and skip out the header entirely.
It's bad coding practice to have big headers. In big projects, you really want to cut down on how much goes in to your headers. Headers may be compiled several times (i think) over different files in your project, but a .cpp will only be compiled once, so the smaller they are, the better.
For example, you can use forward declarations to help. Say you have a header that looks like the following:
class A
{
void blah(B* input);
}
Rather than including b.h, you can write
class B;
class A
{
void blah(B* input);
}
and then in the .cpp have the include "b.h" there. It'll just keep a record that it's expecting a B, but wont worry about what B actually is until it needs to.
Also look up the ideas behind PIMPL, which basically involve putting all private methods inside a struct in the cpp, so the only things in the header files are public method declarations
|
If you are on Windows, use Visual Studio. Pretty much the best C++ IDE available right now. If you're a student, try to get it for free via MSDNA.
For Linux I haven't found anything better than Eclipse yet, but it's definitely not as good as VStudio.
|
The best way to explain this is this:
Imagine being in a big project with classes that have tons of functions. Now imagine that, in the middle of development, there's no full documentation yet.
Now you want to know how a class works, names and declarations etc.
By seperating Definition from Declaration, you could just look into the header and immidiately know whats going on. Now imagine you have a header file that is 2000 lines long. Have fun reading that!
It is just for organizing code and have a better workflow. You don't have to do that, but it is highly recommended to do so.
|
c++ is a total joke for OOP. annoying header files, include loops, and the necessity to overload the copy constructor in many situations and other c++ BS (e.g. manual memory management) has made me switch entirely to java/scala. The java compiler/JVM has come a long way so that compiled c++ isn't really that much more efficient than bytecode anymore, so there's little reason to continue using this language.
|
Header files are not intended to make your life better or worse. They are part of a convention around a necessary aspect of C. The file extensions do not mean anything unless your compiler/preprocessor expects extensions. A header file versus a source file is just a separation of form from functionality. You could put your declarations in a c file if it's convenient. You can write definitions inside of a header file, but this is discouraged because headers are expected to be idempotent with respect to the load order. So if you reload a header file and don't use #ifdef or similar preprocessing to check that it has already been loaded, then the compiler will yell at you for trying to redeclare something.
Declarations (function, struct, class, or otherwise) are not intended to be a "sneak peak" at what the definition will later implement. They are intended for code that does not have access to the definitions at compile time (but before linking) to properly read from the stack (C is one abstraction level above assembly, but there are deep concepts at work). A function declaration essentially tells the compiled code the size of the arguments on the function stack so it knows what byte offsets to use from the stack pointer, a struct describes the byte offsets to use inside an object reference, and a class is similar.
This makes a lot of sense when your code dynamically links against other modules, since you won't even know what the code definition is until runtime. You can put definitions in your headers, but it takes away your ability to define it dynamically.
Don't think of this as a flaw in C that other languages "fix." Many languages do not expose memory like this, so it's a different programming paradigm completely.
If you're a noobie that's writing C/C++, just stick to the conventions for now. You will appreciate them later on when you have to link against other people's code or are running in unfamiliar runtime environments. It feels arbitrary, but the solution is not to pick up a higher-level language that shields you from memory manipulation unless you didn't need this kind of power in the first place. You can write VMs in Java, but how do you write the JVM?
|
As spines said visual studio is your best bet. And you are correct in that object oriented programming is very inefficient in c/++ compared to java. As other people already stated the header is to separate the implementation from the declaration. Once you get used to the extra typing you wont mind it too much. If you write everything in the header it will declare the functions multiple times if you end up using the header multiple times, and give you an error. Your compiler will hate you if you start making nestled classes and you only use a header file.
|
On December 05 2011 05:58 AcrossFiveJulys wrote:
c++ is a total joke for OOP. annoying header files, include loops, and the necessity to overload the copy constructor in many situations and other c++ BS (e.g. manual memory management) has made me switch entirely to java/scala. The java compiler/JVM has come a long way so that compiled c++ isn't really that much more efficient than bytecode anymore, so there's little reason to continue using this language.
Your prejudice is shortsighted. Many languages (Python, Haskell, others) fall back to C/C++ code to get performance. You have an abstraction barrier separating grammar & syntax from what is ultimately machine code any way you look at it.
I believe Java used (or still uses) a C library for SSE operations, and what language is the JVM written in? You cannot talk about performance without respecting the hardware.
Also, try writing a memory allocator in a language that doesn't give you memory access... If you're upset about garbage collection in C, take a look at Go or D.
|
You can write function implementations in the .h, but every time you modify something in the function, big parts of the project will be recompiled which will become a huge pain if your project grows.
If it doesn't, and the code won't be shared with other developers, you don't need to care.
|
On December 05 2011 06:05 mmp wrote:Show nested quote +On December 05 2011 05:58 AcrossFiveJulys wrote:
c++ is a total joke for OOP. annoying header files, include loops, and the necessity to overload the copy constructor in many situations and other c++ BS (e.g. manual memory management) has made me switch entirely to java/scala. The java compiler/JVM has come a long way so that compiled c++ isn't really that much more efficient than bytecode anymore, so there's little reason to continue using this language. Your prejudice is shortsighted. Many languages (Python, Haskell, others) fall back to C/C++ code to get performance. You have an abstraction barrier separating grammar & syntax from what is ultimately machine code any way you look at it. I believe Java used (or still uses) a C library for SSE operations, and what language is the JVM written in? You cannot talk about performance without respecting the hardware. Also, try writing a memory allocator in a language that doesn't give you memory access... If you're upset about garbage collection in C, take a look at Go or D.
Sure, the java compiler might be written in c++, but the point is that with java's JVM and compiler optimizations there is no point in using archaic languages. The abstraction layer is precisely what makes java a more productive language. I have used c, c++, and java extensively and it's amazing how much more productive coding in java is for little performance loss.
|
I don't remember C++ very well (it's been over a decade since I've used it seriously), but in vanilla C you can just stick simple programs in one .c file, no header files required.
By the way, C++ is an incredibly ugly language, but C by itself is very nice. If you just want to learn how to do memory allocation and stuff like that, learn vanilla C.
|
On December 05 2011 07:43 AcrossFiveJulys wrote:Show nested quote +On December 05 2011 06:05 mmp wrote:On December 05 2011 05:58 AcrossFiveJulys wrote:
c++ is a total joke for OOP. annoying header files, include loops, and the necessity to overload the copy constructor in many situations and other c++ BS (e.g. manual memory management) has made me switch entirely to java/scala. The java compiler/JVM has come a long way so that compiled c++ isn't really that much more efficient than bytecode anymore, so there's little reason to continue using this language. Your prejudice is shortsighted. Many languages (Python, Haskell, others) fall back to C/C++ code to get performance. You have an abstraction barrier separating grammar & syntax from what is ultimately machine code any way you look at it. I believe Java used (or still uses) a C library for SSE operations, and what language is the JVM written in? You cannot talk about performance without respecting the hardware. Also, try writing a memory allocator in a language that doesn't give you memory access... If you're upset about garbage collection in C, take a look at Go or D. Sure, the java compiler might be written in c++, but the point is that with java's JVM and compiler optimizations there is no point in using archaic languages. The abstraction layer is precisely what makes java a more productive language. I have used c, c++, and java extensively and it's amazing how much more productive coding in java is for little performance loss.
I don't think anyone's going to argue that c/c++ is easier to use than Java. But if you have a particular need for high performance, whether in speed or in memory usage, then you'll still want to resort to c/c++.
|
Learn C#. The functional aspects are incredibly cool.
|
I think you can visual c++ for free, there should be an express version. I use dot net for work, so the environment was very similar, (and I kinda liked it better after using borland c++ in school )
http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-cpp-express There ya go, the express version, but if you are a student I think you can get the whole package for free(express is a slightly stripped down version, but will do for most home projects/learning).
C/C++ is considered to be the language you can squeeze a lot of power depending on how good you are with it, and is the language of choice for games etc, but it has a higher learning.
Also one more thing with visual c++ I think there are two versions of all types, one is the framework managed type, and teh non memory managed ones, so you'll have to watch for that (not sure about this, but remember seeing something about it).
|
i use VS studio for C++. C im usually on a linux system and i use vim or gedit
if you're just doing this for kicks i dont think you'll find it very fun to bother with it, C++ is relatively similar to java, C is worth learning if you want to do low level stuff or fast computing because C works very similar to how the hardware works. C# is more comparable to java as well. anyway you'll probably just be figuring out how to do something in you could do in java in C++/C#, which is not very fun imo. the fun stuff is figuring out how to do things you couldnt do in java
if you want to try something wacky you could always try other style languages, functional or logical like haskell, a lisp fork, prolog...
|
On December 05 2011 07:43 AcrossFiveJulys wrote:Show nested quote +On December 05 2011 06:05 mmp wrote:On December 05 2011 05:58 AcrossFiveJulys wrote:
c++ is a total joke for OOP. annoying header files, include loops, and the necessity to overload the copy constructor in many situations and other c++ BS (e.g. manual memory management) has made me switch entirely to java/scala. The java compiler/JVM has come a long way so that compiled c++ isn't really that much more efficient than bytecode anymore, so there's little reason to continue using this language. Your prejudice is shortsighted. Many languages (Python, Haskell, others) fall back to C/C++ code to get performance. You have an abstraction barrier separating grammar & syntax from what is ultimately machine code any way you look at it. I believe Java used (or still uses) a C library for SSE operations, and what language is the JVM written in? You cannot talk about performance without respecting the hardware. Also, try writing a memory allocator in a language that doesn't give you memory access... If you're upset about garbage collection in C, take a look at Go or D. Sure, the java compiler might be written in c++, but the point is that with java's JVM and compiler optimizations there is no point in using archaic languages. The abstraction layer is precisely what makes java a more productive language. I have used c, c++, and java extensively and it's amazing how much more productive coding in java is for little performance loss.
Well "little performance loss" may hold true for coding non-real-time applications like office-applications but when it comes to real-time and especially games then you'll be clambering for those 5ms.
EA even wrote it's own STL implementation among other things to get better access to the memory allocation because memory fragmentation is going to cost you dearly, especially when you don't have much and you don't run on an out-of-order CPU (so consoles). There's a reason why minecraft for the XBox is not written in Java and it's mainly that you can't tinker with memory management, so no custom allocators.
edit: well ok, on the xbox the other reason may be that there is no access to JVM and using the .NET port would be highly stupid but the better example would be the pocket version for android. You'd think if it's for android then it'd be Java but on a device so limited in memory they had to use C++.
|
Well the .h is the declaration and .cpp is the implementation.I use Visual C++ and CodeBlocks.
I have to agree that latest builds of JVM(programmed in C++ of course) are pretty efficient but they will never match the speed of C++.
But Java sure is attractive with its thousands of API s,simple operators and extensive documentation.
|
|
|
|
|
|
EPT
