Is it really hard to find someone who know how to make a good use of stl
and combined the power of GP and OOP?Like the way modern c++ design did?

There are so many people say these kind of techniques are unrealistic
because there are only a few of peoples know how to use them

That means, when you stay in a group, you can't or should not use it
because the other peoples would not be able to decipher and maintain your codes

Although there are a lot of brilliant 3rd parties were developed by those techniques
But when you are in a group, you have to follow the design styles of the group.
And should not use the techniques your groups do not familiar with.

Some of my friends say it is useless to learn it, since there are no
one would like to use it and you can't use it because there are no one
know how to use it.

Only those top class company are able to use these kind of techniques?
If I want to learn and be able to see those advance(?) techniques
I have to get into those top class company?

Thanks

Some of my friends say it is useless to learn it, since there are no
one would like to use it and you can't use it because there are no one
know how to use it.

There's some truth to that opinion. But avoiding the techniques doesn't make them any more visible and the cycle of avoiding them because they're unfamiliar continues.

It can be difficult finding a balance between simplicity and power. Modern techniques tend toward the complex, which makes judicious use of them even more important when trying to write accessible code.

> Is it really hard to find someone who know how to make a good use of stl

No. AFAIK, STL (and in many cases boost) have been mainstream for some years.


> ... Like the way modern c++ design did?

Yes. 'Modern C++ Design' went beyond just making good use of STL. I think the techniuqes that Alexandrescu introduced are far from obvious to the vast majority of C++ programmers out there. It takes quite some getting used to, and poor diagnostic support from compilers and poor template debugging facilities don't help.

In practise, I think what would work is: start with specific (non-generic) solutions to specific programming problems, discover reusable abstractions over a period of time, and gently evolve towards a more generic refactoring of the design. Refactoring is something you have to do in real life, and conceptually refactoring (to) generic code is not any more difficult than refactoring (to) object-oriented code.

The situation with C++11 (type_traits, enable_if, polymorphic call-warppers and so on) in 2011 is no different from the situation in 1998 with respect to standard algorithms and function objects.

>> Is it really hard to find someone who know how to make a good use of stl

I would say that people who can't make good use of STL are not really "hire-material" for any kind of job where C++ programming skill is a key asset. Using the STL, and to some extent Boost, is pretty main-stream today. Using STL containers, making some use of STL algorithms, being familiar with smart-pointers, and so on, are pretty basic skills today in C++ programming. I would say that someone who lacks that has sub-par proficiency in C++.

>> and combined the power of GP and OOP?

Those who are only proficient in plain OOP (i.e. Java-like OOP skills) are functional but seriously handicapped in C++. It is also important to note that even though people might not be proficient at harvesting the power of GP in their own design (i.e. making GP functions or classes), it doesn't mean they not able to use GP libraries (like the STL or Boost). You can easily teach a beginner to use std::vector or std::sort or boost::shared_ptr , even though they have no idea of how to make similar stuff, let alone the design methodology involved in doing that. Someone who can comfortably use GP techniques and design methodologies is a person I would qualify as an "advanced" or "expert" C++ programmer (depending on the level of sophistication).

>> Like the way modern c++ design did?

Remember that Alexandrescu's book was quite revolutionary. At the time of publication (2001), very few of what is in his book could even compile on most compilers, although his implementations were all standard-compliant, that's how ground-breaking it was. Today, the kind of things in his book are common place in high-quality libraries (like some Boost libraries, and a few others). Remember also that his techniques are mostly classified under "template meta-programming", which is definitely beyond GP on the learning curve. Surely, today, TMP is still not very accessible to most C++ programmers. But again, many libraries can hide the TMP in the entrails of a library, making it relatively easy for users to use it without them even knowing (since, on the surface, it will often just look like a normal GP library like STL). In general, someone who is comfortable with TMP techniques and template wizardry in general, could be classified as "expert" or even "master" programmers (btw, I humbly consider myself an "expert" in C++ because I am pretty comfortable with TMP and very proficient in GP, but I certainly have much to learn still).

>>There are so many people say these kind of techniques are unrealistic because there are only a few of peoples know how to use them

That's true. Although it is certainly a vicious cycle, as Narue pointed out. I would say one encouraging thought though, most people recognize that GP and TMP has a lot of potential to produce high-quality libraries and great run-time performance, so at least most people are aware that using it would be a good thing and they also recognize that they are not "experts" yet, and that they still have things to learn (i.e. people no longer find themselves on the learning plateau of good OOP skills thinking that they are done learning without realizing there is a higher summit to reach in their learning process).

>>That means, when you stay in a group, you can't or should not use it because the other peoples would not be able to decipher and maintain your codes

That's also true, but I would say that although people are often not comfortable with creating GP code, they are much more comfortable with reading, understanding and modifying existing GP code, as long as it is not too heavy with TMP techniques (Sfinae switches and meta-functions). For example, if you write a generic vector-like container (excluding the "Allocator" part), most C++ programmers would be fairly comfortable with these kinds of basic forms of GP, and that's usually a good starting point to introduce GP techniques into a library (as in, just "parametrizing on the value-type" is usually well received and understood).

>>But when you are in a group, you have to follow the design styles of the group. And should not use the techniques your groups do not familiar with.

Usually people are quite happy with things that spare them time in coding (increases reusability), and doesn't require significant changes to existing code (e.g. turning a function into a function template can easily go unnoticed). It's a lot easier to convince someone that a function or class should be made generic (via templates), than it is to convince them that a certain change in the class hierarchy is needed. For instance, if you hear: "I'd like to use your code but I'm already locked into a given OOP class hierarchy and it could be a bit of trouble to interface the two (yours and mine)" when you tell them your library is generic and doesn't need interfacing two OOP class hierarchies, they will be pretty happy. This is a starting point to show them the usefulness of learning and using GP techniques.

>>Some of my friends say it is useless to learn it, since there are no one would like to use it and you can't use it because there are no one know how to use it.

Yeah, there are a lot of coward and/or lazy people in this world. Too lazy to learn GP, or too coward to step into a new programming paradigm, or both.

>>Only those top class company are able to use these kind of techniques?

Have you thought that maybe causality is the other way around? That is, companies that use these kinds of techniques tend to rise to the top. I can easily see how that can happen, given the real-life benefits of GP (i.e. robustness, performance, scalability, etc.). I thought the point of Capitalism was to make the decisions that make your company the most competitive on the market, and the accumulated skill of the professionals that work at a company is one of the biggest assets a company has. So, in that perspective, I would see it as a good investment.

>>If I want to learn and be able to see those advance(?) techniques, I have to get into those top class company?

Or, make your company a top-class one by getting them on-board with GP. The way to do that is empirically. Managers only like to see their bottom-line grow, and, as I said, there are many ways in which GP can do that, so, show them "da money!" (e.g., "we spared X amount of development time because we could reuse generic code", or "we spared X amount of testing time because most of our generic code was already field-tested"). This can take time, be patient, or go to a "top-class" company.

Thanks for your opinions, I was a little bit curious about the meaning of learning
or studying the book like "modern c++ design", since in my environment(Taiwan),
There are only a few of programmers would like to learn GP or study TMP.
For most of the programmers in Taiwan, they don't know how to work with the
algorithms of stl like, but most of them know how to use those "containers" like
products generate by GP. I would be very happy if I could find someone who
like to study GP with me.
I feel sorry that our schools only teach students C++ as C with classes, so many
programmers in Taiwan don't know C++ have the ability to wrap those tedious works
by GP without losing any runtime performance, many of them don't know and refuse
to believe this is possible, just wonder why.
Whatever, even GP and TMP can't make a good use in my job, it is my interest
I will keep studying them.

The situation with C++11 (type_traits, enable_if, polymorphic call-warppers and so on) in 2011 is no different from the situation in 1998 with respect to standard algorithms and function objects.

I think these facilities would make GP become much more convenient, atleast we have
them become standards, so every decent compilers should support these features.

This can take time, be patient, or go to a "top-class" company.

I would like to go to those "top-class" company if I had a chance, but I have
to keep learning before I have the ability to go there.I start learning C++
and decided to become a C++ programmer about one year ago(although I learn
soome C before that (EE student)), there are still too many things to learn.
I study some data structure and algorithms in school, but nothing like OS,
compiler, internet or how to co-work with other languages and so on. Still
an ordinary programmer.

> I think these facilities would make GP become much more convenient, atleast we have them become standards,
> so every decent compilers should support these features.

Yes, every decent compiler would (given an year or two) support these features.

The problem is that in the real world there are too many senile C++ "experts" who believe that education stops at graduation, and are averse to anyone using anything that they themselves have no desire to understand.

It takes time and patience; that is all. Over a reasonably short period of time, even the newbies realize that the world has moved on.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.