I was trying to output a unicode string using C++ IOStream. And I failed in this. It turnes out that it's a known bug in Visual Studio V6.0 which is declared to be fixed by the SP5 but it exists in VS7.0! If it's really so then it means that people do not really use the IOStream! All C++ projects which I worked with didn't systematically use STL and IOStream. Neither they systematically used all this fancy teamplate stuff. The impression was that they used C++ of 10 years ago.
So, this is how it all seems to me:
<C++ library developer>: I'd like to develop a very generic class. It'll be universal task solver. Since any software developer solves tasks everyone is in desperate need of the class. (template<typename Task, typename TaskData, typename TaskDataProperties<TaskData>> class UniversalTaskSolver;). Unfortunately this is not supported in the language right now :(
<C++ standard comittee>: Hmmm, this wants to develop this library. We should allow this flexibility in the language. Language should be flexible enough to accomodate this.
<C++ compiler developer>: Hmmmm, this new feature is apporved. We should be the first company to implement this in our compiler. Let's ship version 21.0 with support for this. We must be able to declare 95.6% standard conformance. This is good for marketing.
<C++ library developer [on the seminar]>: Here is my universal task solver library! It is supported by the compiler version 21.0 and it's the standard. Everyone should use it.
<average C++ developer [on the seminar]>: Yeah, yeah whatever. This looks cool. But I have a project , I have a deadline. I know such functions as printf, sscanf and I know how to implement my own bubble sort. And the rest of my group isn't on this seminar. No way we can use this library in our code. But it was an excellent and entertaining talk.
In the end, the new feature is implemented and the language is more powerful, but average C++ developer isn't using it. Language is more and more complicated while only 20% percent is used by 80%. At the same time other 80% of the language features are indeed needed and 50% of them are implemented in different languages like Java and C#. And some people switch to those languages because of this.
Is it really so? And if yes, what is the best way to convince peers to use C++ features? And is it worth it?
[ Send an empty e-mail to c++-h...@netlab.cs.rpi.edu for info ] [ about comp.lang.c++.moderated. First time posters: do this! ]
> I was trying to output a unicode string using C++ IOStream. And I failed in > this. It turnes out that it's a known bug in Visual Studio V6.0 which is > declared to be fixed by the SP5 but it exists in VS7.0!
You haven't stated what you think the bug is. I've done lots of Unicode I/O using VC++ from V4.2 on, so I have reason to believe the machinery basically works.
> If it's really so > then it means that peoplw do not really use the IOStream!
What an interesting conclusion. The iostreams machinery is indeed widely used. Wide streams are much less often used and are poorly understood by most programmers. But the latter does *not* negate the former.
> All C++ projects > which I worked with didn't systematically use STL and IOStream. Neither they > systematically used all this fancy teamplate stuff. The impression was that > they used C++ of 10 years ago.
That's also true for many programmers to date. But just because you haven't used something, that doesn't mean that all people do not really use it. And just because you failed to use something the way you hoped, that doesn't mean it's a persistent bug.
> So, this is how it all seems to me: > <C++ library developer>: I'd like to develop a very generic class. It'll be > universal task solver. Since any software developer solves tasks everyone is > in desperate need of the class. > (template<typename Task, typename TaskData, typename > TaskDataProperties<TaskData>> class UniversalTaskSolver;). Unfortunately > this is not supported in the language right now :(
[Long, funny description removed]
This is exactly how I feel about the more "functional" aspects of STL, i.e. the function binders and so on. It is as if they want us to never write a for-loop again. Instead we have to lookup everytime the names of bind_1st, mem_ptr, etc.
In my opinion, it is a lot better to write a direct for-loop than depending on these wrappers. If they wanted us to code in a more functional style, they should have given us a real lambda.
Someone is going to suggest Boost, but they don't have lambdas either, even though they want it to look that way. The favorite example of boost is something with "cout << _1 << endl;", which of course fails miserably if they do "cout << "Blah: " << _1 << endl;".
Bjarke
[ Send an empty e-mail to c++-h...@netlab.cs.rpi.edu for info ] [ about comp.lang.c++.moderated. First time posters: do this! ]
> I was trying to output a unicode string using C++ IOStream. And I failed in > this. It turnes out that it's a known bug in Visual Studio V6.0 which is > declared to be fixed by the SP5 but it exists in VS7.0! If it's really so > then it means that people do not really use the IOStream! All C++ projects > which I worked with didn't systematically use STL and IOStream. Neither they > systematically used all this fancy teamplate stuff. The impression was that > they used C++ of 10 years ago.
Post the code, I have to think you are doing something wrong. I've use the wide versions of the streams a little bit. However, when coding for windows you usually have a GUI, not too many apps are console/command line ones, and of the ones that are, most probably use the ACSII streams.
[ Send an empty e-mail to c++-h...@netlab.cs.rpi.edu for info ] [ about comp.lang.c++.moderated. First time posters: do this! ]
> <average C++ developer [on the seminar]>: Yeah, yeah whatever. This looks > cool. But I have a project , I have a deadline. I know such functions as > printf, sscanf and I know how to implement my own bubble sort. And the rest > of my group isn't on this seminar. No way we can use this library in our > code. But it was an excellent and entertaining talk.
If the "average C++ developer" is impressed by his/her own skills with printf and sscanf and the ability to write a custom bubble sort algorithm, then I think C++ in general may be a bit much for this developer.
I attended The C++ Seminar #1 last year (if this is representative of the style of seminar you are referring to), and I have to say I have since frequently used and even expanded upon many of the techniques presented throughout production level systems, and have trained others in my department on the use of some of these techniques, which they are beginning to incorporate in their own projects as well. Perhaps our system (VMS) has a more compliant compiler than others and we do not have to worry about LCD-quality compilers, as writers of portable library code do, so these "fancy" topics are indeed relevant to our work (and I like to consider it "real world" programming). Most of us don't exactly have PhD's...
> In the end, the new feature is implemented and the language is more > powerful, but average C++ developer isn't using it. Language is more and > more complicated while only 20% percent is used by 80%. At the same time > other 80% of the language features are indeed needed and 50% of them are > implemented in different languages like Java and C#. And some people switch > to those languages because of this.
If Java or C# can effectively serve the needs of programmer(s) for a particular problem, and the programmer(s) find it to be more straightforward, easier, or cost-effective to work with those languages inst ead of C++, then they should certainly consider them. If they persist in using those languages even in cases where it would clearly be a better choice to use C++ (most, imnsho ;-), then they are simply exercising poor or uninformed judgement. The correct definitions of "effective" and "better" may vary. ;-)
> what is the best way to convince peers to use > C++ features?
Actual working non-trivial-but-simple proof-of-concept code can be a quite powerful stimulus.
hys
-- (c) 2002 Hillel Y. Sims, all rights reserved. FactSet Research Systems hsims AT factset.com
[ Send an empty e-mail to c++-h...@netlab.cs.rpi.edu for info ] [ about comp.lang.c++.moderated. First time posters: do this! ]
> If it's really so then it means that people do not really use the IOStream!
No, it just means that people do not output Unicode. I'm not surprised.
> All C++ projects which I worked with didn't systematically use STL and IOStream.
I do. My group does. They did before I joined.
> Neither they systematically used all this fancy teamplate stuff.
We do. As much as we can, anyway, given the dodgy compilers.
> And some people switch to those languages because of this.
Language wars are juvenile. By all means, people should switch if doing so makes them more productive, or happier, or whatever. Meanwhile, the designers of any particular language should be working to perfect it in its own style.
> what is the best way to convince peers to use C++ features?
Demonstrate that a feature helps get the job done more easily, or faster, or more reliably.
[ Send an empty e-mail to c++-h...@netlab.cs.rpi.edu for info ] [ about comp.lang.c++.moderated. First time posters: do this! ]
>In the end, the new feature is implemented and the language is more >powerful, but average C++ developer isn't using it. Language is more and >more complicated while only 20% percent is used by 80%. At the same time >other 80% of the language features are indeed needed and 50% of them are >implemented in different languages like Java and C#. And some people switch >to those languages because of this. >Is it really so? And if yes, what is the best way to convince peers to use >C++ features? And is it worth it?
I'm convinced that the best way to convince peers and the masses is by example. If a particular feature serves a purpose better than an older feature, use it. As far as you or I should be concerned, let other people do it the 'old' way that's slower and less reliable. That makes my code and applications seem that much more impressive in comparison when the executable is half the size, twice as fast, and updated in a few hours instead of weeks.
Nothing speaks so loudly about your competency on the job as when you're five times as productive as your peers given the same tools to work with.
Joke myJoke() { Joke thejoke = "Now leave me alone, I've a lot more printf statements to write."; return thejoke;
}
Michael
-- To email me, remove nospam/ from my email address.
[ Send an empty e-mail to c++-h...@netlab.cs.rpi.edu for info ] [ about comp.lang.c++.moderated. First time posters: do this! ]
> This is exactly how I feel about the more "functional" aspects of STL, i.e. > the function binders and so on. > It is as if they want us to never write a for-loop again. Instead we have to > lookup everytime the names of bind_1st, mem_ptr, etc.
> In my opinion, it is a lot better to write a direct for-loop than depending > on these wrappers. > If they wanted us to code in a more functional style, they should have given > us a real lambda.
Indeed. Personally, I do not like STL, moreover I do not like all that 'metaprogramming' buzz. Yes, templates are very good thing, containers are very good thing. But STL is hard to use, unortoghonal, cryptic, performance-wise crippled. Instead of solving real problems, you end up devicing better ways how to express single two-lines loop using ten-lines long for_each-like idiom and template crap. Result is unreadable, hard to maintain and often slow code.
Mirek
[ Send an empty e-mail to c++-h...@netlab.cs.rpi.edu for info ] [ about comp.lang.c++.moderated. First time posters: do this! ]
> Someone is going to suggest Boost, but they don't have lambdas either, even > though they want it to look that way. The favorite example of boost is > something with "cout << _1 << endl;", which of course fails miserably if > they do "cout << "Blah: " << _1 << endl;".
I don't know how miserably, really, but yes, it fails. You have to write:
cout << constant("Blah") << _1 << endl
Best we can do, sorry. C++ doesn't really have lazy evaluation. If you want that you'll need to pick up some other language.
Alexy Maykov2035754861 wrote: > ... All C++ projects > which I worked with didn't systematically use STL and IOStream. Neither they > systematically used all this fancy teamplate stuff. The impression was that > they used C++ of 10 years ago.
[Examples snipped for space]
> Is it really so? And if yes, what is the best way to convince peers to use > C++ features? And is it worth it?
I certainly make much use of STL, and some use of IOStreams, although only the narrow-char versions. The eagerness of my colleagues to adopt such techniques seems to be proportional to their familiarity with 'C' and their willingness to learn new techniques in general.
I've had an interesting time trying to wean people off the container classes in the library that comes with our toolset [VCL] in favour of the STL as a first step. It's surprising how quickly they came over to the standard the second they had to support two compilers!
AFAICT, the 'majority' of programmers are happy using their tried-and-testing trick and techniques and will go to quite some lengths to avoid taking time out to learn something new, especially if they are being productive. In order to get such developers to embrace the last 10 years, you need to throw them into a new environment where the old tricks are not so easy/reliable as they once were.
OTOH, another group of developers will adopt anything/everything new that comes along. They were quick into Java, currently playing with C#/.NET, and probably a host of other languages as well. The problem here is pinning them down long enough to learn any new tricks in an 'old' language.
-- AlisdairM
[ Send an empty e-mail to c++-h...@netlab.cs.rpi.edu for info ] [ about comp.lang.c++.moderated. First time posters: do this! ]
