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????

[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
"convincing ly 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**********@gm ail.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 misunderstandin g. 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::str ing& s)
{
typedef std::string::si ze_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
"convincing ly 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.