please wait
What is the hardest thing in C++?
Apr 12, 2013 at 9:38pm
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 Apr 12, 2013 at 9:41pm
Apr 12, 2013 at 9:58pmclosed 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.
Apr 13, 2013 at 2:01am
@Select in: 3 is supposed to be hard because you're not supposed to do it manually :)
Last edited on Apr 13, 2013 at 2:01am
Apr 13, 2013 at 5:37amclosed 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 Apr 13, 2013 at 5:38am
Apr 13, 2013 at 6:47pm| 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.
Apr 14, 2013 at 1:52am
Anyone up for forking the memory/process modules for the linux kernel and implementing kernel level sandboxing and garbage collection?
Last edited on Apr 14, 2013 at 1:52am
Apr 14, 2013 at 2:25am
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 Apr 14, 2013 at 2:26am
Apr 14, 2013 at 8:10am
Linux kernel uses some kind of garbage collection internally. As well as gcc compiler.
Apr 14, 2013 at 1:23pm
Linux kernel and C++ are kept separate by a thing called Torvalds. That is much harder than anything within C++.
Apr 14, 2013 at 2:15pm
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.
Apr 14, 2013 at 10:41pm
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
Apr 15, 2013 at 7:46amAvoid 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 Apr 15, 2013 at 7:48am
Apr 15, 2013 at 8:44am
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.
Apr 15, 2013 at 1:18pm
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.
Apr 15, 2013 at 1:37pm
@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.
Apr 15, 2013 at 1:45pm| 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
Apr 17, 2013 at 8:12am
Hardest thing in C++ is convincing yourself that you are C++ Guru