Agree or disagree?
Posted 04 January 2012 - 07:48 AM
Posted 04 January 2012 - 10:52 AM
I don't know if you heard the old joke interview about c++.
The story that it was invented because universities got too good at churning out really good c programmers, so c++ was designed to be incomprehensible to new coders so that aging coders could have some job security.
Most places use about 20% of the features of c++, some less than that. The few places I have been involved with that use most of the features of c++ are horrible to work with and usually churn out awful code. Symbion for one.
Even now some of the features of c++ are not fully supported in some compilers as I have found out to my cost in a couple of cases
In some cases the features of c++ are counter productive and cause crashes for new coders. Like none virtual destructors.
So I agree with you.
Posted 04 January 2012 - 02:28 PM
I am curious: name a useless C++ language feature?
Complexity and richness does have a cost, but don't confuse mangled inheritance, template abuse, excessive exception returns and such as being a problem of the language itself. More often than not, it's the programmer that is useless.
Think of it this way: a carpenter has a set of tools. He uses the circular saw a lot, the coping saw moderately, and the veneer saw even less. Does that mean the veneer saw is useless? I guarantee that when you need that veneer saw, there's no way to use a circular saw instead. Same with C++ language features.
Posted 04 January 2012 - 02:57 PM
Posted 04 January 2012 - 04:32 PM
I think const_cast is a bit of a dumb feature, as is the explicit keyword (IMO most objects should be instantiated explicitly, with a select few exceptions). I disapprove of the new c++11 lambda feature as well, but it's as you say, it depends on the developer. I've worked with .NET code that was littered with anonymous functions and it's just a SOB to work with.
Although overall I have to disagree with the OP. C++ is a great language because it gives you control, it doesn't take it away from you. I may have no need for certain things or stay clear of certain features, but others might and it works for them.
Posted 04 January 2012 - 07:53 PM
Being able to guard against misuse of constructors with the explicit keyword is actually occasionally useful, if again not the norm. (The explicit keyword aplies to constructors, not objects.) I've needed it.
Lambdas are necessary-ish if you use templates and want anonymous, inline functions versus having to declare separate functor elsewhere. But, like exceptions or multiple inheritence, can easily be abused by "self-empowered" intermediate coders.
I think you can find similar edge functionality in any language, which kinda makes the OP's question either true because it is universally true, or false because very rarely is something truly useless.
Posted 05 January 2012 - 04:59 AM
2.Private and protected members of a class. Can anyone name a REAL, and I mean REAL 100% efficient and worthwhile reason as to why a member of a class has to be protected or private in the first place or in any manner that anyone REALLY cares about?
3.C++'s Object-Oriented-Programming altogether and all OOP bugs me simply because I don't see in reason in programming that way in my mental image of programming - I don't believe things should be in "classes" and I don't believe that's how my code should work. But if there's anything annoying and that I find kind of dumb about OOP is C++'s Polymorphism, second being Friendship and Inheritance of classes. Not going to lie and say they're 100% stupid, but there's plenty of debate I can give you on those topics.
4.I have fathomed it for a while and decided that function templates are also somewhat pointless in my opinion. I mean given a wide, long and unlimited train of thought in an extended possibility of programming, tools and game development I can't really see one single particular use I can point out as to why I'd ever use them.
6.#defines ... seriously, give me one special thing about them. It's literally the same thing, almost exactly, as a const container. Where's the real noticeable difference with it?
8.Any well given explanations of the use of an enum? I mean what good is a type of my own? Correct me because I am a beginner no doubt, but I seriously find somethings absolutely to a point that are so obscure and pointless that I can't imagine why it would be useful to me given every other basic feature to write a computer program I already have.
9.Function overloading - another obscure feature of C++ that I have fathomed and fail to see clarity in its use.
10.Virtual base classes.
I'm pretty sure some are debatable, but I'd like to hear someone really make me see use in some of those previous mentioned features I find useless - and I mean REAL explanation, because just because it suits you doesn't mean I can make it useful in the way I see things.
And if you're ignorant to the way I think and do things then don't even bother replying. Just because you prefer it doesn't mean I do, or even see in any use in it for that matter.
Posted 05 January 2012 - 07:45 AM
2. In general, information-hiding can be a good thing when used to assist modularity by reducing coupling. But this only becomes relevant for fairly large pieces of software; for small hobby projects there's not much need for modularity. Actually, I think C++ makes a mistake and conflates classes and modules, which are really two orthogonal concepts, by implementing information-hiding at the class level. Some other languages only have information-hiding at module boundaries, but all classes within the same module are public to each other; I think this is a better approach.
3. OOP has been a contentious subject since its inception, and there are plenty of programmers, including well-respected ones, who disdain OOP. If you don't like OOP you obviously aren't going to like inheritance or polymorphism either, as those are core concepts of OOP. Friends, I agree, are kind of a messy hack, which also ties into what I said about modularity above (friends are a partial workaround for C++'s lack of a true module system).
4. Function templates are handy for the same reason that class templates are: to write functions that can operate on various different types, without needing to duplicate the code explicitly for each type. For example, std::sort is a function template that can sort an array of any type of element.
5. If you don't want to use templates, then good luck getting by without type casts! Seriously, though, I agree that type casting is messy and to be avoided where possible; it's often a sign that either the software design or the programming language's type system is poor. But if you do much serious programming you'll run into cases where it's necessary (or at least the least-bad solution).
6. #defines are part of the preprocessor. Today, they are mainly used for macros. You can read more about preprocessor macros online, but they are one of those things that are easy to misuse and many programmers consider them "evil". They are really useful for a few specific things, though, such as asserts (runtime error messages) that automatically include the file and line number in the source code where the error is being detected.
7. Function pointers are also pretty uncommon, but really useful for a few specific things. I use them in unit testing, where I have a function for each test and create an array of function pointers to all the tests, so I can easily iterate and run all of them in a loop. They're also useful when embedding a scripting language into an application, for providing hooks for the scripts to call C++ functions. And they've traditionally been used for callback functions (e.g. the WndProc in Windows), though the more modern way to do that is with interfaces.
8. Enums are useful anytime you're going to have a variable with a discrete set of values that are not intrinsically numerical. For example, error codes (or other kinds of return codes), or states in a state machine, or sets of mutually exclusive options like what kind of weapon an NPC has (e.g. pistol, machine gun, or grenade launcher). Sure, you could use ints for all these things, but enums have some advantages: they automatically get re-numbered when you add/insert/remove items, they form a new type that's distinct from int so it's harder to accidentally store an invalid value in an enum variable, they document (for the benefit of programmers reading the code) what the valid values are for a variable, etc.
9. Overloading is useful anytime you have an operation that can take several alternative sets of parameters, but it still makes sense to call all the variants by the same name. For example, a geometric plane can be defined either by three points on the plane, or a point and a normal vector. You could have two overloaded functions that compute the plane coefficients, one which takes three points, and one which takes a point and a vector. Of course you could give these functions different names, but it's more concise to just overload them, and is unlikely to cause confusion.
10. Yeah, I've never used virtual base classes. Multiple inheritance is generally considered evil, except for interfaces, and the "diamond pattern" that gives rise to the necessity of virtual base classes is especially evil.
Really, this is not a productive thing to say. How are we possibly going to know what is "the way you think and do things"? Probably no one thinks and does things exactly the same way you do, so should no one answer? Anyway, it won't kill you to listen to some other people's views. Hell, you might even learn something new!
Posted 05 January 2012 - 12:32 PM
I completely disagree on this one, especially concerning inheritance. Programs are better organized and easier to change if you start with a simple building block and build on it through inheritance. I don't think it's absolutely the most efficient way, but it's the better organized way of doing it. You'll see it in games, and engines a lot where they start out with an entity that just has some main characteristics like position, etc, and then build up to static objects that have mass or size, then characters, friends, enemies etc. When you do it that way, you can add things to the base class later that will affect all the classes that inherit from it, or in reverse, only affect the branch you have chosen. I'm using Unity right now, which is a component based engine, and I can't do that and it's a bother. I like a lot of things about it, but I hate that I can't use inheritance on the Game Object. My code is much more messy and hard to manage and I'm stuck in the Unity way of doing things. I've used other engines where I could create classes that inherited from the base object and I liked it a lot better. As the program gets larger, it keeps getting easier and easier to add things and know just where they belong, etc. It's not absolutely necessary and there are other ways to organize, but I think it's one of the best ways of organizing. Just look at some open source projects sometime and you'll see they are mainly OOP because anything else would be a nightmare.
I very seldom bother with private members of classes or all the getters/setters that everyone thinks are necessary. Maybe for a very large program or something, but for me it's not necessary. I use a lot of statics because a large percentage of the time you only need one and it's easier to access them that way.
Posted 05 January 2012 - 04:05 PM
- Typedefs are aliases or shorthands for new types, primarily structs, and thus they are also carry-overs from C. So, you should call this a "useless" C feature, not a useless C++ feature, carried over to help maintain backward compatibility. And, I double-quote because it isn't useless in C. One not-mentioned benefit in the use for typedefs is the same for any kind of aliasing: it adds a layer of indirection. You can alter a lot of code in one place, rather than in multiple places.
- As Reedbeta says, private and protected exist to help organization of the codebase in large projects, esp. those with shared subprojects. For example, you are creating a framework for other devs. Now, if you just code throw-away code for yourself, this would probably be useless to you. Otherwise, it is very useful to many.
- Object-oriented programming is simply one of many paradigms that lends itself very well to many scenarios. It exists, again, to manage projects of a size greater than school homework projects that have more than one cowboy coder. But, it is not the only paradigm and you should learn others too. That does not make it useless. It is popular because it was first to mitigiate the rampant spagetti code of the 70s and 80s.
- This is where you really you lose me. How you can't understand the usefulness of function templates is beyond me. They help you stay DRY. If you ever write three methods that do the same thing, but only vary in parameter(s) type, you would greatly benefit from this. If you don't ever need this, you've probably never written any code of any noticeable complexity. This kind of functionality belongs to the wider, wonderful world of generics. If you are writing a little text-based adventure game like in a "C++-in-21-Days" book examples, yeah, you probably have little need for generics.
- Casting exists in every language. If you do a lot of it, then you may have design issues. But, every codebase I've seen, across multiple languages that have static typing, will have places where casting is inevitable.
- Hmm. Actually, I guess you would want to avoid both #defines and global consts in general practice. Arguably, defines are not a function of the C++ language, I think, but rather a pre-processor directive.
- Again, once you start understanding that functions can be used, swapped and manipulated just like data or classes, then you can really create some solid, compact code. That day may come, but your mind seems closed in ahead of time for some reason. Of course, functional programming is a bigger mind-twist for some than OOP, so beware.
- Enums are a way to create a type with a limited list of possible values. It's primarily a way to constrain your system to control errors. Again, a lone coder on throw-away code can be forgiven for not using them at all, but I'd flay alive any staff that doesn't take advantage of them to help ensure robust code.
- Overloading. Again, throwing the baby out with the bathwater. Yes, overloading is open to abuse, and yes, it does complicate the implementation of the language by the compiler writers, given there will possibly be difficult cases of ambiguity. But, OMG, I am trying to imagine something like I/O without overloading: ReadLongFromFileStream(), ReadIntFromFileStream(), ReadDoubleFromMemoryStream(), ReadStringFromXMLStream(), etc, etc, etc. Furthermore, imagine you introduce a new "from" type, say JSON instead of XML. You have so much code to go futz around with. That would be ice-pick-in-head ugly.
- Virtual base classes are a powerful feature to handle multiple inheritence in C++. For overcomplexity, multiple inheritence is frowned upon, but sometimes unavoidable. But, if you have to walk down that road, virtual base clases are useful for sister delegation. Again, this is like saying that a veneer saw is useless because only master carpenters use them. The flipside of that coin is that if we eliminate master functionality, only the lowest common denominator remains.
That's fine. Being close-minded before friendly debate even begins is defensively comfortable for you, but not useful.
As another analogy, a first-time home owner will often try to use a hammer and a Philips screwdriver for fixing everything. Eventually, they learn to use the right tool for the job and buy a full toolset.
Good luck with your coding!
Posted 05 January 2012 - 04:20 PM
I read an article a few years back from one of the programmers behind the Tony Hawk Pro Skater series. He explains how they refactored their code base from an object hierarchy to a component based system, and how it affected their development.
The Go programming language kind of embraces this style of coding, and I think it looks promising.
Posted 05 January 2012 - 06:14 PM
I haven't found it to be any better myself. There is a place for components and a place for inheritance, I think. Design is much more important when using inheritance, I'm sure. With components, you have to constantly redesign an object that is slightly different instead of just inheriting all that work you did already. I don't think refactoring is as hard as it used to be, either. Most compilers have systems built in for it. I think component based engines suck eggs. Every time you come up with another object, you are back to square one.
Posted 06 January 2012 - 05:52 AM
Thanks for making it CRYSTAL clear that I'll never be as good of a programmer as you!
Congrats on putting the sticks down and letting me know that now, for a fact, I'll never be what I want.
Hope you're happy.
EDIT: I thought my progress in programming was good, but after hearing all your alien talk it just puts me back in my place of pure amateur.
I don't even feel as if continuing to learn programming will benefit me anymore since I'm obviously in a forum talking to mega-geniuses of the topic who baffle confusion with every following sentence.
Not to mention having such knowledge that you feel like you're retarded on the subject.
If there is a way that programming can ACTUALLY be worthwhile, let me know.
Oh well ... thus is life, and not everyone makes it far in it and does what they want...
ALSO, no one has any right to call me close-minded when if something makes no sense to me looking from every which way that I don't use it or prefer it.
That's like me calling you close-minded because you won't see and admit things from a pedophile's perspective.
Anyhow, basically just wasting my time here from now on.
Posted 06 January 2012 - 06:12 AM
Posted 06 January 2012 - 06:26 AM
Honestly, this has been quite the show - too bad you've all been victims to a scheme! LOL!
I'm a professional programmer and I've been developing games for years in Assembly.
You people are just too easy.
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users