C++ - how to convert string to uppercase/lowercase

[Ian Collins]

I'm not sure I understand. The code I write belongs to my
employer. Some employers have very strict coding guidelines,
others don't.

The development team owns the code, collectively on behalf of their
employer. No single developer is responsible (has ownership of in
management speak) any one module. Everyone works on every bit of code.
For this to work, the team has to have a common style, which will
quickly evolve in the absence of a coding guideline. Coding guidelines
should not be cast in stone, they should be owned by and updated by
those who follow them. As you said further down, a unified style
improves programmer productivity, that works best if the programmers
shape the style.

It's the company's code.

Exactly. Many places I have worked have silos within projects, person A
"owns" module Z and person B "owns" module X.

 

[James Kanze]

According to dictionary.com, the term "coworker" date existed
by 1645 at the latest. It is not a neologism. The main
difference, as I perceive it, is that a coworker works for the
same employer, whereas a colleague may not.

I don't really perceive any difference. One is a native
derivation, the other is a loan word from French. I'd typically
suspect the native derivation to be more common in the US, and
the loan word from French to be more common in Britain, but
that's probably just a personal prejudice on my part.

Of course, I tend to prefer the French, even to the point of
using the French spelling.

If you will kindly consult the official c.l.c++ style guide,
you will see that "coworker" is not hyphenated.

Again, probably only if you're not in Britain. My Collins
(British) says it is always hyphenated; the on-line dictionaries
I have access to (all American) either give it as never
hyphenated, or give the unhyphenated form as preferred.

Which brings us back to the starting point: both f() and f(void)
are correct, but different cultural contexts may make one or the
other preferred.

 

[James Kanze]

James Kanze wrote:
[snip]
int main ( void )

[concerning f() vs. f(void)...]

But then, a function call where the return value is discarded

would also yield a hit.

Oops. You're right, my suggestion doesn't work at all.

I agree: tools have a strong influence on coding styles.
Probably the strongest influence with cultural issues and
local consensus.

Especially given that choice of tools is generally a religious
issue.

When namespace nesting gets really deep, the issue becomes
more pressing.

I'm still not too sure what the best practice with regards to
namespaces should be. Most of the places I've worked just
ignore them. One place, on the other hand, nested them much the
way the original Java specification recommended packages be
nested; ending up as many as five layers deep wasn't rare.

My gut feeling is that neither extreme is particularly good. In
my personal work, I have one level for the library (which
encodes the version in the name, so you can't compile with one
version, and link against another), and at most one level below
that in the user interface. Internally, I'll sometimes have a
nested unnamed namespace or a private namespace, but that's the
maximum.

I can see that.

But the best solution might have been not to nest so much. (A
lot of those namespaces only contained a single class.)

That is interesting. I used to think that a string of
qualifications

is a downside (way too verbose). However, it has the advantage
of making very explicit, where the function resides. And, one
does not need to scroll. I guess, that's really a plus. Hm, I
need to think.

Well, I find it a bit verbose as well. But we have no choice
when it comes to classes, and there's something to be said for
treating classes and namespaces identically. But I'm not really
convinced, one way or the other.

 

[James Kanze]

James Kanze wrote:

Using a common editor setup within a team is much better than
a written coding style guide.

Getting everyone to agree on the same editor is several orders
of magnitude more difficult than getting people to agree on the
style.

I've tried using a using directive at the top of source files,
which works if the file contains function definitions for one
class.

Huh. I didn't think that using directives affect function
definitions.

This does upset some editors, my last team liked Visual
Slickedit, which couldn't tag functions unless they were
enclosed in a namespace, or fully qualified.

Was the nesting of namespaces a design smell? I find to many
nested namespaces just as bad as too many nested code blocks.

Sort of, I think. It was some time ago, and I think people were
still experimenting, trying to find what was best. But IMHO,
they were overdoing it.

It does work, keeping the verbosity in the name rather than
excessive indentation.

I can see two very big pluses: it treats namespaces the same way
it treats classes, and it keeps a complete specification of
locality close to where you are working, and so visible.
(Presumably, the main reason Kai-Uwe wants to indent namespaces
is that it allows him to see that the function is in a
namespace, ten functions down in the file.)

It does fail with regards to succinctness, however. And I'm not
really happy about the fact that what is being defined only
shows up way off to the right side of the page.

 

[Noah Roberts]

You mean by ignoring it.

Far from it actually. I'd consider disciplinary action.

 

[Noah Roberts]

The development team owns the code, collectively on behalf of their
employer. No single developer is responsible (has ownership of in
management speak) any one module. Everyone works on every bit of code.
For this to work, the team has to have a common style, which will
quickly evolve in the absence of a coding guideline. Coding guidelines
should not be cast in stone, they should be owned by and updated by
those who follow them. As you said further down, a unified style
improves programmer productivity, that works best if the programmers
shape the style.

I find though that in the early stages of a project, with a team that
has not established its standards, someone needs to guide the process by
being the Nazi, at least for a while. Otherwise you end up with a bunch
of code that's all patchwork looking.

Also, new members need to be pushed in the right direction in the case
of a well established project and team.

There's also some issues that really need immediate standard. TABS vs.
Spaces for instance...you just can't let that one go. It seems trivial
but when people decide on different answers to that question, and
different sizes of indentation...it just gets messy.

Another reason to have standards is that sometimes they actually help
people who don't really have a good idea what their own opinion is.
Like with more complex template declarations...many people simply don't
have a good idea how to format that kind of thing.

 

[Ian Collins]

I find though that in the early stages of a project, with a team that
has not established its standards, someone needs to guide the process by
being the Nazi, at least for a while. Otherwise you end up with a bunch
of code that's all patchwork looking.

That was me, but the coding style soon evolved and I didn't have any
reason to stop it.

There's also some issues that really need immediate standard. TABS vs.
Spaces for instance...you just can't let that one go. It seems trivial
but when people decide on different answers to that question, and
different sizes of indentation...it just gets messy.

That's were a standard editor with a common configuration (under source
control with the code) helps.

 

[Ian Collins]

Huh. I didn't think that using directives affect function
definitions.

They don't. My point was a using directives at the top of the module
only works if there aren't name clashes.

 

[Ian Collins]

Getting everyone to agree on the same editor is several orders
of magnitude more difficult than getting people to agree on the
style.

It wasn't in our case. The team very quickly adopted SlickEdit and they
were able to set it up to follow our preferred style. At that point the
style document became largely redundant in favour of the editor
configuration.

 

[Kai-Uwe Bux]

Bravo, sir. This may be the first time I've ever seen a digressive
thread brought back on topic.

Oh, we have a long way to get back on topic. After all, this thread should
be about the ways of converting a string to lower case. (The result so far
seems that one cannot rely on locales doing the right thing and using the
C-functions is tricky.)


Best

Kai-Uwe Bux

 

[James Kanze]

The development team owns the code, collectively on behalf of
their employer.

I don't know where you get that. All of the code which I've
worked on professionally has been done as a work for hire. The
company who paid for it owned it, and the people who wrote it
had pretty much no say with regards to what was done with it.

No single developer is responsible (has ownership of in
management speak) any one module.

Responsibility and ownership are two different things. Whoever
checks the code in is responsible for it meeting the established
quality requirements.

Everyone works on every bit of code. For this to work, the
team has to have a common style, which will quickly evolve in
the absence of a coding guideline. Coding guidelines should
not be cast in stone, they should be owned by and updated by
those who follow them. As you said further down, a unified
style improves programmer productivity, that works best if the
programmers shape the style.

That more or less "va de soi" (not sure how to say it in
English: "goes from itself"). Coding guidelines are written by
the coders. And the evolve in time. That's always been the
case---nothing else works. (And coding guidelines, and
everything else in the process, must be sold to the programmers;
nothing imposed arbitrarily from above ever works.)

Exactly. Many places I have worked have silos within
projects, person A "owns" module Z and person B "owns" module
X.

Well, I "own" the library at my site. I've written it over a
number of years (too many to count), and no one has ever paid me
for it. But I think you mean something else by "own", although
I can't figure out what: if you are paid for your work, then
whoever pays you owns the copyright on the code, and thus the
code.

And you can't mean the responsibility for the code, because you
want all of the individuals in the team to feel responsible.
When the code works, all of the people who worked on it should
feel proud. The important point here is creating the
understanding that it is a team effort; no one person can do it
himself. And the person who actually coded module X needed the
help of the person who designed it, and the people who code
reviewed it, and the people who tested it, and the people he
talked to while he was coding it, and even his boss, who made
sure that all that support was there, that he wasn't constantly
interrupted by other things, that he had the necessary
resources, etc. The person should be proud of what he has done,
but proud of it as a contribution to a team effort.

A good analogy might be American football. A person who scores
a touchdown can be proud, but so can the person who blocked for
him. And neither should think he did it himself, or there soon
won't be anything for anyone on the team to be proud of.

 

[James Kanze]

I find though that in the early stages of a project, with a
team that has not established its standards, someone needs to
guide the process by being the Nazi, at least for a while.

Not by being a Nazi; that never really works. But you do
normally need someone who will step up and build a consensus;
it doesn't happen by itself.

Otherwise you end up with a bunch of code that's all patchwork
looking.

Also, new members need to be pushed in the right direction in
the case of a well established project and team.

But pushed in the right fashion. You can't impose
responsibility; you can only work to create an environment where
it happens.

Interestingly enough, most people are team players, at heart.
They want to be appreciated, even esteamed by their colleagues
and bosses. If the environment is such that co-operation and
team play (including following guidelines) leads to appreciation
and esteam, most people will co-operate and play a team game
very quickly. The problem for management is to create the
original atmosphere ("ambiance" in French, "Stimmung" in
German---again, I'm not 100% sure of the English word).

There's also some issues that really need immediate standard.
TABS vs. Spaces for instance...you just can't let that one
go. It seems trivial but when people decide on different
answers to that question, and different sizes of
indentation...it just gets messy.

Certainly. But you're not going to be pounding out code from
the first day, either. The very first thing you do on a new
project is build a team. That means defining the rules under
which you're going to work together. If Ian and I were to work
together, for example, before I started my first requirements
specification or he started writing his first test (since he
believes in test driven design), we'd sit down with the other
members of the team, and decide what role requirements
specifications and tests should have in our development process.
More important even than the actual choice is the fact that
everyone finds it acceptable, and is prepared to live with it.
A first draft of the coding guidelines (including the tab's vs
spaces issue, generally---although I've never seen a guideline
that tolerated tabs) should be available before the first line
of code is written.

Another reason to have standards is that sometimes they
actually help people who don't really have a good idea what
their own opinion is. Like with more complex template
declarations...many people simply don't have a good idea how
to format that kind of thing.

Generally speaking, people who have little experience in
something should defer to those who have a lot. Most of the
time, anyway. Again, in practice, I find that they usually do,
when management has created a good "atmosphere".

 

[James Kanze]

Oh, we have a long way to get back on topic. After all, this
thread should be about the ways of converting a string to
lower case. (The result so far seems that one cannot rely on
locales doing the right thing and using the C-functions is
tricky.)

On topic for the thread, maybe. I think he meant on topic for
the group. (I don't think hyphenation is really a C++ issue.
Unless, of course, you're using it as a C++ symbol. In which
case, it shouldn't be hyphenated.)

 

[Ian Collins]

I don't know where you get that. All of the code which I've
worked on professionally has been done as a work for hire. The
company who paid for it owned it, and the people who wrote it
had pretty much no say with regards to what was done with it.

I think we are in agreement here and arguing at cross purposes.

I don't mean legal ownership, "controls" or "is responsible" or even
"guards with his life" might be better terms. Or maybe you have never
worked in a shop where modules or libraries are controlled by
individuals. Places where you can't change "Fred's code", you have to
ask Fred to make the changes.

Arguments, like projects need a common metaphor!

 

[Noah Roberts]

I don't mean legal ownership, "controls" or "is responsible" or even
"guards with his life" might be better terms. Or maybe you have never
worked in a shop where modules or libraries are controlled by
individuals. Places where you can't change "Fred's code", you have to
ask Fred to make the changes.

Arguments, like projects need a common metaphor!

Emotionally invested.

It works more than just in code too. It's important all around. When
you get the employees to feel like they own the company they're more
likely to go above and beyond...and not feel like they're being used for it.

The place I work for now does a pretty good job of that.

 

[James Kanze]

I think we are in agreement here and arguing at cross purposes.

I don't mean legal ownership,

I realize that, but it's not clear to me what you do mean.

"controls" or "is responsible" or even "guards with his life"
might be better terms.

I rather expect the person who checks in something to "be
responsible" for what he's done. In well run shops, management
will generally delegate "control" to the team, but a lot of the
time, it's more rule by decree: management decides, and everyone
else has to follow suite.

Or maybe you have never worked in a shop where modules or
libraries are controlled by individuals. Places where you
can't change "Fred's code", you have to ask Fred to make the
changes.

Are you kidding. I've never seen management which would allow
that: giving up power to an individual programmer, with nothing
in return. It just goes against human nature. (I have seen
programmers, or groups of programmers, try to establish such
conditions. But never successfully, at least not for long.)

 

[Ian Collins]

Are you kidding. I've never seen management which would allow
that: giving up power to an individual programmer, with nothing
in return. It just goes against human nature. (I have seen
programmers, or groups of programmers, try to establish such
conditions. But never successfully, at least not for long.)

You have had a sheltered life!

 

[Ian Collins]

If I weren't allowed to use Vim, I literally would quit. I do not say
that lightly.

I didn't force them, it was their choice.