What is the hardest thing in C++?
The hardest thing that's C++ specific would be a combination of either:
1.Late binding, inheritance, or other OOP concepts in good depth.
2.Templates, pointers, or hash tables/binary trees, algorithmic problem solving, and good code structuring.
3.Maybe memory management as well, such as the stack, heap, etc..
However, once you know all of those three above good (although OOP is not required to be a successful programmer) you're off to being a great programmer in my book.
1.Late binding, inheritance, or other OOP concepts in good depth.
2.Templates, pointers, or hash tables/binary trees, algorithmic problem solving, and good code structuring.
3.Maybe memory management as well, such as the stack, heap, etc..
However, once you know all of those three above good (although OOP is not required to be a successful programmer) you're off to being a great programmer in my book.
Last edited on
closed account (3qX21hU5)
Its one thing to know all about the concept of c++ but its a whole nother beast to be able to use them effectively and with good designs to make a real program. That is probably the hardest part of any programming language.
@Select in: 3 is supposed to be hard because you're not supposed to do it manually :)
Last edited on
closed account (S6k9GNh0)
metaprogramming in C++ is only hard because it's ultimately a really big hack/workaround the C language. One reason why D really caught my eye is that it tries to build metaprogramming into the language from the beginning, the advantage of not being limited to C backwards compatibility... although it doesn't seperate compile-time and run-time functionality very well so it ends up being confused a lot :/
Last edited on
| 3 is supposed to be hard because you're not supposed to do it manually |
Yeah, but the real problem arises when you let the JVM handle memory for you.
It's virtualized, so it's not real.
Anyone up for forking the memory/process modules for the linux kernel and implementing kernel level sandboxing and garbage collection?
Last edited on
How about a computer with a switch on the back that can only be changed while it is off, with two settings "Fast" and "Safe", which would do as they suggest when your computer is running. Obviously you have to accept an additional end user license agreement before you can start using the "Fast" setting.
Last edited on
Linux kernel uses some kind of garbage collection internally. As well as gcc compiler.
Linux kernel and C++ are kept separate by a thing called Torvalds. That is much harder than anything within C++.
Yep, because he shuns garbage collection we can explicitly call his destructor.
Oh also, rapidcoder, I was not aware of that O:, in that case I'd like to make any easy interface to let it take care of garbage collection for an entire user level app.
Oh also, rapidcoder, I was not aware of that O:, in that case I'd like to make any easy interface to let it take care of garbage collection for an entire user level app.
IMO there is nothing that i would quickly say was "the hardest thing in C++". But in Software Development I think ensuring integrity and long term maintainability of your work is one of the hardest things. The vast majority of people do a very poor job of this, and this is why ironically I have no shortage in finding contracts.
When working on large software projects you need to ensure you:
- Write code that is simple and easy to follow
- Use logical amounts of documentation to explain your code
- Adhere to your coding standard
- Use unit tests to verify the integrity of your code and protect it from future changes
- Use source control with useful commit messages
- Avoid excessive use of anti-patterns
- Test your work for memory leaks, performance bottlenecks with a profiler
- Avoid refactoring large amounts of work for little functional gain
When working on large software projects you need to ensure you:
- Write code that is simple and easy to follow
- Use logical amounts of documentation to explain your code
- Adhere to your coding standard
- Use unit tests to verify the integrity of your code and protect it from future changes
- Use source control with useful commit messages
- Avoid excessive use of anti-patterns
- Test your work for memory leaks, performance bottlenecks with a profiler
- Avoid refactoring large amounts of work for little functional gain
Avoid refactoring large amounts of work for little functional gain |
Refactoring assumes no functional gain at all (at least not immediate).
But generally I agree to the content of your post.
Last edited on
Refactoring is often a catalyst for new changes. You need to assess the overall benefits of these changes before refactoring to ensure a decent ROI.
You can also refactor in your 'free' time so that when the time comes that you actually do need to make changes, you can get started right away.
@LB, Cheraphy
You can't call Linus' destructor because he's not RAII-compliant. You can, however, free() him from his fleshly tomb.
You can't call Linus' destructor because he's not RAII-compliant. You can, however, free() him from his fleshly tomb.
| Avoid refactoring large amounts of work for little functional gain |
I think the very definition of refactoring implies that there is no change in the overall functionality