J
James Kanze
[...]
There is. At least in my book, it's called fraud if it's
intentional, and incompetence otherwise.
[...]
There is. At least in my book, it's called fraud if it's
intentional, and incompetence otherwise.
A
Alf P. Steinbach
* James Kanze:
There is the question of whose fraud and incompetence, though.
Cheers,
- Alf
There is the question of whose fraud and incompetence, though.
Cheers,
- Alf
T
Tony
"One of the main STL advantages is that it's part of the C++ standard"
I see that as a detriment, not an advantage.
Tony
I see that as a detriment, not an advantage.
Tony
T
Tony
"I take it by efficiency you mean programmer efficiency."
Noooooo. I meant the space vs. time tradeoff.
Tony
T
Tony
"It's the most important kind."
No, that's entirely wrong. JK is "assuming" that because some language or OS
or whatever has longevity, it has merit. And that is not so at all. Let's
make it less "light": "hey, if you do this, your kids will live and we won't
break your legs". (Was that it?).
"But in this case, I was
responding somewhat humorously---the original poster asked for
the disadvantages of the STL, so I suggested that one might be
that it increases programmer efficiency (and thus reduces the
length of the contract)."
In your contrived world. (I was raised by catholics, don't **** with me).
"Yes. On the other hand, I've seen a couple of cases in my
career where a software company or a consultant has
(intentionally?) written code that no one else could understand,
and then lived of over priced maintenance contracts for the rest
of the programs lifetime.'
Of course that is the goal of C++ gurus: to be god! "standard library": I'm
not buying it. Language lock-in: I'm not buying it.
(Aside to BS: You were wrong... you were an old senile man when you invented
the language.
).Tony
T
Tony
[...]
"There is. At least in my book, it's called fraud if it's
intentional, and incompetence otherwise."
You're apparently quick to that. It is indicative. Was that vulturous? Hey
JK, curb it. You said "job security". Apparently it should be retroactively
revoked!
Tony
T
Tony
Noah Roberts said:
Oh, surely that is correct. "I beg your pardon, I'm so wrong with my life
that a sentence from you obliterates my very existence".
Cliches are like assholes.
J
Juha Nieminen
Tony said:
Yes, sure. We should all go back to C which doesn't offer any standard
library utilities whatsoever (except for a few horrid string functions).
This way we will be forced to create our own data containers from
scratch even for the smallest projects and spend hours and hours
bug-hunting and optimizing. This will allow us to create better-quality,
more maintainable software faster and better.
C
coal
Tony, I'd appreciate it if you would watch your language here.
O
The STL is still decent. The Boost Intrusive library is
better than the STL in a number of ways and I expect it's
use will increase. I'm impressed recently by it's option
of a non constant-time size function. In the sort of code
I write, the use of size() is rare and not having to pay
for the field or increment/decrement it frequently makes
sense. Kudos to the Boost Intrusive library authors.
(Aside to BS: You were wrong... you were an old senile man when you invented
the language.
I met Bjarne long after he invented the language and he
wasn't a senile man at that time. He was a friendly and
thoughtful host. Meanwhile, back at the ranch, gcc is
being developed in C as of March 27, 2009. That's where
we may find some senility. People who always do things
the same way are at greater risk of Alzheimer's than
those who change things up from time to time.
Brian Wood
Ebenezer Enterprises
www.webEbenezer.net
C
coal
Yes, it's a form of fraud. I would like a more colorful
term for it when it's not due to incompetence. "Code
Lawyer" would be a start. I'm thinking of the twister-
of-words aspect that describes a lot of lawyers.
Brian Wood
Ebenezer Enterprises
www.webEbenezer.net
S
SG
Hello Tony,
it seems you don't have a lot to contribute to this (or any?)
discussion. I went through the trouble of reading all your posts in
this thread and the thread "C++ is complicated" again and the only
things that have stuck are:
* STL is supposedly complicated. It's more complicated
than your container library.
* You don't accept the STL being part of the C++ standard
library as an advantage even though obvious arguments
for this position have been mentioned.
* You prefer some "void*-based" container design (whatever
that means)
* You said that the STL's performance advantage "probably
doesn't matter".
This goes along with a lack of arguments and accusations à la
"Propaganda!", "You're a marketeer", "Bitch.", etc.
Nicely done, Tony.
-SG
N
Noah Roberts
SG said:
hehehehe, and here I was just going to say "*plonk*"
C
Christof Donat
Hi,
Well. actually I've been doing quite some Java coding during the last year.
I still think of the STL to be easier to use. The Java Containers have some
flaws I feel unesy with. See below for one example.
It has not been fixed. You still can write Java Code like this:
List<String> l1 = new ArrayList<String>
List l2 = l1;
List<Integer> l3 = l2;
You will get a compiler warning that you can swith off, but not an error. If
you run this code, put a String in l1 and try to take it out as Integer from
l3 you will get a ClassCastException at the point where you try to take out
the Integer.
Java generics are just a compiler feature. At runtime a container has no
information about the Elements it can hold. That ist the reason why the
ClassCastException can only be thrown when you try to access an element from
the container, not at the point when the container istself is casted which
actually is the error in this code.
Christof
Well. actually I've been doing quite some Java coding during the last year.
I still think of the STL to be easier to use. The Java Containers have some
flaws I feel unesy with. See below for one example.
It has not been fixed. You still can write Java Code like this:
List<String> l1 = new ArrayList<String>
List l2 = l1;
List<Integer> l3 = l2;
You will get a compiler warning that you can swith off, but not an error. If
you run this code, put a String in l1 and try to take it out as Integer from
l3 you will get a ClassCastException at the point where you try to take out
the Integer.
Java generics are just a compiler feature. At runtime a container has no
information about the Elements it can hold. That ist the reason why the
ClassCastException can only be thrown when you try to access an element from
the container, not at the point when the container istself is casted which
actually is the error in this code.
Christof
B
Bo Schwarzstein
In fact, the only disadvantage of STL is that I need DMA, get out the
data directly to feed the OpenGL. But in most times I have to allocate
another memory then "copy".
T
Tony
Juha Nieminen said:
When you reference C as if it was the only other alternative to C++, I
automatically think: propaganda. Does C++ need a marketeering team these
days?
OK, you're being propogandist or you are just not very smart (is there
another option?). So you create a replacement container on one project.
Evolve it on the next. Confidence builds and you decide to implement a
number of containers. These evolve over time. THEN, you have a replacement
or potential replacement for the "do everything for everyone" std library.
That you took my thought to the extreme of "build containers from scratch on
every project" is quite annoying (though you are forgiven if indeed you are
just not very smart).
Tony
T
Tony
Jeff Schwab said:
Do you know what a camel is? (And no, that's not the only reason).
Tony
T
Tony
Tony, I'd appreciate it if you would watch your language here.
O
"The STL is still decent."
What I think is the major value of STL: "exposing" the algorithms and
designs. All else is just syntax, and I consider the syntax bad.
(Aside to BS: You were wrong... you were an old senile man when you
invented
the language.
"I met Bjarne long after he invented the language and he
wasn't a senile man at that time. He was a friendly and
thoughtful host. Meanwhile, back at the ranch, gcc is
being developed in C as of March 27, 2009. That's where
we may find some senility. People who always do things
the same way are at greater risk of Alzheimer's than
those who change things up from time to time."
Dude, when I put in a wink, I mean it! I have nothing but respect for B.S.
His books are on my shelves 10 years (has it been more?) after he wrote
them, and I still refer to them. What I wonder though, is what kind of group
it is that actually creates such tomes. I can't imagine the writing being of
just one individual. Maybe guided and edited by an individual.
Tony
T
Tony
Yannick Tremblay said:
Noted. My purpose is to verify my designs and architectures.
Your opinion noted. But it is an invalid (or worse) thing to say without a
given frame of reference: namely, in what time period? Because I can buy
high-dollar C++ programmers + a required guru who know the std library that
is better than tooling up to avoid that scenario? I need to see 2 or 3
alternatives or I know something is rotten in Denmark.
[snipped invalid-assumption based stuff]
Tony
T
Tony
"Hello Tony,"
No need to be formal (seesh).
"it seems you don't have a lot to contribute to this (or any?)
discussion."
Give to receive. (Or is that too a cliche?).
" I went through the trouble of reading all your posts in
this thread and the thread "C++ is complicated" again and the only
things that have stuck are:"
("only", as if you are omniscient).
"* STL is supposedly complicated."
I said "obfuscated", didn't I?
" It's more complicated than your container library."
From an implementation standpoint, yes. (You're not talking about design
outside of the language/syntax domain are you?) Think about it this way: why
would I have created and evolved something else if I thought STL was "the
bomb"?
"* You don't accept the STL being part of the C++ standard
library as an advantage"
Oh, so it's an "acceptance" thing huh. Like Catholicism! (Been there, didn't
do that).
" even though obvious arguments for this position have been mentioned."
I "steal" the STL algorithms (well a few or some, my patterns work).
Apparently, any "obvious arguments" have not been retained in my mind so
please be so kind as to reiterate them in response here. (The way my mind
works: I evaluate and after I do, it either stays in my mind as
useful/relevant or goes to the trash bin. Nothing apparently has been said
that I didn't hear a dozen years ago).
"* You prefer some "void*-based" container design (whatever
that means)"
I think I corrected the person that said that such a design is not type
safe. Look at it from my perspective: every time I hear such stuff, I wonder
if they indeed don't know or if they are propagandizing/marketeering. I have
no way of knowing!
"* You said that the STL's performance advantage "probably
doesn't matter"."
In many instances, even container choice makes little difference.
Personally, I use a container that fits the problem even if "a simple array"
could do it more efficiently a lot of times. If I was developing genome
programs or such, I would probably choose the highest performing beast
available: STL (template-based gives high perf). I think that the concept of
one library that would span the needs of a programmer that needs to develop
utility programs in adjunct to network/system administration, to the
scientific programmer, a non-practical idea. Rogue-Wave and Borland both
went to "enterprise development". Did they "cave in" because of the C++ std
library? I know how companies evolve. And when the substance walks out the
door (and gets "let go"), the company stagnates to a period of
inter-management boom ("enterprise" sounds kinda fitting huh?).
You're a bit behind the current times though apparently: you are saying that
if one uses C++, then the std C++ library is the way to go. I don't think
C++ is the way to go and haven't for quite awhile. It has been a great
learning experience, but times have changed.
"This goes along with a lack of arguments and accusations à la
"Propaganda!", "You're a marketeer", "Bitch.", etc."
Now you know "the rest of the story". Still feel the same?
Tony
C
coal
You remind me of "Le Chaud Lapin" on comp.lang.c++.moderated. He
goes on and on about his code, but doesn't ever publish it. I asked
him about that a couple years ago and he said he would in a year or
so. I don't know for sure, but I wouldn't be surprised if he hasn't
published anything yet. If you don't have a growing number of users
for your software, I don't think it will mature. I once thought the
STL was "the bomb," but have changed my mind now. In a number of
ways the containers in the Boost Intrusive library are better than
the STL. Anyway, your talk of another approach without giving much
detail or publishing anything doesn't work for me.
I would use a combination of the Boost Intrusive containers and the
STL.
Boost Intrusive doesn't have anything like vector or deque so I'd use
those where it made sense. In places where there is a choice between
an STL container and a Boost Intrusive container, I'd favor using the
Boost Intrusive container.
What do you suggest? Do tell.
Brian Wood
Ebenezer Enterprises
www.webEbenezer.net