This is a recurring and entrenched permeating this group... hence
treat it as such
I have recently started a new job, and to my surprise, we still write
a fairly traditional c++ code, still using raw pointers, and still in
market with our products.
How popular is this scenario?
What's the future for C++, other than ceasing years of
maintainance ?
Will new standardization create new markets for c++ developers and
applications, will it expand the application domain?
These are broad questions, seeking some reassurance, hope... well,
perhaps not so dramatic, but am genuinely curious what other think
about.
PuzzleCrakcer!
71  3319 
puzzlecracker writes:
This is a recurring and entrenched permeating this group... hence
treat it as such
I have recently started a new job, and to my surprise, we still write
a fairly traditional c++ code, still using raw pointers, and still in
market with our products.
How popular is this scenario?
Fairly popular, I'd say. In the grand scheme of things, STL matured fairly
recently. Plenty of code still around, dating back from pre-STL days.
What's the future for C++, other than ceasing years of
maintainance ?
New development, going forward, should use STL, and modern language
features.
Will new standardization create new markets for c++ developers and
applications, will it expand the application domain?
I believe that there will be plenty of new markets for skilled C++
developers, as less-skilled developers will migrate to Java and .NYET, and
when management comes to a realization that well-written, efficient C++ code
will spank the monkey out of Java and .NYET.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEABECAAYFAkiDcbgACgkQx9p3GYHlUOI1bQCdG+b/vmKq7DKcsvQy3/Z5ej88
bWwAn0osvv5JnncmEVcoSsxtUfNX4lPL
=pSOG
-----END PGP SIGNATURE-----
On Jul 20, 12:36 pm, puzzlecracker <ironsel2...@gmail.comwrote:
This is a recurring and entrenched permeating this group... hence
treat it as such
I have recently started a new job, and to my surprise, we still write
a fairly traditional c++ code, still using raw pointers, and still in
market with our products.
How popular is this scenario?
What's the future for C++, other than ceasing years of
maintainance ?
Will new standardization create new markets for c++ developers and
applications, will it expand the application domain?
C++ urgently needs support for multi-threading/tasking IMHO.
>
These are broad questions, seeking some reassurance, hope... well,
perhaps not so dramatic, but am genuinely curious what other think
about.
PuzzleCrakcer!
On Sun, 20 Jul 2008 09:36:27 -0700 (PDT), puzzlecracker wrote:
>I have recently started a new job, and to my surprise, we still write
a fairly traditional c++ code, still using raw pointers, and still in
market with our products.
because the 'traditional' way of writing real-world C++ code is still
better than 'modern' C++.
>How popular is this scenario?
very popular. Even Google uses it.
>What's the future for C++, other than ceasing years of
maintainance ?
Maintainance programming isn't that bad if you value a relatively
secure job. Maintaining a large grown code base and understanding the
domain logic behind is anything but simple.
>Will new standardization create new markets for c++ developers and
applications, will it expand the application domain?
Nothing from the new Standard I've seen so far supports this
speculation. Quite the contrary. The C++ Standards committee seems to
have lost any contact with real-world C++ programming. They attempt to
add even more complexity to an already over-complex language.
>These are broad questions, seeking some reassurance, hope... well,
perhaps not so dramatic, but am genuinely curious what other think
about.
C++ is still strong in certain niches where it is mostly used as a
better C (C with classes). Job ads nowadays often look for C/C++
skills instead of 'pure' C or C++ skills.
--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch
C++ urgently needs support for multi-threading/tasking IMHO.
Indeed, do you think the support for multi-threading application will
again put C++ at the top of food chain, and resume its gain in
popularity?
Don't forget, a plethora of libraries that support multi-threading is
already in existance, making it a language feature would be no more
that convenience, I think.
C++ should also enter the realm of Internet. And once it does, it will
with ease displace java and other powerhouse.
how about making C++ a platform neutral?
How about making faster?
C++ urgently needs support for multi-threading/tasking IMHO.
Indeed, do you think the support for multi-threading application will
again put C++ at the top of food chain, and resume its gain in
popularity?
Don't forget, a plethora of libraries that support multi-threading is
already in existance, making it a language feature would be no more
that convenience, I think.
C++ should also enter the realm of Internet. And once it does, it will
with ease displace java and other powerhouse.
how about making C++ a platform neutral?
How about making faster?
because the 'traditional' way of writing real-world C++ code is still
better than 'modern' C++.
Why? Isn't more error-prone, harder to maintain, and becoming obsolete
given that new and improved libraries sooner, if not already, catching
up in speed and features?
Maintainance programming isn't that bad if you value a relatively
secure job. Maintaining a large grown code base and understanding the
domain logic behind is anything but simple.
Thanks, sometimes aged code is a big pile of mess...it just doesn't
get better with time, contrary to wine. Otherwise, I agree, it's
fairly challenging. I still want to move on to build systems ground
up in c++... though language is not the prerogative for that.
Nothing from the new Standard I've seen so far supports this
speculation. Quite the contrary. The C++ Standards committee seems to
have lost any contact with real-world C++ programming. They attempt to
add even more complexity to an already over-complex language.
I am under the same impression
On Sun, 20 Jul 2008 12:11:21 -0500, Sam <sam@...comwrote:
>In the grand scheme of things, STL matured fairly
recently. Plenty of code still around, dating back from pre-STL days.
STL was introduced in 1995 and standardized in 1998. It came from a
single source and was usable from the beginning (although popular
compilers didn't support all STL features). Moreover, STL was
tremendously hyped for years (this is not an exaggeration as anyone
interested in C++ in the late nineties can confirm). STL's low rate of
adoption is rooted primarily in the STL, not in lazy and unwilling
programmers.
The major STL problems are obvoius by now:
- restricion to value semantics
- template obfuscation, esp. through allocators
- non-optimal iterator design
>New development, going forward, should use STL, and modern language
features.
I would have subscribed to this recommendation in 1998. In 2008 it is
refuted by reality.
--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch
On Jul 20, 9:01 pm, george.p...@gmail.com wrote:
On Jul 20, 12:36 pm, puzzlecracker <ironsel2...@gmail.comwrote:
This is a recurring and entrenched permeating this group... hence
treat it as such
I have recently started a new job, and to my surprise, we still write
a fairly traditional c++ code, still using raw pointers, and still in
market with our products.
How popular is this scenario?
What's the future for C++, other than ceasing years of
maintainance ?
Will new standardization create new markets for c++ developers and
applications, will it expand the application domain?
C++ urgently needs support for multi-threading/tasking IMHO.
These are broad questions, seeking some reassurance, hope... well,
perhaps not so dramatic, but am genuinely curious what other think
about.
PuzzleCrakcer!
yes now multicore processors needs threads. and threads not standart
in C++.
But threads can efficiently be used up to 4 cores. not more cores.
That is threads
are short term solution, not long term. I think that 16/32/.. etc core
chips will be
produced soon. And a great probability, transaction memory management
as a real
solution for multicores will be used in the next time.. Tö my opinion
transaction memory management should be in C++
I would have subscribed to this recommendation in 1998. In 2008 it is
refuted by reality.
The only practical use of STL to this day is to code solutions in
programming challangies (TopCoder, ACM, etc).
On Jul 20, 3:03 pm, puzzlecracker <ironsel2...@gmail.comwrote:
C++ urgently needs support for multi-threading/tasking IMHO.
Indeed, do you think the support for multi-threading application will
again put C++ at the top of food chain, and resume its gain in
popularity?
I don't know, but it will give it better chances for sure.
>
Don't forget, a plethora of libraries that support multi-threading is
already in existance, making it a language feature would be no more
that convenience, I think.
That's more of the problem: too many libraries. Rather have one
elegant solution. Besides how far libraries can take you. At some
point you will need to change the language.
>
C++ should also enter the realm of Internet. And once it does, it will
with ease displace java and other powerhouse.
That will be more realm of run-time libraries (as is with Java
or .NET).
>
how about making C++ a platform neutral?
How about making faster?
On Jul 20, 8:01 pm, george.p...@gmail.com wrote:
On Jul 20, 12:36 pm, puzzlecracker <ironsel2...@gmail.comwrote:
C++ urgently needs support for multi-threading/tasking IMHO.
It has it in practice, but it certainly does need that that
support be standardized. Which will be the case when the next
version of the standard appears.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Jul 20, 3:48 pm, izmirli <nanotu...@gmail.comwrote:
On Jul 20, 9:01 pm, george.p...@gmail.com wrote:
On Jul 20, 12:36 pm, puzzlecracker <ironsel2...@gmail.comwrote:
This is a recurring and entrenched permeating this group... hence
treat it as such
I have recently started a new job, and to my surprise, we still write
a fairly traditional c++ code, still using raw pointers, and still in
market with our products.
How popular is this scenario?
What's the future for C++, other than ceasing years of
maintainance ?
Will new standardization create new markets for c++ developers and
applications, will it expand the application domain?
C++ urgently needs support for multi-threading/tasking IMHO.
These are broad questions, seeking some reassurance, hope... well,
perhaps not so dramatic, but am genuinely curious what other think
about.
PuzzleCrakcer!
yes now multicore processors needs threads. and threads not standart
in C++.
But threads can efficiently be used up to 4 cores. not more cores.
That is threads
are short term solution, not long term. I think that 16/32/.. etc core
chips will be
produced soon. And a great probability, transaction memory management
as a real
solution for multicores will be used in the next time.. Tö my opinion
transaction memory management should be in C++
I agree, support for MT should include protected memory access of some
sort. Challenge is to make it in elegant way that may prove impossible
without restricting use of raw pointers.
On Jul 20, 7:11 pm, Sam <s...@email-scan.comwrote:
puzzlecracker writes:
This is a recurring and entrenched permeating this group...
hence treat it as such
I have recently started a new job, and to my surprise, we
still write a fairly traditional c++ code, still using raw
pointers, and still in market with our products.
How popular is this scenario?
Fairly popular, I'd say. In the grand scheme of things, STL
matured fairly recently. Plenty of code still around, dating
back from pre-STL days.
Typically, it takes something like 25 years for practice to
catch up with theory, so don't expect STL to dominate even
today. The current situation is that you get all possible
extremes: STL, Boost and TMP taken to a point beyond reason, and
people who refuse to even consider using templates. Most shops
are somewhere near the middle of the continuum, however,
integrating the STL in their new code, and maybe even a few
parts of Boost, but avoiding the extremes.
What's the future for C++, other than ceasing years of
maintainance ?
New development, going forward, should use STL, and modern
language features.
Green fields projects, yes. New modules in existing code still
have to interface with the existing code (which can be a pain at
times, when you know that much better solutions exist).
Will new standardization create new markets for c++
developers and applications, will it expand the application
domain?
I believe that there will be plenty of new markets for skilled
C++ developers, as less-skilled developers will migrate to
Java and .NYET,
The bluffers migrate to the "in" language. I think Java has
passed that stage by now (and I can remember when it was C++,
and some of the CV's we saw).
and when management comes to a realization that well-written,
efficient C++ code will spank the monkey out of Java and
.NYET.
I doubt that efficiency of the code will play a role. The fact
that in a well managed project, C++ will typically result in
higher programmer efficiency and more reliable code will swing
the balance, however.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Jul 20, 9:03 pm, puzzlecracker <ironsel2...@gmail.comwrote:
C++ urgently needs support for multi-threading/tasking IMHO.
Indeed, do you think the support for multi-threading
application will again put C++ at the top of food chain, and
resume its gain in popularity?
Don't forget, a plethora of libraries that support
multi-threading is already in existance, making it a language
feature would be no more that convenience, I think.
C++ should also enter the realm of Internet. And once it does,
it will with ease displace java and other powerhouse.
C++ is in the realm of the Internet, and it's used for a lot
more things there than Java. Server side, reliability is
usually important, for example, which means C++ (preferrably
with the Boehm collector, to avoid the security problems caused
by a lack of garbage collection), and not Java.
how about making C++ a platform neutral?
Because it isn't really appropriate. Or necessary. Most
network software is written for just a couple of machines.
That's the whole point of networking: the problem comes to you;
you don't have to go to it.
How about making faster?
Than what? C++ is, on the average, as fast as any of the other
languages out there. And pretty much all of the widespread
languages are "fast enough".
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Jul 20, 9:48 pm, izmirli <nanotu...@gmail.comwrote:
On Jul 20, 9:01 pm, george.p...@gmail.com wrote:
On Jul 20, 12:36 pm, puzzlecracker <ironsel2...@gmail.comwrote:
But threads can efficiently be used up to 4 cores. not more
cores.
According to who? We use them on a 24 core system on our
servers. There's no real upper limit.
That is threads are short term solution, not long term. I
think that 16/32/.. etc core chips will be produced soon.
Most large scale servers have been 16 or more core for quite
some years now.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
izmirli wrote:
On Jul 20, 9:01 pm, george.p...@gmail.com wrote:
>On Jul 20, 12:36 pm, puzzlecracker <ironsel2...@gmail.comwrote:
>>This is a recurring and entrenched permeating this group... hence
treat it as such
I have recently started a new job, and to my surprise, we still write
a fairly traditional c++ code, still using raw pointers, and still in
market with our products.
How popular is this scenario?
What's the future for C++, other than ceasing years of
maintainance ?
Will new standardization create new markets for c++ developers and
applications, will it expand the application domain?
C++ urgently needs support for multi-threading/tasking IMHO.
>>These are broad questions, seeking some reassurance, hope... well,
perhaps not so dramatic, but am genuinely curious what other think
about.
PuzzleCrakcer!
yes now multicore processors needs threads. and threads not standart
in C++.
Now? Multi-processor systems have been with us for as long as C++ has.
But threads can efficiently be used up to 4 cores. not more cores.
Nonsense.
That is threads
are short term solution, not long term. I think that 16/32/.. etc core
chips will be
produced soon.
SMP machines with way more processors than that have been with us for
years. Maybe not in the windows world, but common in Unix.
And a great probability, transaction memory management
as a real
solution for multicores will be used in the next time.. Tö my opinion
transaction memory management should be in C++
Once it works....
--
Ian Collins.
Roland Pibinger wrote:
Job ads nowadays often look for C/C++
skills instead of 'pure' C or C++ skills.
That's because the types who write these adverts are too ignorant to
know the difference.
On 20 Jul., 20:46, rpbg...@yahoo.com (Roland Pibinger) wrote:
{snip]
>
Will new standardization create *new markets for c++ developers and
applications, will it expand the application domain?
Nothing from the new Standard I've seen so far supports this
speculation. Quite the contrary. The C++ Standards committee seems to
have lost any contact with real-world C++ programming. They attempt to
add even more complexity to an already over-complex language.
{snip]
So what parts of the new standard are bad, and what necessary parts
were left out?
/Peter
On 20 Jul., 21:29, rpbg...@yahoo.com (Roland Pibinger) wrote:
On Sun, 20 Jul 2008 12:11:21 -0500, Sam <sam@...comwrote:
In the grand scheme of things, STL matured fairly
recently. Plenty of code still around, dating back from pre-STL days.
STL was introduced in 1995 and standardized in 1998. It came from a
single source and was usable from the beginning (although popular
compilers didn't support all STL features). Moreover, STL was
tremendously hyped for years (this is not an exaggeration as anyone
interested in C++ in the late nineties can confirm). STL's low rate of
adoption is rooted primarily in the STL, not in lazy and unwilling
programmers.
The major STL problems are obvoius by now: *
- restricion to value semantics
- template obfuscation, esp. through allocators
- non-optimal iterator design
Is this indeed so? I just don't see how having STL not being value-
based could be possible in the first place. Secondly, I do not see the
real obfuscation. How often do you need to use e.g. std::vector with
anything but the standard allocator? I have never used a standard
container with a non-standard container, and every C++ project I've
been developing has taken advantage of the standard containers - to
great benefit IMO.
/Peter
On 20 Jul., 21:58, george.p...@gmail.com wrote:
On Jul 20, 3:03 pm, puzzlecracker <ironsel2...@gmail.comwrote:
C++ urgently needs support for multi-threading/tasking IMHO.
Indeed, do you think the support for multi-threading application will
again put C++ at the top of food chain, and resume its gain in
popularity?
I don't know, but it will give it better chances for sure.
Don't forget, a plethora of libraries that support multi-threading is
already in existance, making it a language feature would be no more
that convenience, I think.
That's more of the problem: too many libraries. *Rather have one
elegant solution. *Besides how far libraries can take you. *At some
point you will need to change the language.
So why does everybody complain that there are to few standard C++
libraries? If you look at competing languages such as Java and C# you
will realise that C++ has very little library support: E.g. the Java
library is much larger.
I like the non-monopolistic approach of C++, where the standard does
not impose to much. If you want more, you get an outside source. Of
course, there is also a downside to this - one of them being the
increased effort required by programmers.
/Peter
On Jul 20, 7:36 pm, puzzlecracker <ironsel2...@gmail.comwrote:
This is a recurring and entrenched permeating this group... hence
treat it as such
I have recently started a new job, and to my surprise, we still write
a fairly traditional c++ code, still using raw pointers, and still in
market with our products.
How popular is this scenario?
What's the future for C++, other than ceasing years of
maintainance ?
I think there are quite a number of 'mainstream' and 'modern' projects
that already use C++, for example:
* Facebook has C++ backend libraries
* MySQL is written C++
* Most Mozilla stuff is written in C++, including Firefox, to my
knowledge.
Having modern projects use C++ probably means its future will not
'ceasing years of maintenance'.
I'd assume the case seems like 'ceasing years of maintenance' with
you, because the code you are maintaining uses 'traditional' C++.
Will new standardization create new markets for c++ developers and
applications, will it expand the application domain?
These are broad questions, seeking some reassurance, hope... well,
perhaps not so dramatic, but am genuinely curious what other think
about.
PuzzleCrakcer!
On Jul 20, 10:29 pm, rpbg...@yahoo.com (Roland Pibinger) wrote:
On Sun, 20 Jul 2008 12:11:21 -0500, Sam <sam@...comwrote:
In the grand scheme of things, STL matured fairly
recently. Plenty of code still around, dating back from pre-STL days.
STL was introduced in 1995 and standardized in 1998. It came from a
single source and was usable from the beginning (although popular
compilers didn't support all STL features). Moreover, STL was
tremendously hyped for years (this is not an exaggeration as anyone
interested in C++ in the late nineties can confirm). STL's low rate of
adoption is rooted primarily in the STL, not in lazy and unwilling
programmers.
The major STL problems are obvoius by now:
- restricion to value semantics
- template obfuscation, esp. through allocators
- non-optimal iterator design
New development, going forward, should use STL, and modern language
features.
I would have subscribed to this recommendation in 1998. In 2008 it is
refuted by reality.
Let's not forget that STL is implemented on top of C++'s language
features. One can implement his own replacement for STL. This is
probably one source of C++'s power.
>
--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch
puzzlecracker wrote:
The only practical use of STL to this day is to code solutions in
programming challangies (TopCoder, ACM, etc).
Does that mean eg. you don't use STL for real application code? Are
you saying the STL is useless in practice?
If the answer is affirmative, I really don't get it. I use STL *a lot*
when I code as a hobby and as my payjob. It has saved me countless hours
of development and debugging time because most of the time I don't have
to implement my own data containers nor algorithms, nor do I have to
thoroughly test them for bugs.
If I had to code in C, which has no data containers nor algorithms
whatsoever (besides the horrible qsort), that would be a real nightmare.
On Jul 20, 5:49 pm, peter koch <peter.koch.lar...@gmail.comwrote:
On 20 Jul., 21:58, george.p...@gmail.com wrote:
On Jul 20, 3:03 pm, puzzlecracker <ironsel2...@gmail.comwrote:
C++ urgently needs support for multi-threading/tasking IMHO.
Indeed, do you think the support for multi-threading application will
again put C++ at the top of food chain, and resume its gain in
popularity?
I don't know, but it will give it better chances for sure.
Don't forget, a plethora of libraries that support multi-threading is
already in existance, making it a language feature would be no more
that convenience, I think.
That's more of the problem: too many libraries. Rather have one
elegant solution. Besides how far libraries can take you. At some
point you will need to change the language.
So why does everybody complain that there are to few standard C++
libraries? If you look at competing languages such as Java and C# you
will realise that C++ has very little library support: E.g. the Java
library is much larger.
You misunderstood, my comment. I meant libraries for MT support,
otherwise STL has plenty of basic functions to work with.
I like the non-monopolistic approach of C++, where the standard does
not impose to much. If you want more, you get an outside source. Of
course, there is also a downside to this - one of them being the
increased effort required by programmers.
/Peter
On Sun, 20 Jul 2008 12:48:22 -0700, izmirli wrote:
yes now multicore processors needs threads. and threads not standart in
C++.
Really? What's wrong with pthreads?
But threads can efficiently be used up to 4 cores. not more cores.
Really? Could you please elaborate on that?
Rui Maciel
puzzlecracker <ir*********@gmail.comwrote:
I have recently started a new job, and to my surprise, we still
write a fairly traditional c++ code, still using raw pointers, and
still in market with our products.
How popular is this scenario?
What's the future for C++, other than ceasing years of
maintainance?
Will new standardization create new markets for c++ developers and
applications, will it expand the application domain?
All I have to go on is my own personal experience. When I got my first
programming job back in '98, I was genuinely concerned that my sketchy
knowledge of the STL was going to make things difficult for me. As it
turned out, my knowledge of the STL was already much greater than
anybody else in the company! I found myself routinely having to
demonstrate how the standard containers were more efficient than any
home-grown solution any of the "old guard" could come up with.
I'm working on my 10th year with the company and over the years, the STL
has fallen completely by the way-side. Principally because the owners
(both programmers themselves) learned everything they ever would about
programming long before I ever met them. The company had a vector, list
and string implementation long before the STL existed and the owners
have a severe case of NIH (Not invented here.)
Meanwhile, the company has hired a bunch of programmers fresh out of
college who learned C++ "from the ground up", i.e., they know more about
raw pointers and loops than containers and algorithms.
On top of that, the people I work with view programming as a job, a
means to an end, not a passion or hobby, so their willingness to learn
something more than they already know is practically nonexistent.
.... Before I start sounding "holier than thou" I have to say, I learned
C++ when the STL was touted as the best thing since sliced bread, I
spent a lot of time learning how to use the functional library and
building up my own library of adaptors and predicates. Now, I hear that
boost's lambda library is going to become part of the standard but
frankly I doubt I will ever learn it (or any of the other new parts of
the standard) as well as I know the STL.
On Jul 20, 7:00 pm, Juha Nieminen <nos...@thanks.invalidwrote:
puzzlecracker wrote:
The only practical use of STL to this day is to code solutions in
programming challangies (TopCoder, ACM, etc).
Does that mean eg. you don't use STL for real application code? Are
you saying the STL is useless in practice?
If the answer is affirmative, I really don't get it. I use STL *a lot*
when I code as a hobby and as my payjob. It has saved me countless hours
of development and debugging time because most of the time I don't have
to implement my own data containers nor algorithms, nor do I have to
thoroughly test them for bugs.
If I had to code in C, which has no data containers nor algorithms
whatsoever (besides the horrible qsort), that would be a real nightmare.
I don't mean to downplay the the usefulness of STL, by no means. We do
use it in our company. However, a lot of times we develop data
structures bases off STL, and use our own utilities where speed is the
factor, despite the certain guarantees it makes.
I personally love STL and use it for fun...
Again, by no means I have anything against STL... (maybe gtk :) )
Now, I hear that
boost's lambda library is going to become part of the standard but
frankly I doubt I will ever learn it (or any of the other new parts of
the standard) as well as I know the STL.
Why not, just curious?
I have very scantly touched Boost as well as other new libraries that
have a chance of becoming a
part of the new standard though I do want find some time for that...
puzzlecracker <ir*********@gmail.comwrote:
Now, I hear that boost's lambda library is going to become part
of the standard but frankly I doubt I will ever learn it (or any
of the other new parts of the standard) as well as I know the STL.
Why not, just curious?
Like I said, where I work the STL is considered advanced practice, I
already know stuff about the language I can't use because then no one
else will be able to work with my code. Why should I learn even more?
I have very scantly touched Boost as well as other new libraries
that have a chance of becoming a part of the new standard though I
do want find some time for that...
Oh I want to as well, and I probably will in hobby code, but that is a
very small percentage of the code I write every day.
BTW, to answer the question posed in the subject... Yes, of course C++
is dying. Everything dies.
Juha Nieminen <no****@thanks.invalidwrote:
puzzlecracker wrote:
The only practical use of STL to this day is to code solutions in
programming challangies (TopCoder, ACM, etc).
Does that mean eg. you don't use STL for real application code? Are
you saying the STL is useless in practice?
If the answer is affirmative, I really don't get it. I use STL *a lot*
when I code as a hobby and as my payjob. It has saved me countless hours
of development and debugging time because most of the time I don't have
to implement my own data containers nor algorithms, nor do I have to
thoroughly test them for bugs.
If I had to code in C, which has no data containers nor algorithms
whatsoever (besides the horrible qsort), that would be a real nightmare.
Nonsense. You would do the same thing every programming house did before
the STL came along, develop your own set of containers and algorithms
and use them. Then when someone asked why you don't switch from what you
know to this "new improved" library, you would look at all the code you
already have written, all the evidence that your containers work and
work well, and ask "why bother?"
A lot of C++ engines, frameworks and libraries were developed long
before STL burst on the scene and they solved all the problems STL
solves. Why should they dump all that hard work, that works?
Programming languages have a nasty habit of starting life clean and well
designed but with a few quirks and lacking in some way, then they grow
to become bloated beasts that have way more than they need and even more
quirks because of the requirement that they are backwards compatible.
Eventually they die under their own weight. Either that, or the language
stagnates and eventually becomes minor niche.
C++ seems to be in the unenviable position of officially bloating while
practically stagnating.
On Jul 21, 4:40 am, "Daniel T." <danie...@earthlink.netwrote:
Juha Nieminen <nos...@thanks.invalidwrote:
puzzlecracker wrote:
[...]
If I had to code in C, which has no data containers nor
algorithms whatsoever (besides the horrible qsort), that
would be a real nightmare.
Nonsense. You would do the same thing every programming house
did before the STL came along, develop your own set of
containers and algorithms and use them. Then when someone
asked why you don't switch from what you know to this "new
improved" library, you would look at all the code you already
have written, all the evidence that your containers work and
work well, and ask "why bother?"
To which you answer: because it's standard. I've used many
different pre-standard libraries, most of them better designed
than the STL (but some real desasters in design, too). But none
of them as well known as the STL: I'm concerned with my code
being easily understood not only by the veterans who've worked
at the company for years, but by the new kids we hire next week.
For most purposes, the my GB_ArrayOf, OSE's OTC_Vector and the
standard's std::vector will work equally well, but the new hire
will already know std::vector, but not GB_ArrayOf or OTC_Vector.
(Not to mention that a lot of places where I've worked bought in
libraries like the Booch toolkit, which are no longer
supported.)
A lot of C++ engines, frameworks and libraries were developed
long before STL burst on the scene and they solved all the
problems STL solves. Why should they dump all that hard work,
that works?
So that they can interface with other engines, frameworks and
libraries. And so that there is one less thing for new hires to
learn.
Programming languages have a nasty habit of starting life
clean and well designed but with a few quirks and lacking in
some way, then they grow to become bloated beasts that have
way more than they need and even more quirks because of the
requirement that they are backwards compatible. Eventually
they die under their own weight. Either that, or the language
stagnates and eventually becomes minor niche.
C++ seems to be in the unenviable position of officially
bloating while practically stagnating.
I don't follow you here. Java came along, and pretended to
replace C++, and now it's more or less relegated to a few (very
big) niches, where as C++ continues to be widely used in a large
number of domains. Ditto a few other languages. C++ has a
number of flaws, but it is flexible, and can be adapted to meet
just about any requirements.
It is complex. For two reasons: the first is that it is used to
solve complex problems: if the complexity wasn't in the
language, it would have to be in your user code. The second is
that it derives from C, and there are a number of things in C
which are poorly designed and don't scale (e.g. the declaration
syntax). But without this relationship to C, it's probable that
the language would have followed the tracks of Modula-3: an
excellent language that just never caught on.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Jul 20, 11:43 pm, peter koch <peter.koch.lar...@gmail.comwrote:
On 20 Jul., 21:29, rpbg...@yahoo.com (Roland Pibinger) wrote:
On Sun, 20 Jul 2008 12:11:21 -0500, Sam <sam@...comwrote:
>In the grand scheme of things, STL matured fairly recently.
>Plenty of code still around, dating back from pre-STL days.
STL was introduced in 1995 and standardized in 1998. It came
from a single source and was usable from the beginning
(although popular compilers didn't support all STL
features). Moreover, STL was tremendously hyped for years
(this is not an exaggeration as anyone interested in C++ in
the late nineties can confirm). STL's low rate of adoption
is rooted primarily in the STL, not in lazy and unwilling
programmers.
The major STL problems are obvoius by now:
- restricion to value semantics
- template obfuscation, esp. through allocators
- non-optimal iterator design
Is this indeed so? I just don't see how having STL not being
value-based could be possible in the first place.
The STL is value-based because C++ is value-based. It would be
trivial to design the library otherwise, but such designs don't
"fit in" with the rest of the language. Many early libraries,
back before there were templates, did have containers of
Object*, and require everything in the containers to derive from
Object. It didn't work, and even back then, it was found
preferrable to use <generic.h>, with all its horrors, than to go
the route of reference semantics. There are (or have been) many
libraries better designed than STL, but they've all used value
semantics as well.
Secondly, I do not see the real obfuscation. How often do you
need to use e.g. std::vector with anything but the standard
allocator?
I agree that the best thing to do with the allocator argument is
to forget it. I does come into play if you try to use some of
the more advanced features of C++, however, like template
template parameters.
With regards to the third point, the iterator design of the STL
is a desaster, but most of the time, you can make it work
anyway.
I have never used a standard container with a non-standard
container, and every C++ project I've been developing has
taken advantage of the standard containers - to great benefit
IMO.
Having something standard is always a benefit. Often enough of
one to outweigh certain technical disadvantages.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Jul 21, 12:13 am, Rui Maciel <rui.mac...@gmail.comwrote:
On Sun, 20 Jul 2008 12:48:22 -0700, izmirli wrote:
yes now multicore processors needs threads. and threads not
standart in C++.
Really? What's wrong with pthreads?
They don't work under Windows:-).
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Jul 20, 10:24 pm, Matthias Buelow <m...@incubus.dewrote:
Roland Pibinger wrote:
Job ads nowadays often look for C/C++
skills instead of 'pure' C or C++ skills.
That's because the types who write these adverts are too
ignorant to know the difference.
Sometimes. Sometimes it's because some maintenance programming
is required.
Most of the time, though, the job offer specifies clearly C++,
and doesn't mention C.
I'd say that C++/Java or C++/C# is more in demand than C++/C.
It's not rare to have light-weight clients written in C#, or for
the front end of the web server to make use of Java Beans, while
all of the real work is done in C++. IMHO, it's a good model
(although I'd use Java for the clients as well, rather than C#).
You get the advantage of a good, standard GUI library for the
client code, and the infrastructure of your Web server to
support the development of the beans, but the programmer
productivity and the program robustness of C++ where it counts,
where the critical work is being done.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Jul 21, 4:24 am, "Daniel T." <danie...@earthlink.netwrote:
puzzlecracker <ironsel2...@gmail.comwrote:
BTW, to answer the question posed in the subject... Yes, of
course C++ is dying. Everything dies.
That's true for organic beings, but I don't know about computer
languages. Both Fortran and Cobol are alive and thriving.
Part of the question could also be: what does it mean for a
language to die? Is it just the name---would C++ die if we
decided to rename it SomethingElse? Or is it the language
itself: but the language I learned twenty years ago under the
name C++ doesn't exist anymore (no <generic.h>, for example:-)).
One thing is certain, a language that doesn't evolve and change
will find its user community shrinking rapidly. If Fortran and
Cobol (and C++) are alive and thriving, it's because the
language today would be largely unrecognizable to someone who
learned it back when it was first conceived. (Which leads to an
interesting correlary: any language which continues to thrive
for more than twenty years will end up overly complicated. It's
the price you pay for longevity.)
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze <ja*********@gmail.comwrote:
"Daniel T." <danie...@earthlink.netwrote:
Juha Nieminen <nos...@thanks.invalidwrote:
puzzlecracker wrote:
If I had to code in C, which has no data containers nor
algorithms whatsoever (besides the horrible qsort), that
would be a real nightmare.
Nonsense. You would do the same thing every programming house
did before the STL came along, develop your own set of
containers and algorithms and use them. Then when someone
asked why you don't switch from what you know to this "new
improved" library, you would look at all the code you already
have written, all the evidence that your containers work and
work well, and ask "why bother?"
To which you answer: because it's standard. I've used many
different pre-standard libraries, most of them better designed
than the STL (but some real desasters in design, too). But none
of them as well known as the STL: I'm concerned with my code
being easily understood not only by the veterans who've worked
at the company for years, but by the new kids we hire next week.
For most purposes, the my GB_ArrayOf, OSE's OTC_Vector and the
standard's std::vector will work equally well, but the new hire
will already know std::vector, but not GB_ArrayOf or OTC_Vector.
(Not to mention that a lot of places where I've worked bought in
libraries like the Booch toolkit, which are no longer
supported.)
The new kids we hired (about 20 in the last 3 months) don't know the
STL, so your reasoning is quite speacious. Most people learning C++
still learn "from the ground up", they have barely touched on the
standard containers and algorithms (if at all,) and routinely use raw
pointers and loops, because that was what they learned in school.
Programming languages have a nasty habit of starting life
clean and well designed but with a few quirks and lacking in
some way, then they grow to become bloated beasts that have
way more than they need and even more quirks because of the
requirement that they are backwards compatible. Eventually
they die under their own weight. Either that, or the language
stagnates and eventually becomes minor niche.
C++ seems to be in the unenviable position of officially
bloating while practically stagnating.
I don't follow you here.
I'll spell it out, C++ (indeed any language that has been growing for a
while) has a bunch of "standard features" that people don't use, and
more is being added, while it also has a bunch of "warts" that people
have to use.
Please understand, I love the language and know it well, but I find that
isn't the case for most users of it.
Subject: "C++...is it dying"
On 20 Jul, 23:48, khalid...@gmail.com wrote:
On Jul 20, 7:36 pm, puzzlecracker <ironsel2...@gmail.comwrote:
Tis is a recurring and entrenched permeating *this group... hence
treat it as such
*what* is "recurring [,] entrenched [and] permeating this group"?
The idea that C++ is dying?
I have recently started a new job, and to my surprise, we still write
a fairly traditional c++ code, still using raw pointers, and still in
market with our products.
wow. Linux is still in the market and *that's* written in C!!!!
How popular is this scenario?
What's the future for C++, other than ceasing *years of
maintainance ?
what does "ceasing years of maintainance" mean? Increasing?
Unceasing? Is it really bad to maintain a softwatr product?
Doesn't it mean your customer base is still interested in your
product?
I think there are quite a number of 'mainstream' and 'modern' projects
that already use C++, for example:
* Facebook has C++ backend libraries
* MySQL is written C++
* Most Mozilla stuff is written in C++, including Firefox, to my
knowledge.
Having modern projects use C++ probably means its future will not
'ceasing years of maintenance'.
what? Do you mean using C++ means you won't have bugs in your product?
Or no one will use your product (no maintenance implies (to me)
no customers)? Or do you *you* won't be stuck on maintenance if you
write new projects in C++?
I'd assume the case seems like 'ceasing years of maintenance' with
you, because the code you are maintaining uses 'traditional' C++.
you'll have to explain that to me
Will new standardization create *new markets for c++ developers and
applications, will it expand the application domain?
These are broad questions, seeking some reassurance, hope... well,
perhaps not so dramatic, but am genuinely curious what other think
about.
I think you have a negative attitude to products with long life
cycles. Imagine all those Oracle programmers "oh no! we've got
to work on that old DBMS system"
--
Nick Keighley
Daniel T. wrote:
> If I had to code in C, which has no data containers nor algorithms
whatsoever (besides the horrible qsort), that would be a real nightmare.
Nonsense. You would do the same thing every programming house did before
the STL came along, develop your own set of containers and algorithms
and use them.
In other words, spend countless of hours developing and debugging data
containers and algorithms (and often not even catching all bugs until
during the years), for no good reason. Hours which could be used more
productively.
Then when someone asked why you don't switch from what you
know to this "new improved" library, you would look at all the code you
already have written, all the evidence that your containers work and
work well, and ask "why bother?"
If someone is starting a new project from scratch, why should he not
use what the STL has to offer? There's no "switch" to anything.
A lot of C++ engines, frameworks and libraries were developed long
before STL burst on the scene and they solved all the problems STL
solves. Why should they dump all that hard work, that works?
Why shouldn't a new C++ engine, framework or library use the STL?
On Sun, 20 Jul 2008 14:43:06 -0700 (PDT), peter koch wrote:
>I just don't see how having STL not being value-
based could be possible in the first place.
Just take a look at the libraries from Rogue Wave or Qt.
>Secondly, I do not see the
real obfuscation. How often do you need to use e.g. std::vector with
anything but the standard allocator?
The STL allocators literally multiply the length of compiler error
messages. Moreover, you don't need user-defined allocators when the
library merely uses value semantics (values and copies of values).
Even if there were a need for allocators they wouldn't have to be
template parameters.
--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch
On Jul 21, 1:46 pm, "Daniel T." <danie...@earthlink.netwrote:
James Kanze <james.ka...@gmail.comwrote:
"Daniel T." <danie...@earthlink.netwrote:
Juha Nieminen <nos...@thanks.invalidwrote:
puzzlecracker wrote:
If I had to code in C, which has no data containers nor
algorithms whatsoever (besides the horrible qsort), that
would be a real nightmare.
Nonsense. You would do the same thing every programming house
did before the STL came along, develop your own set of
containers and algorithms and use them. Then when someone
asked why you don't switch from what you know to this "new
improved" library, you would look at all the code you already
have written, all the evidence that your containers work and
work well, and ask "why bother?"
To which you answer: because it's standard. I've used many
different pre-standard libraries, most of them better designed
than the STL (but some real desasters in design, too). But none
of them as well known as the STL: I'm concerned with my code
being easily understood not only by the veterans who've worked
at the company for years, but by the new kids we hire next week.
For most purposes, the my GB_ArrayOf, OSE's OTC_Vector and the
standard's std::vector will work equally well, but the new hire
will already know std::vector, but not GB_ArrayOf or OTC_Vector.
(Not to mention that a lot of places where I've worked bought in
libraries like the Booch toolkit, which are no longer
supported.)
The new kids we hired (about 20 in the last 3 months) don't
know the STL, so your reasoning is quite speacious.
I know. It's a problem. I once had a candidate who didn't know
the meaning of virtual. There are a lot of Basic or C
programmers out there who claim C++, because it is what the
market is asking for.
That's why you vet candidates, and don't take their CV too
literally until you've actually talked to them.
Most people learning C++ still learn "from the ground up",
they have barely touched on the standard containers and
algorithms (if at all,) and routinely use raw pointers and
loops, because that was what they learned in school.
What school? There are some professors who are out of date, but
on the whole, the situation is no where near as bad as you seem
to indicate.
I've seen a lot more of the opposite: the people coming out of
school are all eager to show what they've learned, and throw in
template metaprogramming and who knows what all else, when all
that is needed is a simple for loop.
Programming languages have a nasty habit of starting life
clean and well designed but with a few quirks and lacking in
some way, then they grow to become bloated beasts that have
way more than they need and even more quirks because of the
requirement that they are backwards compatible. Eventually
they die under their own weight. Either that, or the language
stagnates and eventually becomes minor niche.
C++ seems to be in the unenviable position of officially
bloating while practically stagnating.
I don't follow you here.
I'll spell it out, C++ (indeed any language that has been
growing for a while) has a bunch of "standard features" that
people don't use, and more is being added, while it also has a
bunch of "warts" that people have to use.
As you say, that's a penalty which comes with being mature. C++
certainly can't be accused of being overly simple or to
abstractly elegant. In the case of C++, in addition, the
language tries (and largely succeeds) in being usable for
everything. But it's clear that the features you need to
implement an OS kernel or a low level library (like the standard
library) aren't generally of much use in application code. And
vice versa.
Please understand, I love the language and know it well, but I
find that isn't the case for most users of it.
The problem I sometimes find is that while the older users and
the youngers both know the language well, and love it, it's not
always the same language they know and love. (The other problem
I find is that most practitionners seem to go to extremes. It's
either STL and TMP everywhere, or no where. You need balance:
my job as an applications programmer isn't to stress test the
compilers, but you also do have to evolve.)
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Jul 21, 7:59 pm, rpbg...@yahoo.com (Roland Pibinger) wrote:
On Sun, 20 Jul 2008 14:43:06 -0700 (PDT), peter koch wrote:
I just don't see how having STL not being value-
based could be possible in the first place.
Just take a look at the libraries from Rogue Wave or Qt.
Experience with the early Rogue Wave libraries is *why* people
felt that value semantics were so important. (To its credit,
Rogue Wave moved over to supporting value semantics very
quickly, too.)
Secondly, I do not see the real obfuscation. How often do you
need to use e.g. std::vector with anything but the standard
allocator?
The STL allocators literally multiply the length of compiler error
messages.
Which may be indicative that there could be some improvement in
compilers, particularly when it comes to generating error
messages.
Moreover, you don't need user-defined allocators when the
library merely uses value semantics (values and copies of
values). Even if there were a need for allocators they
wouldn't have to be template parameters.
Allocators are a misfeature. IIUC, Stepanov introduced them to
support different pointer models (small, medium, large, etc.).
Why they lived on after this need died, I can't fathom myself.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Mon, 21 Jul 2008 12:20:12 -0700 (PDT), James Kanze wrote:
>On Jul 21, 7:59 pm, rpbg...@yahoo.com (Roland Pibinger) wrote:
>Just take a look at the libraries from Rogue Wave or Qt.
Experience with the early Rogue Wave libraries is *why* people
felt that value semantics were so important. (To its credit,
Rogue Wave moved over to supporting value semantics very
quickly, too.)
I don't know which 'early' versions you are referring. From a
pragmatic point of view Rogue Wave libraries, esp. (formerly known as)
Tools.h++ and DbTools.h++ are the best C++ libraries I've seen so far.
Stepanov's use of 'value semantics' is the same as in functional
programming languages. It means stateless programming without
references and pointers (the only permitted 'pointers' for STL
programming are the iterators).
>The STL allocators literally multiply the length of compiler error
messages.
Which may be indicative that there could be some improvement in
compilers, particularly when it comes to generating error
messages.
Compiler error messages have not improvend since the mid 90ies. They
are pimarily determined by the nature of templates as code generators.
>Moreover, you don't need user-defined allocators when the
library merely uses value semantics (values and copies of
values). Even if there were a need for allocators they
wouldn't have to be template parameters.
Allocators are a misfeature. , Stepanov introduced them to
support different pointer models (small, medium, large, etc.).
Why they lived on after this need died, I can't fathom myself.
AFAIK, allocators were not part of the original STL. According to this
paper Stroustrup introduced them into STL: www.research.att.com/~bs/DnE2005.pdf
--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch
On Jul 21, 11:46 pm, "Daniel T." <danie...@earthlink.netwrote:
>
The new kids we hired (about 20 in the last 3 months) don't know the
STL, so your reasoning is quite speacious. Most people learning C++
still learn "from the ground up", they have barely touched on the
standard containers and algorithms (if at all,) and routinely use raw
pointers and loops, because that was what they learned in school.
Then they aren't C++ programmers.
No one who lacks an understanding of a core component of the language
can calim to be a C++ (or any other language) programmer. The stadard
library is at the core of the language.
Ian.
Juha Nieminen <no****@thanks.invalidwrote:
Daniel T. wrote:
Then when someone asked why you don't switch from what you
know to this "new improved" library, you would look at all the code you
already have written, all the evidence that your containers work and
work well, and ask "why bother?"
If someone is starting a new project from scratch, why should he not
use what the STL has to offer? There's no "switch" to anything.
A lot of C++ engines, frameworks and libraries were developed long
before STL burst on the scene and they solved all the problems STL
solves. Why should they dump all that hard work, that works?
Why shouldn't a new C++ engine, framework or library use the STL?
Why build a new one when we already have one that works quite well, and
has already been ported to five different architectures? Why would
someone start a new project from scratch and not take advantage of any
of the libraries in existence (many of which *don't* use the STL because
they are older than the STL?)
Why use STL constructs when a majority of the programmers in the
software house don't know them? Talk about maintenance nightmare!
I like the STL and I think that many of the solutions it embodies are
better than the ones my company uses, but why should I write code that
only I understand? Why should I have to deal with the extra complexity
of converting from STL classes to the in-house classes and back again? ia******@hotmail.com wrote:
On Jul 21, 11:46 pm, "Daniel T." <danie...@earthlink.netwrote:
The new kids we hired (about 20 in the last 3 months) don't know the
STL, so your reasoning is quite speacious. Most people learning C++
still learn "from the ground up", they have barely touched on the
standard containers and algorithms (if at all,) and routinely use raw
pointers and loops, because that was what they learned in school.
Then they aren't C++ programmers.
No one who lacks an understanding of a core component of the language
can calim to be a C++ (or any other language) programmer. The stadard
library is at the core of the language.
Thank you for answering James Kanze's question about when a language is
dead.
If only software written with the STL as a core component is "C++
software" then I expect the popularity of the language is far smaller
than the raw numbers let on.
On Jul 22, 11:06 am, "Daniel T." <danie...@earthlink.netwrote:
ian-n...@hotmail.com wrote:
On Jul 21, 11:46 pm, "Daniel T." <danie...@earthlink.netwrote:
The new kids we hired (about 20 in the last 3 months) don't know the
STL, so your reasoning is quite speacious. Most people learning C++
still learn "from the ground up", they have barely touched on the
standard containers and algorithms (if at all,) and routinely use raw
pointers and loops, because that was what they learned in school.
Then they aren't C++ programmers.
No one who lacks an understanding of a core component of the language
can calim to be a C++ (or any other language) programmer. The stadard
library is at the core of the language.
Thank you for answering James Kanze's question about when a language is
dead.
If only software written with the STL as a core component is "C++
software" then I expect the popularity of the language is far smaller
than the raw numbers let on.
That is not what I said.
One can write C++ code using whatever subset of the language one
chooses. Anyone claiming to be programmer in any language should be
familiar with that language's core libraries. The C++ standard
library is over half of the language standard, or any decent textbook.
Ian.
On Jul 22, 11:04 am, "Daniel T." <danie...@earthlink.netwrote:
Juha Nieminen <nos...@thanks.invalidwrote:orks?
Why shouldn't a new C++ engine, framework or library use the STL?
Why build a new one when we already have one that works quite well, and
has already been ported to five different architectures? Why would
someone start a new project from scratch and not take advantage of any
of the libraries in existence (many of which *don't* use the STL because
they are older than the STL?)
Why use electricity when we have gas lamps?
What happens when you have to use a new compiler or platform where
your libraries don't build? If you use the standard libraries,
porting is someone else's problem.
Why use STL constructs when a majority of the programmers in the
software house don't know them? Talk about maintenance nightmare!
Time to book some training. It sounds like your staff are going
stales.
I like the STL and I think that many of the solutions it embodies are
better than the ones my company uses, but why should I write code that
only I understand? Why should I have to deal with the extra complexity
of converting from STL classes to the in-house classes and back again?
Try pairing and collective code ownership for a while, your team's
skills will improve considerably.
Ian
"puzzlecracker" blew my mind thusly:
The only practical use of STL to this day is to code
solutions in programming challangies (TopCoder, ACM,
etc).
Hardly. Only people who have never tried STL talk like
that.
At my last job, our primary software product contained
maps of structs which contained deques of structs. Try
implimenting THAT with C-style C++! You could do it,
but it would take you a very long time, and you'd end
up just reimplimenting the STL, badly. Complete waste
of time! It's already written. Why not just use it?
--
Cheers,
Robbie Hatley
lonewolf aatt well dott com
www dott well dott com slant user slant lonewolf slant This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: lawrence |
last post by:
Right now, over at www.monkeyclaus.org, the following script is
getting to the 9th run through and dying after the line:
echo "...";
You'll admit that is a strange place to die. I've hit...
|
by: Steve |
last post by:
I tried to run a simple script today on my PC (WinXP, PHP5, MySQL
4.0.17) that I haven't run for about a year, and for some reason it's
dying at an include() statement that used to work fine. I...
|
by: diggum |
last post by:
Hi,
We've been troubleshooting a connection problem with a client of ours
for several weeks. Basically, a combination of network stuff appears
to be causing the VM to freeze, or at least just...
|
by: jdh2358 |
last post by:
I have a python file that is trying to read raw data from a raw
partition on a dying dist, eg
f = file('/dev/sda')
f.seek(SOMEWHERE)
s = f.read(SOMEBYTES)
On some blocks, the read succeeds,...
|
by: Dave Rudolf |
last post by:
Hi all.
I have a multithreaded little app that I am writing. Periodically, I see
messages on my console that read:
The thread '<No Name>' (0xa7c) has exited with code 0 (0x0).
|
by: zee |
last post by:
Hi,
I remember when i first went to school and got my copy of "oh Pascal" and
thought it was a great language. What seemed like a lifetime later. It was
then C closely followed by C++ as I...
|
by: ML |
last post by:
I have recently been looking on dice.com (and other sites) and noticed
a striking difference in the number of listings for DB2 DBAs for the
OS390 platform. Most of the listings are AIX.
Anyone...
|
by: Linny |
last post by:
Hi,
Came across this article in the ComputerWorld website which has
included C in the top ten dying languages.
The top 10 dead (or dying) computer skills...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
