Beginner help!

[aaron]

I have a question in my class.. hoping to get some help
I need to create a program that will print
firstName middleName lastName
then their initials

User will input:
John Smith Doe

Output:
John
Smith
Doe
JSM

I can easily create the strings and cout the names but having trouble
finding how to print the first letter of each string
(cannot use array)
am I to use ignore function somehow?
can anyone help me????

[Alf P. Steinbach]

* aaron:

I have a question in my class.. hoping to get some help
I need to create a program that will print
firstName middleName lastName
then their initials

User will input:
John Smith Doe

Output:
John
Smith
Doe
JSM

I can easily create the strings and cout the names but having trouble
finding how to print the first letter of each string
(cannot use array)
am I to use ignore function somehow?
can anyone help me????

std::string, which you should be using to represent each name, has a
number of member functions you can use to extract the first character.

The 'at' member function, for example.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[aaron]

thank you...
Please understand this is the very beginning of a intro to comp
programming class
this at member function is never mention as of yet...

I am including string...
All I need now is to find out how to just print the first character
maybe the use of the ignore function?

#include <iostream>
#include <string>

using namespace std;

int main()
{
string first;
string middle;
string last;

cout << "Enter a name in the format First Middle Last: ";
cin >> first;
cin >> middle;
cin >> last;

cout << first << endl << middle << endl << last << endl;

return 0;

}

[Jim Langston]

"aaron" <aa***@yadavis.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

thank you...
Please understand this is the very beginning of a intro to comp
programming class
this at member function is never mention as of yet...

I am including string...
All I need now is to find out how to just print the first character
maybe the use of the ignore function?

#include <iostream>
#include <string>

using namespace std;

int main()
{
string first;
string middle;
string last;

cout << "Enter a name in the format First Middle Last: ";
cin >> first;
cin >> middle;
cin >> last;

cout << first << endl << middle << endl << last << endl;

return 0;

}

Oh, if they are 3 seperate strings it's even much easier.

first[0] is the first character of the std::string first.
middle[0] is the first character of the std::string middle, etc..

so

std::cout << first[0] << middle[0] << last[0] << std::endl;

would print their initials.

It is [0] instead of [1] because in C, and C++, array elements start at 0,
not 1.

[aaron]

Thank you Jim
That does work... but is this an array?
I have been instructed not to use arrays.

[benben]

aaron wrote:

thank you...
Please understand this is the very beginning of a intro to comp
programming class
this at member function is never mention as of yet...

I am including string...
All I need now is to find out how to just print the first character
maybe the use of the ignore function?

#include <iostream>
#include <string>

using namespace std;

int main()
{
string first;
string middle;
string last;

cout << "Enter a name in the format First Middle Last: ";
cin >> first;
cin >> middle;
cin >> last;

cout << first << endl << middle << endl << last << endl;
Don't use std::endl in this way. Just use '\n'.

return 0;

}

Well if first is "hello" then first[0] will be 'h'.

You work out the rest.

ben

[Alf P. Steinbach]

* benben:

Well if first is "hello" then first[0] will be 'h'.

I recommend the at function, first.at(0), as mentioned.

Especially for a beginner.

To the OP: no, std::string is not an array; using std::string is
probably what your instructor meant by no arrays.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[aaron]

Here is the actual question I've been presented with...

Write a program that reads a person's name from the keyboard in the
format First Middle Last. It should then (1) print each of the names on
a separate line and (2) print the person's initials on the fourth line.
Assume that each person has exactly 3 names, that the first name begins
in the first position on a line (there are no leading blanks) and that
the names are separated from each other by a single blank.

Do not use arrays in this assignment.

[Jim Langston]

"aaron" <aa***@yadavis.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

Thank you Jim
That does work... but is this an array?
I have been instructed not to use arrays.

You are correct. std::string is not an array. But, the same syntax used
for char arrays to get to the individual characters is the same syntax used
for std::string to get to individual characters. Which is the array element
syntax of [] and std::string actually stores it's data in a char pointer it
gets to internally using arrays.

When you use [] to get to an element, it is 0 bound instead of 1 bound for
the low value.

And what do you mean it doesn't work? Did you try it?

[roberts.noah]

aaron wrote:

Here is the actual question I've been presented with...

Write a program that reads a person's name from the keyboard in the
format First Middle Last. It should then (1) print each of the names on
a separate line and (2) print the person's initials on the fourth line.
Assume that each person has exactly 3 names, that the first name begins
in the first position on a line (there are no leading blanks) and that
the names are separated from each other by a single blank.

Do not use arrays in this assignment.

Have you told your instructor that you do not understand the material
in his lectures and the book well enough to do this assignment? If you
need help you should be asking your instructor. Hire a tutor if you
need to; this service is quite common in college and in fact that is
how I fed myself during those years. The assignment is quite easy and
your inability to figure it out indicates that you don't understand the
material in the class and reading materials either because the concepts
are difficult for you (this is pretty normal actually because
programming requires a certain way of thinking that people are not used
to) or you didn't listen/read. If the former, you really need to get a
tutor and/or approach your instructor because it only gets worse (my
experience indicates at least half of the students drop out of any
introductory programming class after midterms), if the later then read
the damn book.

[aaron]

I did not say that it doesn't work... I said "That does work"

[aaron]

I'll respond...but just to let you know, you're not helping
- I have emailed my instructor... he hasn't responded yet
- Once I reach the point of understanding then this assignment will be
easy (for me)

[Luke Meyers]

aaron wrote:

That does work... but is this an array?
No, but the same convention (called "zero-indexing") typically applies
to other data types supporting the subscript operator (operator[]), and
to indexed collections in general within all of computer science. We
like zero.
I have been instructed not to use arrays.

Make sure to thank your instructor for this. Where is this being
taught?

Luke

P.S. Not that you shouldn't know how to use arrays; they just shouldn't
be taught until later.

[aaron]

This course is being taught at
SRJC santarosa.edu

[Tom]

On 4 Feb 2006 22:44:10 -0800, "aaron" <aa***@yadavis.com> wrote:

Here is the actual question I've been presented with...

Write a program that reads a person's name from the keyboard in the
format First Middle Last. It should then (1) print each of the names on
a separate line and (2) print the person's initials on the fourth line.
Assume that each person has exactly 3 names, that the first name begins
in the first position on a line (there are no leading blanks) and that
the names are separated from each other by a single blank.

Do not use arrays in this assignment.

I suggest to do exactly as the assignment calls.

Strings are arrays as far as I am concerned.

I won't write your code for you because you need to learn by
doing/playing with it.

The following is sloppy psuedo code, but should get you on the way
without using arrays or strings.

So ....

Read a character.
Store First Initial.
print character
while(character != ' ')
{
read a character;
print a character;
}
print line return
Read a character.
Store Second Initial.
print character
while(character != ' ')
{
read a character;
print a character;
}
print line return
Read a character.
Store Third Initial.
print character
while(character != ' ')
{
read a character;
print a character;
}
print line return
print 1'st, 2'nd, 3'rd initials

-----------------

I hope this is helpful.
If I was the instructor and you used strings... zero credit.

-- Tom

[roberts.noah]

aaron wrote:

I'll respond...but just to let you know, you're not helping
Time will tell, but I don't think you can be helped.
- I have emailed my instructor... he hasn't responded yet
In the mean time why not try writing it? Here, I'll get you started:

int main()
{
// PROGRAM GOES HERE.
}
- Once I reach the point of understanding then this assignment will be
easy (for me)

I've got a lot of experience helping people learn programming and I can
tell you without a doubt that it is the ones that try to do it that
make it. The ones that just ask what to do as soon as they get the
problem just don't make it. Part of learning how to program is
learning how to answer that question.

When I was tutoring if the student didn't have something to show they
tried I dropped them; it's just a waste of my time.

[aaron]

stillNotHelping

[aaron]

interesting... now this is helpful
thank you Tom

[Bo Persson]

"Alf P. Steinbach" <al***@start.no> skrev i meddelandet
news:43****************@news.individual.net...

* benben:

Well if first is "hello" then first[0] will be 'h'.
I recommend the at function, first.at(0), as mentioned.

Especially for a beginner.

We should perhaps mention the difference, error checking. The at()
function verifies that the parameter is within the current size of the
string. The [] operator does not.

Using first.at(1000) will get you an out_of_range error. If you use
first[1000], we don't know what will happen, because that is
explicitly not defined by the standard. It just runs ahead without
looking!

The slight advantage of using [] is that not checking the index saves
you some (very small) amount of time. If your program runs millions of
times a day, that might be worth the risk!

To the OP: no, std::string is not an array; using std::string is
probably what your instructor meant by no arrays.

Agree.
Bo Persson

[Thomas J. Gritzan]

ro**********@gmail.com schrieb:

In the mean time why not try writing it? Here, I'll get you started:

int main()
{
// PROGRAM GOES HERE.
}

This seems to be a misunderstanding. The OP did already started to
program, but just posted his assignment. Since he did not quote the
context, you think he was asking for doing his homework.

@aaron:

Please, http://learn.to/quote !

Thomas

[Luke Meyers]

Bo Persson wrote:

The slight advantage of using [] is that not checking the index saves
you some (very small) amount of time.
There's also an argument to be made in terms of clarity.
If your program runs millions of
times a day, that might be worth the risk!

Disagree. If your program runs millions of times a day, that
(efficiency gain) might be worth the *effort* of rigorously verifying
the correctness of the access so that the extra checking provided by
at() is redundant. Any code running millions of time, day in and day
out, is probably too important to accept additional *risk* of undefined
behavior.

A good design and clean implementation by someone who knows what
they're doing (not someone in an introductory programming course, mind
you) should be able to provide convincingly correct invariants when
necessary.

Luke

[Alf P. Steinbach]

* Luke Meyers:

Bo Persson wrote:

The slight advantage of using [] is that not checking the index saves
you some (very small) amount of time.

There's also an argument to be made in terms of clarity.

If your program runs millions of
times a day, that might be worth the risk!

Disagree. If your program runs millions of times a day, that
(efficiency gain) might be worth the *effort* of rigorously verifying
the correctness of the access so that the extra checking provided by
at() is redundant. Any code running millions of time, day in and day
out, is probably too important to accept additional *risk* of undefined
behavior.

A good design and clean implementation by someone who knows what
they're doing (not someone in an introductory programming course, mind
you) should be able to provide convincingly correct invariants when
necessary.

I'm sorry, but that's not meaningful in any sense.

IBM did an experiment in coding on paper only, I think that was in
Australia. They'll never do that again.

That's why we we have checked operations such as at(), and that's why we
have testing.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[osmium]

"Luke Meyers" wrote:

Bo Persson wrote:

The slight advantage of using [] is that not checking the index saves
you some (very small) amount of time.

There's also an argument to be made in terms of clarity.

If your program runs millions of
times a day, that might be worth the risk!

Disagree. If your program runs millions of times a day, that
(efficiency gain) might be worth the *effort* of rigorously verifying
the correctness of the access so that the extra checking provided by
at() is redundant. Any code running millions of time, day in and day
out, is probably too important to accept additional *risk* of undefined
behavior.

A good design and clean implementation by someone who knows what
they're doing (not someone in an introductory programming course, mind
you) should be able to provide convincingly correct invariants when
necessary.

The [] is much more clear that at. A well designed language would check for
bounds errors when using the [] notation. It would also have the option of
turning off checking on production builds. All problems solved, nothing to
discuss.

[Luke Meyers]

Alf P. Steinbach wrote:

* Luke Meyers:

Bo Persson wrote:

The slight advantage of using [] is that not checking the index saves
you some (very small) amount of time.
There's also an argument to be made in terms of clarity.

If your program runs millions of
times a day, that might be worth the risk!

Disagree. If your program runs millions of times a day, that
(efficiency gain) might be worth the *effort* of rigorously verifying
the correctness of the access so that the extra checking provided by
at() is redundant. Any code running millions of time, day in and day
out, is probably too important to accept additional *risk* of undefined
behavior.

A good design and clean implementation by someone who knows what
they're doing (not someone in an introductory programming course, mind
you) should be able to provide convincingly correct invariants when
necessary.

I'm sorry, but that's not meaningful in any sense.

IBM did an experiment in coding on paper only, I think that was in
Australia. They'll never do that again.

I think you mistook my meaning. I did not say to produce logical
proofs of program correctness (is that the meaning you took?). I said
"convincingly correct," by which I mean that the invariant "all
unchecked indices are valid," where useful in the context of a specific
time optimization, can generally be provided to an acceptable degree of
confidence within a sufficiently local context. Is that more clear?
Close scrutiny and thorough testing can suffice, when truly expedient.
That's why we we have checked operations such as at(), and that's why we
have testing.

Yes, but in C++, there is an important principle that "you don't pay
for what you don't use." So that's why the unchecked operation is
available.

Luke

[Luke Meyers]

osmium wrote:

The [] is much more clear that at.
A reasonable subjective argument can be made for that (or for the
contrary). I would imagine it depends a great deal on the individual
reading the code.
A well designed language would check for
bounds errors when using the [] notation.
This too is very subjective. What do you mean by "well-designed?"
Given that a programming language is created with certain design
principles involved, certain goals to accomplish, is it fair to call
something poorly designed if you disagree with the selection of
principles and goals? In C++, you don't pay (in terms of time and
space cost at runtime) for what you don't use. There's no free lunch
-- you can't have checked access and have it be as fast as unchecked
access. Inside the body of a tight loop, or another
performance-critical context, this overhead may be both unnecessary and
unacceptably expensive.

You might argue that, while unchecked access is a good facility to have
available, checked access should be the common case, and therefore
provide what you see as the clearest syntax. However, remember that
another important design goal of C++ has always been maximal
compatibility with C; it is because C++ is compatible with C that it
has come into such wide use. The vast majority of programming
languages, "well-designed" or not, languish in obscurity. The []
element access syntax comes from arrays, and for arrays it is an
unchecked operation. Hence, the most consistent scheme is to have the
unchecked operations for other containers use the same syntax.

So, with this in mind, do you really feel it's a bad design, or just
disagree with the priorities involved in choosing design criteria?
It would also have the option of
turning off checking on production builds.
That negates much of the benefit. Non-production code is only run on
whatever test cases you invent (and take the time to implement).
Production use is typically far more exhaustive, and as such may
uncover cases not reached in testing. If the access is unchecked in
those cases, you're no better off for having had checked access in your
tests. When you're in a nice, safe testing sandbox, undefined behavior
may take longer to diagnose than a handled error, but for the most part
the result is the same. In production, undefined behavior can be
catastrophic -- for a lot of C++ code, lives depend on not invoking
undefined behavior.

Better to use checked access in general, and make careful use of
unchecked access when a specific optimization need is discovered during
performance analysis. Fortunately, for those who use the STL
effectively and as intended, it's rare to have to use operator[] or
at() in any case -- that's why we have iterators and standard
algorithms. You can bet that your local for_each implementation isn't
using checked access, but it's small and tight and closely-scrutinized,
and it works great 100% of the time.
All problems solved, nothing to discuss.

That's naive (and rather arrogant). You made your points, based on
your subjective opinion; that doesn't entitle you to declare the
discussion closed and take a victory lap.

Luke

[roberts.noah]

Thomas J. Gritzan wrote:

ro**********@gmail.com schrieb:

In the mean time why not try writing it? Here, I'll get you started:

int main()
{
// PROGRAM GOES HERE.
}

This seems to be a misunderstanding. The OP did already started to
program, but just posted his assignment. Since he did not quote the
context, you think he was asking for doing his homework.

Well, he has been given several ways to do his original question.
Steinbach gave him one right off the bat. So I don't understand why he
is still posting his assignment; seems to me like he should have tried
the solution given and be well on his way to finishing.

His original question was quite reasonable...

[osmium]

"Luke Meyers" wrote:

osmium wrote:

The [] is much more clear that at.
A reasonable subjective argument can be made for that (or for the
contrary). I would imagine it depends a great deal on the individual
reading the code.

Really? Do you actually know a person who finds at clearer?

A well designed language would check for
bounds errors when using the [] notation.

This too is very subjective. What do you mean by "well-designed?"
Given that a programming language is created with certain design
principles involved, certain goals to accomplish, is it fair to call
something poorly designed if you disagree with the selection of
principles and goals? In C++, you don't pay (in terms of time and
space cost at runtime) for what you don't use. There's no free lunch
-- you can't have checked access and have it be as fast as unchecked
access. Inside the body of a tight loop, or another
performance-critical context, this overhead may be both unnecessary and
unacceptably expensive.

You might argue that, while unchecked access is a good facility to have
available, checked access should be the common case, and therefore
provide what you see as the clearest syntax. However, remember that
another important design goal of C++ has always been maximal
compatibility with C; it is because C++ is compatible with C that it
has come into such wide use. The vast majority of programming
languages, "well-designed" or not, languish in obscurity. The []
element access syntax comes from arrays, and for arrays it is an
unchecked operation. Hence, the most consistent scheme is to have the
unchecked operations for other containers use the same syntax.

So, with this in mind, do you really feel it's a bad design, or just
disagree with the priorities involved in choosing design criteria?

It would also have the option of
turning off checking on production builds.

That negates much of the benefit. Non-production code is only run on
whatever test cases you invent (and take the time to implement).
Production use is typically far more exhaustive, and as such may
uncover cases not reached in testing. If the access is unchecked in
those cases, you're no better off for having had checked access in your
tests. When you're in a nice, safe testing sandbox, undefined behavior
may take longer to diagnose than a handled error, but for the most part
the result is the same. In production, undefined behavior can be
catastrophic -- for a lot of C++ code, lives depend on not invoking
undefined behavior.

What is it you don't understand about optional?
Better to use checked access in general, and make careful use of
unchecked access when a specific optimization need is discovered during
performance analysis. Fortunately, for those who use the STL
effectively and as intended, it's rare to have to use operator[] or
at() in any case -- that's why we have iterators and standard
algorithms.

Do you realize that people actually write mathematical programs and other
programs using random access (games) in C++?

[Stephan Brönnimann]

osmium wrote:

"Luke Meyers" wrote:
The [] is much more clear that at. A well designed language would check for
bounds errors when using the [] notation. It would also have the option of
turning off checking on production builds. All problems solved, nothing to
discuss.

An all or nothing bound check is not desirable. How would you
efficiently implement the 2 (non-sense) functions below?
With at and operator[] I can chosse what fits my needs.

char first(const std::string& s) throw (std::exception)
{
return s.at(0);
}

void addOne(std::string& s)
{
typedef std::string::size_type Size;
for (Size e = s.size(), i = 0; i < e; ++i) {
s[i] += 1; // *)
}
}

*) Certainly Alf agrees to use the operator[] here :-)
Overflow check omitted.

Regards, Stephan
br****@osb-systems.com
Open source rating and billing engine for communication networks.

[Alf P. Steinbach]

* Luke Meyers:

Alf P. Steinbach wrote:

* Luke Meyers:

Bo Persson wrote:
> The slight advantage of using [] is that not checking the index saves
> you some (very small) amount of time.

There's also an argument to be made in terms of clarity.

> If your program runs millions of
> times a day, that might be worth the risk!

Disagree. If your program runs millions of times a day, that
(efficiency gain) might be worth the *effort* of rigorously verifying
the correctness of the access so that the extra checking provided by
at() is redundant. Any code running millions of time, day in and day
out, is probably too important to accept additional *risk* of undefined
behavior.

A good design and clean implementation by someone who knows what
they're doing (not someone in an introductory programming course, mind
you) should be able to provide convincingly correct invariants when
necessary.

I'm sorry, but that's not meaningful in any sense.

IBM did an experiment in coding on paper only, I think that was in
Australia. They'll never do that again.

I think you mistook my meaning. I did not say to produce logical
proofs of program correctness (is that the meaning you took?). I said
"convincingly correct," by which I mean that the invariant "all
unchecked indices are valid," where useful in the context of a specific
time optimization, can generally be provided to an acceptable degree of
confidence within a sufficiently local context. Is that more clear?
Close scrutiny and thorough testing can suffice, when truly expedient.

First rule of optimization: don't do it.

Second rule: don't do it yet.

Third rule: measure first.

IMO teaching irrelevant and mostly problematic low-level optimization
techniques to novices, instead of proper engineering, is very bad.

At least, if unchecked operations are to be recommended, also recommend
measurement to see whether they actually have any positive effect.

That's why we we have checked operations such as at(), and that's why we
have testing.

Yes, but in C++, there is an important principle that "you don't pay
for what you don't use." So that's why the unchecked operation is
available.

The unchecked operations are available for the cases where you either
don't care about correctness, or guarantee it in other ways.

Those are not reasonable requirements for a novice.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[roberts.noah]

Luke Meyers wrote:

osmium wrote:

[snip - no point arguing missing sections since they are correct]

It would also have the option of
turning off checking on production builds.

That negates much of the benefit. Non-production code is only run on
whatever test cases you invent (and take the time to implement).
Production use is typically far more exhaustive, and as such may
uncover cases not reached in testing. If the access is unchecked in
those cases, you're no better off for having had checked access in your
tests. When you're in a nice, safe testing sandbox, undefined behavior
may take longer to diagnose than a handled error, but for the most part
the result is the same. In production, undefined behavior can be
catastrophic -- for a lot of C++ code, lives depend on not invoking
undefined behavior.

Better to use checked access in general, and make careful use of
unchecked access when a specific optimization need is discovered during
performance analysis. Fortunately, for those who use the STL
effectively and as intended, it's rare to have to use operator[] or
at() in any case -- that's why we have iterators and standard
algorithms. You can bet that your local for_each implementation isn't
using checked access, but it's small and tight and closely-scrutinized,
and it works great 100% of the time.

While much of what you say is true I do find that providing
non-production checks to be very benificial. Sometimes when you are in
the middle of development you are not fully aware of all the
concequences of your actions. Placing asserts that are compiled out in
release mode help other developers find those areas that get broken by
code they change or add. For instance in this case you may find that
something you did added length to a vector but you were not aware of
that concequence. Concequently you run into a buffer overrun situation
and without a debug assert telling you what happened and where it could
take you hours or days to find it.

Also you use of iterators as illustration is questionable since
iterators are unchecked. In a situation when you want to be sure never
to overrun it may be more beneficial to use at() then an iterator that
can go past end() into no-man's land.

That said, I never use at(). For one thing it would be a major issue
where I work because the lead dev doesn't like STL to begin with and
thinks its slow and does bounds checking all the time (I know) but also
because he doesn't like exceptions and at() generates exceptions. But
to tell the truth I never used it anyway since it is just so easy to
check for yourself and most of the time you have to anyway. IMHO even
when you don't you should be since exceptions are for exceptional
situations and shouldn't be used for bound checking.

[Luke Meyers]

osmium wrote:

"Luke Meyers" wrote:

osmium wrote:

The [] is much more clear that at.

A reasonable subjective argument can be made for that (or for the
contrary). I would imagine it depends a great deal on the individual
reading the code.

Really? Do you actually know a person who finds at clearer?

Anyone used to C would instinctively read [] as unchecked access. An
inconsistency in semantics (operator[] meaning different things for
different types) would make programs less clear to such individuals (of
which there are many).

It would also have the option of
turning off checking on production builds.

That negates much of the benefit. Non-production code is only run on
whatever test cases you invent (and take the time to implement).
Production use is typically far more exhaustive, and as such may
uncover cases not reached in testing. If the access is unchecked in
those cases, you're no better off for having had checked access in your
tests. When you're in a nice, safe testing sandbox, undefined behavior
may take longer to diagnose than a handled error, but for the most part
the result is the same. In production, undefined behavior can be
catastrophic -- for a lot of C++ code, lives depend on not invoking
undefined behavior.

What is it you don't understand about optional?

I take exception to your tone, and to the presumption that I'm failing
to understand. Someone asked a more detailed version about this
elsewhere in this thread; I'll make my response there.

Better to use checked access in general, and make careful use of
unchecked access when a specific optimization need is discovered during
performance analysis. Fortunately, for those who use the STL
effectively and as intended, it's rare to have to use operator[] or
at() in any case -- that's why we have iterators and standard
algorithms.

Do you realize that people actually write mathematical programs and other
programs using random access (games) in C++?

Obviously. There are certainly situations where it's called for. But
it's far more common, in a good design that makes wise use of standard
libraries, to treat the contents of containers systematically (e.g.
iterating over the whole set) rather than interacting with numeric
indices. I use the STL extensively, and neither operator[] nor at()
figure heavily into my usage patterns. It's nice to know they're
there, but I don't find them appearing often in good designs.
Obviously, there are exceptions peculiar to specific domains.

Luke

[Luke Meyers]

ro**********@gmail.com wrote:

Luke Meyers wrote:

osmium wrote:
[snip - no point arguing missing sections since they are correct]

Cheers. ;)

It would also have the option of
turning off checking on production builds.

That negates much of the benefit. Non-production code is only run on
whatever test cases you invent (and take the time to implement).
Production use is typically far more exhaustive, and as such may
uncover cases not reached in testing. If the access is unchecked in
those cases, you're no better off for having had checked access in your
tests. When you're in a nice, safe testing sandbox, undefined behavior
may take longer to diagnose than a handled error, but for the most part
the result is the same. In production, undefined behavior can be
catastrophic -- for a lot of C++ code, lives depend on not invoking
undefined behavior.

Better to use checked access in general, and make careful use of
unchecked access when a specific optimization need is discovered during
performance analysis. Fortunately, for those who use the STL
effectively and as intended, it's rare to have to use operator[] or
at() in any case -- that's why we have iterators and standard
algorithms. You can bet that your local for_each implementation isn't
using checked access, but it's small and tight and closely-scrutinized,
and it works great 100% of the time.

While much of what you say is true I do find that providing
non-production checks to be very benificial. Sometimes when you are in
the middle of development you are not fully aware of all the
concequences of your actions. Placing asserts that are compiled out in
release mode help other developers find those areas that get broken by
code they change or add. For instance in this case you may find that
something you did added length to a vector but you were not aware of
that concequence. Concequently you run into a buffer overrun situation
and without a debug assert telling you what happened and where it could
take you hours or days to find it.

Oh, please don't misunderstand -- optionally-enabled runtime assertions
are an invaluable tool. But optionality isn't free. The fact that
(for std::vector) operator[] is unchecked and at() is checked is an
invariant. Users of at() would be disappointed if they wrote code
reliant on the checking provided by at(), only to find that this
checking was swept out from under them in production.
Optionally-checked random access would be a helpful feature, but it's
by no means an acceptable substitute for *guaranteed* checking.
Also you use of iterators as illustration is questionable since
iterators are unchecked. In a situation when you want to be sure never
to overrun it may be more beneficial to use at() then an iterator that
can go past end() into no-man's land.
Iterators are more tightly typed than integer indices. Integers can
easily pass to and fro through wide swathes of program code. Iterators
naturally restrict themselves to more limited scopes, closely
associated with the container they pertain to. As such, I think in
general the pedigree (validity) of an iterator is far easier to
ascertain than that of an integer used as an index. An integer can
mean anything, and is involved in countless operations having nothing
to do with your container -- iterators only participate in logic
pertinent to the container.

The point I was really trying to make, though, is that with iterators
one can rely on proven algorithms rather than constantly, redundantly
performing low-level manipulation of individual elements.
std::for_each operates on a whole container, not just a single element.
It's correct, it's optimal, it's reliable. Hand-crufted for loops are
far more prone to error and efficiency. It's far easier to pass valid
iterators to std::for_each than to write a correct for loop.
That said, I never use at().
Me neither, for the most part. Same with operator[] (for std::vector).
For one thing it would be a major issue
where I work because the lead dev doesn't like STL to begin with and
thinks its slow and does bounds checking all the time (I know)
You have my sympathy. However, those statements are provably false on
technical grounds. If your lead is so unreasonable that he will not
listen to such an argument, I wonder why you're wasting your time on a
team so severely handicapped by such deficient and misguided
leadership.
but also
because he doesn't like exceptions and at() generates exceptions.
Exceptions carry a lot of subtleties with them, but they're a valuable
language feature and should not be shunned. Professional software
developers should be expected to take the time to learn important tools
and how to use them properly. Put another way: the alternative to an
exception is undefined behavior. If your lead doesn't like exceptions,
how does he like segmentation faults and core dumps?
But
to tell the truth I never used it anyway since it is just so easy to
check for yourself and most of the time you have to anyway.
Most of the time it's moot because a standard algorithm is perfectly
suitable.
IMHO even
when you don't you should be since exceptions are for exceptional
situations and shouldn't be used for bound checking.

One valid interpretation is that exceptions can represent invariant
violations. Out-of-bounds access surely meets that criterion.

Luke

[roberts.noah]

Luke Meyers wrote:

For one thing it would be a major issue
where I work because the lead dev doesn't like STL to begin with and
thinks its slow and does bounds checking all the time (I know)
You have my sympathy. However, those statements are provably false on
technical grounds. If your lead is so unreasonable that he will not
listen to such an argument, I wonder why you're wasting your time on a
team so severely handicapped by such deficient and misguided
leadership.

Oh, I like where I work I just butt heads with the lead on some issues.

I think I've shown that using the STL isn't as costly as he thinks well
enough that I don't hear about it too often anymore. I'm introducing
new ideas and such into the group, as it should be, and visa-versa and
I am learning things so I feel the relationship is mutually productive.
You shouldn't judge the crew based on my complaints; there are some
very smart people here.

but also
because he doesn't like exceptions and at() generates exceptions.
Exceptions carry a lot of subtleties with them, but they're a valuable
language feature and should not be shunned. Professional software
developers should be expected to take the time to learn important tools
and how to use them properly.

Definately. I'm always buying books to improve my abilities and learn
different techniques. I don't always use them but I always get
something out of the reading. To me this is fundamental and in fact it
is how 90% of my learning has been accomplished.

In this case however, it isn't about not knowing how to use a language
feature (though since they don't there is some of that) it is that they
are percieved as too costly and as such explicitly disallowed. In
other words someone actually decided that they would not use them, not
just too lazy to learn.

Put another way: the alternative to an exception is undefined behavior. If your lead doesn't like exceptions,
how does he like segmentation faults and core dumps?
The alternative to exceptions is return codes. I myself think this is
a much more inefficient way to deal with exceptional situations but I'm
not ready to go there. So we use return codes and debug build asserts.
I agree that we should be using exceptions but people lived a long
time without them and it is possible to continue doing so.

But
to tell the truth I never used it anyway since it is just so easy to
check for yourself and most of the time you have to anyway.
Most of the time it's moot because a standard algorithm is perfectly
suitable.

I often iterate vectors instead of calling for_each. Often it is some
simple thing I want to do and its easier just to write a for loop
instead of function or functor. Might be nice to use bll or phoenix
expressions but I can't....at least not yet....no boost.

IMHO even
when you don't you should be since exceptions are for exceptional
situations and shouldn't be used for bound checking.

One valid interpretation is that exceptions can represent invariant
violations. Out-of-bounds access surely meets that criterion.

Out of bounds access yes but checks should always be done before hand
either explicitly or through the nature of the algorithm itself. An
out of bounds exception should indicate that the algorithm has failed
in a fundamental way.

[aaron]

aha...it's so simple!!!

use the substr function
firstName.substr(0,1)
middleName.substr(0,1)
lastName.substr(0,1)

Thanks everyone!