M
Mike Wahler
Mike Stenzler said:
[sigh]
*PLONK*
-Mike
[sigh]
*PLONK*
-Mike
M
Mike Stenzler
Default said:
That is an argumentum ad hominem. In case you don't know what that is
please RTFM. Additionally, I didn't know jackasses can type. I think you
are behaving like an orangutan.
You're absolutely right - but I already admitted to that transgression
and apologized. Then I moved on and asked a question that WAS topical.
Read the thread. Didn't happen. I never said a word about the behaviour
of anyone except those I was in direct communication with. That comment
(see below) was a sarcastic comment directed at one single individual
who took it upon himself to "manage" the newsgroup.
I didn't ask for a tutorial, I didn't ask for 4 chapters of text, I
didn't ask to understand the entire subject, I didn't ask to get into
this little pissing match - I just asked how to use std::vector to
implement an array of classes. I DEFINITELY did not SAY ANYTHING about
the newsgroup as a whole and the netiquette of it's posters. As evidence
that this question was not so overly broad as to be unanswerable except
by reading several chapters of a book - Jonathan answered my question in
about 20 lines of code and gave me the info I was looking for.
Yes, it was previously mentioned.
Mike Stenzler
W
WW
Mike said:
Et tu, Mike? ;-)
W
WW
TROLL ALERT!
B
Buster
Mike Stenzler said:
For default-initialized elements,
std::vector <name_of_type> name_of_vector (size_of_vector);
For copy-initialized elements, I forget which way round it goes
(but it's in the FM
Good luck and best regards,
Buster.
M
Mike Stenzler
Jonathon-
Jonathan Mcdougall wrote:
[snip]
I know you did. I acknowledged that. My thanks were genuine. I just
don't think my question was that broad to get painted with the RTFM
brush. You proved that by answering it with like maybe 20 lines of code.
Yes, I need to do some reading to use this further. But Jeez, lighten up
on people.
I didn't miss any posts, I can see the whole thread here in my news
reader. I DID miss a few smiley's of yours and probably wouldn't have
given YOU any sass if I'd seen them.
Is calling me a jackass, polite? (Not you - Brian Rodenborn aka
Default_User).
That statement was made as a sarcastic comment on Atilla's behaviour as
newsgroup nazi. I just don't like being shit upon, especially by a herd.
I looked but I'm not sure I see that in the faq.
[snip]
You're right. It doesn't. I missed the smiley, missed 2 of 'em I think.
Most seemed to have missed my ironies.
Missed it. Sorry.
OK, I'll bite (that's how I got into several people's kill files to
begin with)
it seems to me that using this std::vector class to instantiate an array
of class objects isn't too efficient. In C you declare (and allocate
memory for) an array in one shot, then use very efficient direct
addressing (subscript notation, not ptr) to access the array members.
Unfortunately, the array is not dynamically resizeable, so limited in
usage (from my perspective) - I prefer linked lists, usually when I use
an array it's strictly for efficiency. In VB of course, arrays are
resizeable (redim). The MFC CArray class creates an empty array that is
then settable to a number of elements using CArray::SetSize(). So in a
possible implementation for me I could instantiate an array, set it to
some reasonable size, then fetch data into it and if the reasonable size
is exceeded I could use CArray::SetAtGrow() or CArray::Add() to grow the
array record by record. Microsoft claims that using CArray::GetAt() &
CArray::SetAt() to access the array members (each in this case a class)
is just as efficient as the direct addressing of C language.
Now, I DID RTFM as far as the a.pop_back() that you had included in your
snippet, I'm not sure I understand why, but id does solve the problem I
immediately saw of an empty element at .last. I still see (under a
debugger) an empty at .end - not sure if this is a problem. Here's where
a RTFM comment is warranted. What I'm curious about now is I don't see
any way to batch allocate an array (vector) of a certain size - it's
certainly clear that using your method will work, but it grows the array
a record at a time - that seems inefficient compared to the MFC
implementation and certainly compared to raw C arrays. Am I missing
something? Or id this just a tradeoff situation?
Mike
Jonathan Mcdougall wrote:
[snip]
I know you did. I acknowledged that. My thanks were genuine. I just
don't think my question was that broad to get painted with the RTFM
brush. You proved that by answering it with like maybe 20 lines of code.
Yes, I need to do some reading to use this further. But Jeez, lighten up
on people.
I didn't miss any posts, I can see the whole thread here in my news
reader. I DID miss a few smiley's of yours and probably wouldn't have
given YOU any sass if I'd seen them.
Is calling me a jackass, polite? (Not you - Brian Rodenborn aka
Default_User).
That statement was made as a sarcastic comment on Atilla's behaviour as
newsgroup nazi. I just don't like being shit upon, especially by a herd.
I looked but I'm not sure I see that in the faq.
[snip]
You're right. It doesn't. I missed the smiley, missed 2 of 'em I think.
Most seemed to have missed my ironies.
Missed it. Sorry.
OK, I'll bite (that's how I got into several people's kill files to
begin with)
it seems to me that using this std::vector class to instantiate an array
of class objects isn't too efficient. In C you declare (and allocate
memory for) an array in one shot, then use very efficient direct
addressing (subscript notation, not ptr) to access the array members.
Unfortunately, the array is not dynamically resizeable, so limited in
usage (from my perspective) - I prefer linked lists, usually when I use
an array it's strictly for efficiency. In VB of course, arrays are
resizeable (redim). The MFC CArray class creates an empty array that is
then settable to a number of elements using CArray::SetSize(). So in a
possible implementation for me I could instantiate an array, set it to
some reasonable size, then fetch data into it and if the reasonable size
is exceeded I could use CArray::SetAtGrow() or CArray::Add() to grow the
array record by record. Microsoft claims that using CArray::GetAt() &
CArray::SetAt() to access the array members (each in this case a class)
is just as efficient as the direct addressing of C language.
Now, I DID RTFM as far as the a.pop_back() that you had included in your
snippet, I'm not sure I understand why, but id does solve the problem I
immediately saw of an empty element at .last. I still see (under a
debugger) an empty at .end - not sure if this is a problem. Here's where
a RTFM comment is warranted. What I'm curious about now is I don't see
any way to batch allocate an array (vector) of a certain size - it's
certainly clear that using your method will work, but it grows the array
a record at a time - that seems inefficient compared to the MFC
implementation and certainly compared to raw C arrays. Am I missing
something? Or id this just a tradeoff situation?
Mike
W
WW
Mike said:
You don't need to be shit upon. You smell troll without it. And I have to
inform you that I do not take lightly to be called a nazy. You have crossed
the line.
M
Mike Stenzler
Ahh! Thanks.
Mike
Mike
For default-initialized elements,
std::vector <name_of_type> name_of_vector (size_of_vector);
For copy-initialized elements, I forget which way round it goes
(but it's in the FM
Good luck and best regards,
Buster.
D
Default User
Mike said:
What are you talking about? I was making an observation, not debating a
topic.
Brian Rodenborn
J
Jonathan Mcdougall
it seems to me that using this std::vector class to instantiate an array
For sure arrays are more efficient than std::vector, since it is a
class with some book-keeping. But imho, better safe than sorry.
v[0]
is best you can have. In the best case, it only redirects to the
array (assuming the internal representation _is_ an array).
The member function at() gives checked access to the vector :
try
{
v.at(10) = 50;
}
catch(std:ut_of_range)
{
// ...
}
In that case, check out std::list.
[ot]
Usually, std::vector's internal representation is an array which is
copied around and resized when full. std::list is usually a linked
list. But aside from the speed constraints, this is implementation
defined.
[/ot]
In C++ too, but you have got to do that manually.
std::vector::reserve() is the closest match. It reserves memory
to avoid reallocation.
For example :
std::vector<int> v(10);
this creates a vector of 10 elements. It is correct to do
v[0] = 5;
v[1] = 54;
...
v[9] = 21;
If you want to enlarge the vector, you *must* *add* elements
via push_back() or insert().
v.push_back(12);
Since the vector had only 10 elements, it must grow (create a new
array, copy the data, delete the old one). It could grow by one,
but this would not be very efficient, so it grows by a given
factor, let's say 2. So now our std::vector has 20 elements for
which memory is reserved, but only *11* accessible.
If you know you have a lot of inserts or push_back to do, you
can reserve the memory to avoid reallocation :
v.reserve(100);
Here, the memory is reserved for 100 elements. You can now add
100 elements with no reallocation.
You must understand the difference between capacity (with reserve())
and size (with push_back and insert). reserve() does not create
element, insert and push_back do.
std::vector:ush_back() adds an element at the end of the vector and
grows it if needed. std::vector::insert() inserts an element at the
given position and grows it if needed.
Do you know we are talking about less than milli-seconds here? If
speed is important, you can do it in assembly, it could be faster.
But the difference is really not big enough to make a difference
(depending on the context, of course).
I am not sure I am following you here.
As I said
std::vector<int> v(10); // 10 elements
or
v.reserve(100);
to prevent the reallocation if less than 100 elements are inserted.
It would be far more interesting for you to get Josuttis's "The C++
Standard Library". Lots and lots of nice informations in there.
Jonathan
For sure arrays are more efficient than std::vector, since it is a
class with some book-keeping. But imho, better safe than sorry.
std::vector said:
v[0]
is best you can have. In the best case, it only redirects to the
array (assuming the internal representation _is_ an array).
The member function at() gives checked access to the vector :
try
{
v.at(10) = 50;
}
catch(std:
ut_of_range){
// ...
}
In that case, check out std::list.
[ot]
Usually, std::vector's internal representation is an array which is
copied around and resized when full. std::list is usually a linked
list. But aside from the speed constraints, this is implementation
defined.
[/ot]
In C++ too, but you have got to do that manually.
std::vector::reserve() is the closest match. It reserves memory
to avoid reallocation.
For example :
std::vector<int> v(10);
this creates a vector of 10 elements. It is correct to do
v[0] = 5;
v[1] = 54;
...
v[9] = 21;
If you want to enlarge the vector, you *must* *add* elements
via push_back() or insert().
v.push_back(12);
Since the vector had only 10 elements, it must grow (create a new
array, copy the data, delete the old one). It could grow by one,
but this would not be very efficient, so it grows by a given
factor, let's say 2. So now our std::vector has 20 elements for
which memory is reserved, but only *11* accessible.
If you know you have a lot of inserts or push_back to do, you
can reserve the memory to avoid reallocation :
v.reserve(100);
Here, the memory is reserved for 100 elements. You can now add
100 elements with no reallocation.
You must understand the difference between capacity (with reserve())
and size (with push_back and insert). reserve() does not create
element, insert and push_back do.
std::vector:
ush_back() adds an element at the end of the vector andgrows it if needed. std::vector::insert() inserts an element at the
given position and grows it if needed.
Do you know we are talking about less than milli-seconds here? If
speed is important, you can do it in assembly, it could be faster.
But the difference is really not big enough to make a difference
(depending on the context, of course).
I am not sure I am following you here.
As I said
std::vector<int> v(10); // 10 elements
or
v.reserve(100);
to prevent the reallocation if less than 100 elements are inserted.
It would be far more interesting for you to get Josuttis's "The C++
Standard Library". Lots and lots of nice informations in there.
Jonathan
J
Jonathan Mcdougall
TROLL ALERT!
enough.
jonathan
enough.
jonathan
W
WW
Jonathan said:
Yeah. That is a synonim.
M
Mike Wahler
WW said:
What really got me was:
<quote>
"after almost 20 years as a professional programmer writing
in 6 languages under I'm not sure how many different OS
environments..."
</quote>
(obviously an attempt to impress people
and/or engender their 'sympathy')
<quote>
"Having 2 small children and job deadline pressures to meet,
I usually don't have the luxury of poring through docs..."
</quote>
(more childish whining)
So, to Mr. Stenzler, a reality check:
[big breath]
During my just under thirty years as a software professional,
in more languages than I can recall (in excess of two dozen),
with 10+ operating systems, dozens of special purpose libraries,
many special-purpose hardware devices with their idiosyncracies
and outright bugs, in over 20 vertical markets, dealing with many irrational
or unreasonable requests/demands, negotiating with
employers, clients, and vendors, managing subordinates,
administrating computer networks, participating in marketing,
deployment, user training, and customer service, continuing my
education via books, seminars, and consultants, in 7 U.S. states,
and often exhausting business travel (both air and land), I've
never needed to make demands of or abuse others in order to do my
job effectively.
I've never used the circumstances of my personal life (which
as is probably the case with almost anyone, have been occasionally
quite trying) to justify defaulting on my self-reponsibility
or attempting to assign that responsibility to others, in order
to acquire any additional knowledge and/or skills necessary
to to my job.
And I still somehow found time to write this rant.
Employer/client: "I need this new technology integrated
into the project."
Employee/consultant: "But I don't know how to do that,
I don't have time to learn, and
I can't find anyone to do it for me."
Employer/client "Help wanted."
You need not reply, Mr. Stenzler, I won't see it.
There, I feel better now. We now return you to
your regularly scheduled programming.
-Mike
W
WW
Mike Wahler wrote:
[SNIPPO]
Ah. Then we know you did not work for Dogbert's consultancy.
[SNIPPO RE-RUN]
I can understand if someone is desperate. But all I can say is:
http://mars-attacks.org/~boklm/browse/humor/bart.gif
[SNIPPO]
Ah. Then we know you did not work for Dogbert's consultancy.
[SNIPPO RE-RUN]
I can understand if someone is desperate. But all I can say is:
http://mars-attacks.org/~boklm/browse/humor/bart.gif
R
Ron Natalie
Jonathan Mcdougall said:
For sure, vectors are not slower for most of what you are doing on
a reasonable implementation. This is precisely the reason operator[]
does not do any range checking, etc...
Which is no more work than what the compiler does to access
the array in most cases.
Or resize().
J
Jonathan Mcdougall
int main()
I just saw that comment, yurk! 'v' contains *one* element now,
not two. pop_back() removes the last element. Sorry.
Two elements now.
Jonathan
I just saw that comment, yurk! 'v' contains *one* element now,
not two. pop_back() removes the last element. Sorry.
Two elements now.
Jonathan
M
Mike Stenzler
Yeah, that did confuse me a bit, see my email.
There *is* some unusual behaviour or wrong usage on my part under VC++,
it may be have to do with reserve() vs the element allocation of
push_back(). I'll check in the AM at work.
Thanks
Mike
There *is* some unusual behaviour or wrong usage on my part under VC++,
it may be have to do with reserve() vs the element allocation of
push_back(). I'll check in the AM at work.
Thanks
Mike
Jonathan said:
K
Karl Heinz Buchegger
Mike said:
It's only 5% you should or need to know about vectors.
The remaining 95% are what is written in those 4 chapters.
But it has the benefit, that if you have read those 4 chapters
you would also know how to work with std::list, std::map, std::multimap, etc ...
In this NG we don't care who you are or what your position is.
Even if Stroustroup himself posts and is wrong he will
be corrected.
A
Attila Feher
M
Mike Stenzler
Karl Heinz Buchegger wrote:
[snip]
understood - my immediate need was just for some syntax on std::vector
or any similar animal (hence the initial misdirected request re CArray),
it would be nice to know all of the rest, but to solve my problem of the
moment I just needed to see if vector would work for me.
It was a joke son, a joke! I didn't post the above to appear better
than anyone - just to sarcastically reply to the the poster below who
implies that I'm having such a tough time programming. My point was that
the evidence of my position belied the statement - I've been pretty damn
successful in life writing code. I was also kinda teasing him since he
signs his posts as "WW aka Atilla". However, it's true that position
doesn't directly equate to competence - lots of folks get promoted (or
elected) over their heads, and in the context of a newsgroup I can see
how it could be misinterpreted - so it was a poor choice of words in
this senseless pissing match.
Anyway, time to move on..
Mike
[snip]
understood - my immediate need was just for some syntax on std::vector
or any similar animal (hence the initial misdirected request re CArray),
it would be nice to know all of the rest, but to solve my problem of the
moment I just needed to see if vector would work for me.
It was a joke son, a joke!
I didn't post the above to appear betterthan anyone - just to sarcastically reply to the the poster below who
implies that I'm having such a tough time programming. My point was that
the evidence of my position belied the statement - I've been pretty damn
successful in life writing code. I was also kinda teasing him since he
signs his posts as "WW aka Atilla". However, it's true that position
doesn't directly equate to competence - lots of folks get promoted (or
elected) over their heads, and in the context of a newsgroup I can see
how it could be misinterpreted - so it was a poor choice of words in
this senseless pissing match.
Anyway, time to move on..
Mike