By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,659 Members | 1,689 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,659 IT Pros & Developers. It's quick & easy.

.h for standard headers

P: n/a
At what point was the .h dropped from the STL headers? I just had a
discussion yesterday with my boss, who said he wanted .h on all the
STL includes, despite me protesting that it was not standard...

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Jul 22 '05
Share this Question
Share on Google+
71 Replies


P: n/a
"Jeff Schwab" <je******@comcast.net> wrote in message
news:ip********************@comcast.com...
What other sorts of files do you store in your "include" directories?

So you're telling me that I shouldn't have the problem I have if only
my work habits were correct? That's the usual (non)defense of somebody
who either doesn't see the problem or doesn't want to admit it exists.


:) I'm not telling you anything, I'm asking you a question. If your
point is that, theoretically, somebody could be storing other stuff in
the standard "include" directory, and that the same people may
subsequently whine that their environment is cluttered, then you got me.
The cat's out of the bag; the traditional file-based C++ development
model is open to abuse!


So you *are* telling me that I have bad work habits, however much you
pretend otherwise. Noted.
As someone who develops libraries all the time, I often have mixes of
"standard" headers and other code in the same directory for periods
of time. With the C headers, I can grep all of them with no fear of
sweeping up an odd assortment of executables, etc. in the process.
That's not so easy with the new C++ headers, and it's a real loss,
IMO, for no real gain.


What do you mean "standard" headers? When you're implementing the
standard C++ headers, just keep a subdirectory full of symlinks to the
standard headers, and grep through $subdir/*.


Say, thanks for telling me how to do my job. Now that you've
defined my problem in terms of "clutter" and "abuse" I see
that it really doesn't exist at all.
If you're developing some
other set of headers, you can call them whatever you like; mine end in
".hh".


Next time I develop extensions to Standard C++, I'll suggest that
we give all future headers a .hh suffix. Unfortunately, the current
contract I'm working under has already decided that I must use
unsuffixed names.
sometimes have a README file, but it's easy enough to wrap its contents
in /* */.

I suppose this is a relevant comment, but I can't imagine how.


Think harder.


Your work habits are not mine.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Jul 22 '05 #51

P: n/a
P.J. Plauger wrote:
"Jeff Schwab" <je******@comcast.net> wrote in message
news:ip********************@comcast.com...

What other sorts of files do you store in your "include" directories?
So you're telling me that I shouldn't have the problem I have if only
my work habits were correct? That's the usual (non)defense of somebody
who either doesn't see the problem or doesn't want to admit it exists.


:) I'm not telling you anything, I'm asking you a question. If your
point is that, theoretically, somebody could be storing other stuff in
the standard "include" directory, and that the same people may
subsequently whine that their environment is cluttered, then you got me.
The cat's out of the bag; the traditional file-based C++ development
model is open to abuse!

So you *are* telling me that I have bad work habits, however much you
pretend otherwise. Noted.

As someone who develops libraries all the time, I often have mixes of
"standard" headers and other code in the same directory for periods
of time. With the C headers, I can grep all of them with no fear of
sweeping up an odd assortment of executables, etc. in the process.
That's not so easy with the new C++ headers, and it's a real loss,
IMO, for no real gain.


What do you mean "standard" headers? When you're implementing the
standard C++ headers, just keep a subdirectory full of symlinks to the
standard headers, and grep through $subdir/*.

Say, thanks for telling me how to do my job. Now that you've
defined my problem in terms of "clutter" and "abuse" I see
that it really doesn't exist at all.

If you're developing some
other set of headers, you can call them whatever you like; mine end in
".hh".

Next time I develop extensions to Standard C++, I'll suggest that
we give all future headers a .hh suffix. Unfortunately, the current
contract I'm working under has already decided that I must use
unsuffixed names.

sometimes have a README file, but it's easy enough to wrap its contents
in /* */.
I suppose this is a relevant comment, but I can't imagine how.


Think harder.

Your work habits are not mine.

PJ, I'm not attacking you personally in any way. All I know about your
work habits is what you've told this group, and what I've read in CUJ;
I'm not trying to criticize you or your techniques. I see that from
your point of view, the move to extensionless standard headers caused an
unpleasant change. Things that used to work stopped working. I'm sorry
for this.

To be frank, though, I think that the removal of filename extensions
from the standard headers was the right move. It helps decouple C++
from any particular development model or file system. C++ developers
working with particular IDE's or sets of platforms can still use
whatever conventions are appropriate. Ways of working with the standard
headers in the same way one works with other headers are readily
available, using links, shortcuts, or other platform-specific techniques.

I'm certainly not trying to tell you your job; I don't have anything
like the depth of experience that you do. I do however think that file
naming conventions have little or no place in the C++ standard. If you
are working on some other set of libraries, and (as you said above) are
forced to used extensionless headers for them, it's an issue with that
contract, not the C++ standard.
Jul 22 '05 #52

P: n/a
"Jeff Schwab" <je******@comcast.net> wrote in message
news:aO********************@comcast.com...
Your work habits are not mine.

PJ, I'm not attacking you personally in any way. All I know about your
work habits is what you've told this group, and what I've read in CUJ;
I'm not trying to criticize you or your techniques.


Use of the terms "whine", "cluttered", and "abuse" are pejorative.
Thanks for clarifying your goal, but I encourage you to be a bit
more careful in how you achieve it in future.
I see that from
your point of view, the move to extensionless standard headers caused an
unpleasant change. Things that used to work stopped working. I'm sorry
for this.
Thanks. Me too.
To be frank, though, I think that the removal of filename extensions
from the standard headers was the right move. It helps decouple C++
from any particular development model or file system. C++ developers
working with particular IDE's or sets of platforms can still use
whatever conventions are appropriate. Ways of working with the standard
headers in the same way one works with other headers are readily
available, using links, shortcuts, or other platform-specific techniques.
None of what you say is improved in any way that I can see by the
removal of filename extensions. Given that *.h headers had been in
use for roughly a quarter century when the committee decided to
remove them, and given that they continue to be used as C headers,
it's hard to argue that any existing platform would be inconvenienced
by retaining them. OTOH, the C++ committee violated its charter, in
part, by breaking with past practice. There are many ways they could
have achieved their stated goals without eliminating filename
suffixes altogether. (I do accept the fact that they did. I only
complain when the topic rears up anew, as it does from time to time,
as part of the overall discussion.)
I'm certainly not trying to tell you your job; I don't have anything
like the depth of experience that you do. I do however think that file
naming conventions have little or no place in the C++ standard.
And I think they're one of the central aspects of the C++ Standard.
We certainly give a lot of thought to consistent header naming for
each new proposed addition (and did so during the drafting of the
original standard).
If you
are working on some other set of libraries, and (as you said above) are
forced to used extensionless headers for them, it's an issue with that
contract, not the C++ standard.


Except that this particular part of the contract is written that way
*because* of the decision made by the C++ committee. That decision
also circumscribes the naming options for all sorts of headers being
proposed with various Technical Reports, all of which Dinkumware is
implementing. This is *not* a problem confined to a fixed set of
files ghettoized in their own private directory. Certainly not for
us, and often not for others. (But see separate reply for more details.)

I'm truly happy that this change has little or no effect on your work
habits. That means it's less disruptive than I first feared.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Jul 22 '05 #53

P: n/a
"Jeff Schwab" <je******@comcast.net> wrote in message
news:8Y********************@comcast.com...
Julie wrote:
Let's try a different tack:

- What was K&R's original intention of appending .h to includes?
To make the types of files readily apparent to people and tools.


Still a good goal.
- Why is that intention no longer considered valid w/ C++ standard

includes?
Because a different solution has now become virtually universal: the
standard includes are stored in a dedicated directory.


Yep, but They Are Not Alone. I just checked half a dozen compilers I
use on a regular bases, on my Windows laptop, a Linux system, and a
Solaris system. *Every one of them* had other files in the same directory
as the C++ headers. If you try to grep the headers for a given name,
there's no easy way to eliminate:

-- binary files, such as DLLs

-- subdirectories

-- supplemental "internal" headers with funny suffixes

all of which generate garbage, long search times, and/or false positives.
Maybe this is Bad Practice (TM) on the part of the tool packagers,
but it's damn near universal.

IME, grepping include files is not a practice reserved to a handful
of us library vendors. Everybody I know does it all the time. And
it's now appreciably less productive since include/*.h no longer
does the job.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Jul 22 '05 #54

P: n/a
Rolf Magnus wrote:
This is not about Windows. It's about a concept that (among others)
Windows just happens to use.
or dismiss this as not a problem, but it still annoys me on a daily
basis.


It might be a problem, but I think it's not the C++ standard's task to
solve it.


Rolf -- please pay attention.

The committee _CREATED_ the problem by changing the de facto standard of .h for
library includes.
Jul 22 '05 #55

P: n/a
Jeff Schwab wrote:

Julie wrote:
Let's try a different tack:

- What was K&R's original intention of appending .h to includes?


To make the types of files readily apparent to people and tools.
- Why is that intention no longer considered valid w/ C++ standard includes?


Because a different solution has now become virtually universal: the
standard includes are stored in a dedicated directory.


Game, set, match.

The change from having the file type defined by the extension (context _free_)
to file type defined by file location (context _sensitive_) is a FUNDAMENTAL
change that honestly I think the C++ std committee didn't have the authority to
change. This change wasn't a standardization, but a _DE_standardization -- the
de facto standard regarding .h had been set years prior, and the committee
undid that.

I'd like to hear from anyone that has _BENEFITED_ from the change to
extensionless headers.
Jul 22 '05 #56

P: n/a

"Old Wolf" <ol*****@inspire.net.nz> wrote in message
news:84**************************@posting.google.c om...
"Duane Hebert" <sp**@flarn2.com> wrote:
grep "somefunctionname" *.h is a sight better than grep
"somefunctionname" *.* when I'm looking for a function
declaration in a header file.


"grep foo *.*" will not find things in files that don't contain a dot
(except on retarded filesystems). Why not list all your implementation's
standard headers into a file (that won't ever need to change), and then
you can go:

grep foo *.h `cat stdhdrs`

or make an alias or small script to do that. If you want to search
headers in many directories (eg. if you're working on a project with
3rd party libraries) regularly, you have to do something like this anyway.


How is any of this simpler than grep foo *.h ?
Jul 22 '05 #57

P: n/a
ol*****@inspire.net.nz (Old Wolf) wrote in message news:<84**************************@posting.google. com>...
"Tim Clacy" <no*******@nospamphaseone.nospamdk> wrote:
Christopher Benson-Manica wrote:
At what point was the .h dropped from the STL headers? I just had a
discussion yesterday with my boss, who said he wanted .h on all the
STL includes, despite me protesting that it was not standard...
Presumably the idea of omitting an extension was thought up by someone who
doesn't use Windows; we have lost the conveniences of double clicking to
open and meaningful icon associations in one fell swoop.


Whatever. The instruction

#include <iostream>

means that the functions and objects which form part of the iostream
library (as defined by the Standard) are now in scope (etc. etc. etc.)
There does not have to be any file "iostream", and in fact, the
implementation does not even have to have a filesystem.


As pjp has already remarked you are using a preprocessor directive not
an instruction.

On my Windows system there is in fact only the file "iostream.h",
which gets included when you issue the above instruction,
How do you know for sure about that? Does your iostream file has the
following

namespace std{
#include <iostream.h>
} and I can
still do the double-click trick (which, incidentally, I almost never
do, since I use a shell with tab completion).


--
Imanpreet Singh Arora
Jul 22 '05 #58

P: n/a
Julie <ju***@nospam.com> wrote in message news:<40***************@nospam.com>...
Let's try a different tack:

- What was K&R's original intention of appending .h to includes?

- Why is that intention no longer considered valid w/ C++ standard includes?

Well Andrew Koenig in AC++ on page 66-67 says that

<quote>
The reason is[Why we refer to our own headers as header files and
implementation supplied headers as standard headers rather than
standard header files] that header files are genuine files in every
C++ implementation, but system headers need not be implemented as
files.
</quote>
I am not quite sure about this, I haven't worked on am implementation
on which header files are NOT implemented as files(Database
Systems(?)). But I believe that any implmentation that supports system
headers to be stored in a format other than in files IMO must support
storing/using/saving header files in non file format.

Why have a non suffix system headers but not non suffix header files.

--
Imanpreet Singh Arora
i"kaur" At acm DOT org
Replace "kaur" by "singh"
Jul 22 '05 #59

P: n/a
"P.J. Plauger" <pj*@dinkumware.com> wrote:
"Old Wolf" <ol*****@inspire.net.nz> wrote:

Whatever. The instruction

#include <iostream>

means that the functions and objects which form part of the iostream
library (as defined by the Standard) are now in scope (etc. etc. etc.)


Uh, yes. But what does that have to do with omitting the suffix?


The point is, it is not a requirement that the thing in between
the < > be an actual file on the system, as evinced by my one
(Borland C++Builder 5 (with Rogue Wave)). There are in fact no
files without extensions, if you look in the system include directory.
On my Windows system there is in fact only the file "iostream.h",
which gets included when you issue the above instruction,


It's actually a preprocessing directive, FWIW. You must have an
unusual compiler, because all the ones I use on Windows consider
iostream.h to be the pre-standard legacy version of iostreams.
The file iostream is the one that gets read by the include you
show above.


If you write "#include <iostream.h>" you get the legacy crap. If
you write "#include <iostream>" you get the standard stuff.
Obviously the system does a bit of 'beind the scenes' stuff when
you write "#include <iostream>" (I imagine it would be something
like: enter namespace std, define some macros, and then open the
file iostream.h, and so on, you probably have a better idea of
this than I do).

The same goes for all the standard headers. Some of the other files
in the system include dir:
cctype.h
iterator.h
function.h (corresponds to #include <functional>)
algorith.h (corresponds to #include <algorithm>)
string.h (corresponds to #include <string.h>)
string.stl (corresponds to #include <string>)

You get the idea.
Jul 22 '05 #60

P: n/a
"Old Wolf" <ol*****@inspire.net.nz> wrote in message
news:84**************************@posting.google.c om...
"P.J. Plauger" <pj*@dinkumware.com> wrote:
"Old Wolf" <ol*****@inspire.net.nz> wrote:
Whatever. The instruction

#include <iostream>

means that the functions and objects which form part of the iostream
library (as defined by the Standard) are now in scope (etc. etc. etc.)


Uh, yes. But what does that have to do with omitting the suffix?


The point is, it is not a requirement that the thing in between
the < > be an actual file on the system,


Well, yes. But the same rule is in Standard C, which kept the .h
suffixes. So this *still* has nothing to do with omitting the
suffix.
as evinced by my one
(Borland C++Builder 5 (with Rogue Wave)). There are in fact no
files without extensions, if you look in the system include directory.
Oh, I've looked long and hard at the Borland packaging. It's gotten
better, but there for a while it was so determined to remap suffixes
that us third-party library vendors didn't have a chance at
selectively displacing parts of the library. Sun went through
much the same exercise. It's telling that both have backed down
considerably from their earlier positions.
On my Windows system there is in fact only the file "iostream.h",
which gets included when you issue the above instruction,


It's actually a preprocessing directive, FWIW. You must have an
unusual compiler, because all the ones I use on Windows consider
iostream.h to be the pre-standard legacy version of iostreams.
The file iostream is the one that gets read by the include you
show above.


If you write "#include <iostream.h>" you get the legacy crap. If
you write "#include <iostream>" you get the standard stuff.
Obviously the system does a bit of 'beind the scenes' stuff when
you write "#include <iostream>" (I imagine it would be something
like: enter namespace std, define some macros, and then open the
file iostream.h, and so on, you probably have a better idea of
this than I do).


What you have to do to deliver standard-conforming C++ is way
more complex than you've outlined.
The same goes for all the standard headers. Some of the other files
in the system include dir:
cctype.h
iterator.h
function.h (corresponds to #include <functional>)
algorith.h (corresponds to #include <algorithm>)
string.h (corresponds to #include <string.h>)
string.stl (corresponds to #include <string>)

You get the idea.


Yeah, I do. Borland's packaging is *not* compelling evidence
that omitting the .h from the Standard C++ headers leads tp
better technology.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Jul 22 '05 #61

P: n/a
Minti wrote:
Why have a non suffix system headers but not non suffix header files.


#include <babalooie>

as well as

#include <babalooie.xyz>

will work just fine.
There is nothing magic about ".h". In fact, many people use .H or .hpp
or .h++ or something else.
Jul 22 '05 #62

P: n/a
"Bill Seurer" <se****@us.ibm.com> wrote in message
news:c8***********@news.rchland.ibm.com...
Minti wrote:
Why have a non suffix system headers but not non suffix header files.
#include <babalooie>

as well as

#include <babalooie.xyz>

will work just fine.
There is nothing magic about ".h".


You mean, aside from the fact that it has been used to designate
C headers for over 30 years? Or that it is still used for header
names mandated by both the C and C++ Standards?
In fact, many people use .H or .hpp
or .h++ or something else.


Yes, "many people" do. But we're talking about what the C++ Standard
mandates, which is suffix-less header names. Moreover, it does *not*
mandate that these names be mapped into names with nice suffixes,
so most preprocessors simply take the header name as the filename
in one or more candidate include directories. The real-life
situation is thus that the world is now awash with filenames that
lack suffixes, while most shells are geared toward naming groups
with wildcards that are *much* easier to write for names with a
common suffix. And developers *do* have occasion to want to name
all the C++ headers as a group.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Jul 22 '05 #63

P: n/a
The standard does NOT dictate how headers are stored on your system.
<iostream> is a header, not a header file. A header is just an
abstraction that guarantees that the required declarations are
available, not necessarily mapping to a disk file. If your system
stores header in an inconvenient manner, the standard cannot solve
that problem. C++ is a cross-platform, system-independent language.
Why should it be guided by Windows' file conventions?

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
To iterate is human, to recurse divine.
-L. Peter Deutsch
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Jul 22 '05 #64

P: n/a
Prateek R Karandikar wrote:

The standard does NOT dictate how headers are stored on your system.
<iostream> is a header, not a header file. A header is just an
abstraction that guarantees that the required declarations are
available, not necessarily mapping to a disk file. If your system
stores header in an inconvenient manner, the standard cannot solve
that problem. C++ is a cross-platform, system-independent language.
Why should it be guided by Windows' file conventions?


For the informed, this is *NOT* a discussion about Windows (or any other
specific) OS issue.

It is about the inappropriate change of a de facto standard of a .h header
suffix by the C++ standards committee.
Jul 22 '05 #65

P: n/a
> It is about the inappropriate change of a de facto standard of a .h header
suffix by the C++ standards committee.


Your opinion on the standard comitee's decision to drop the .h extension
from the headers doesn't make the chane an inappropriate one. I like
the fact that standard headers don't have an extension.

JLR
Jul 22 '05 #66

P: n/a

"Jorge Rivera" <jo*****@rochester.rr.com> wrote in message
news:%f*******************@twister.nyroc.rr.com...
It is about the inappropriate change of a de facto standard of a .h header suffix by the C++ standards committee.


Your opinion on the standard comitee's decision to drop the .h extension
from the headers doesn't make the chane an inappropriate one. I like
the fact that standard headers don't have an extension.

JLR


That's nice. Does your opinion make it an appropriate change?

One of the main contributors to this thread was apparently on the committee
that made the decision, and he disagrees with it. And many of us agree.

What was gained by the decision? (And I'm wondering...why *do* you like
it..because you don't have that whopping extra workload of typing in .h
after the name?)

It changed the way it had been done for ages, and resulted in problems for
many of us. Am I incorrect on either of those points?

-Howard
Jul 22 '05 #67

P: n/a
> It changed the way it had been done for ages, and resulted in problems for
many of us. Am I incorrect on either of those points?


I am not interested in what's correct or not. Do you think changing it
back will be any better?

I like it because anywhere I see something without a .h, typically it
means I am using a standard header. Anything else is not standard C++.
Hence I don't have to carefully check each file to look for non
standard additions.

I do understand the pain involved in the change. All I'm saying is that
I like it. A judgement of "inappropiate" comes usually from the fact
that someone doesn't like it. Who cares how many people in the comitee
dind't like this idea? The majority did, and so it is. Deal with it.

JLR
Jul 22 '05 #68

P: n/a
"Jorge Rivera" <jo*****@rochester.rr.com> wrote in message
news:5C********************@twister.nyroc.rr.com.. .
It changed the way it had been done for ages, and resulted in problems for many of us. Am I incorrect on either of those points?

I am not interested in what's correct or not. Do you think changing it
back will be any better?

I like it because anywhere I see something without a .h, typically it
means I am using a standard header. Anything else is not standard C++.


Like assert.h, ctype.h, errno.h, float.h, iso646.h, limits.h, locale.h,
math.h, setjmp.h, signal.h, stdarg.h, stddef.h, stdio.h, stdlib.h,
string.h, time.h, wchar.h, or wctype.h? An implementation that *fails*
to provide any of these headers is not Standard C++. Good rule.
Hence I don't have to carefully check each file to look for non
standard additions.
Like project1st, project2nd, select1st, select2nd, iota, etc. etc.?
I've found all of these, and then some, in those "standard" headers
with no suffixes. Another good rule.
I do understand the pain involved in the change. All I'm saying is that
I like it. A judgement of "inappropiate" comes usually from the fact
that someone doesn't like it.
Not entirely. It also comes from a failure of the committee to "codify
existing practice." That's a legitimate gripe, particularly because
on practically every occasion where WG21 abandoned existing practice,
they've caused on-going pain.
Who cares how many people in the comitee
dind't like this idea? The majority did, and so it is. Deal with it.


That part I agree with. I accept majority rule and I deal with it
on a daily basis. IMO, most of this thread has been about some
people pretending there is no problem, or defining it out of
existence, and others (like me) doggedly explaining that there
*is* a problem and it won't go away. I'd be the last person to
suggest, at this late date, that we change the C++ Standard in
an attempt to undo the damage. It would only cause more. And
I note that none of the other "complainers" are asking for a
change either.

OTOH, I've heard several reasons advanced for why this change
is a good idea, and I haven't heard one yet that I think
holds water. YMMV.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Jul 22 '05 #69

P: n/a
Bill Seurer <se****@us.ibm.com> wrote in message news:<c8***********@news.rchland.ibm.com>...
Minti wrote:
Why have a non suffix system headers but not non suffix header files.


#include <babalooie>

as well as

#include <babalooie.xyz>

will work just fine.
There is nothing magic about ".h". In fact, many people use .H or .hpp
or .h++ or something else.


Yes it could be even .cpp[ As has been used in case of Algorithms in
C++ by Sedgwick ], but the point is the emphasis shown in case of the
above quotes. Why emphasize that your headers are genuine header files
in every implementation, system headers aren't.
IMO the probablity of having non-suffix user headers is/should be the
same that of non-suffix system headers [ Which is 1.0 ].

If the standard wants to take away the suffix it should do it as a
whole.

I don't have the copy of standard right now on my desktop, but I am
quite sure it also uses .h as a suffix for denoting header files.

--
Imanpreet Singh Arora

isingh AT acm DOT org
Jul 22 '05 #70

P: n/a
Minti wrote:

Bill Seurer <se****@us.ibm.com> wrote in message news:<c8***********@news.rchland.ibm.com>...
Minti wrote:
Why have a non suffix system headers but not non suffix header files.
#include <babalooie>

as well as

#include <babalooie.xyz>

will work just fine.
There is nothing magic about ".h". In fact, many people use .H or .hpp
or .h++ or something else.


Yes it could be even .cpp[ As has been used in case of Algorithms in
C++ by Sedgwick ], but the point is the emphasis shown in case of the
above quotes. Why emphasize that your headers are genuine header files
in every implementation, system headers aren't.

IMO the probablity of having non-suffix user headers is/should be the
same that of non-suffix system headers [ Which is 1.0 ].


If the standard wants to take away the suffix it should do it as a
whole.


The standards committee exists for the *benefit* of the users (us), not the
other way around.

The standards committee is charged w/ purpose of making changes to the standard
that are in the best interest of the _community_. I'd like to hear one reason
where extensionless headers have BENEFITED the users (us), excluding
preferential opinions.

The standards committee usurped authority that it didn't have when making the
extensionless change. Fortunately the effects haven't had too negative of an
impact, but we (THE COMMUNITY) should be vigilant for other
unwarranted/unjustified changes to the standard that may have far greater
(negative) consequences...

Remember, the standards (and committee) exist for *OUR* benefit and pleasure.
Jul 22 '05 #71

P: n/a
Julie <ju***@nospam.com> wrote in news:40**************@nospam.com:

(...)
The standards committee exists for the *benefit* of the users (us),
not the other way around.

The standards committee is charged w/ purpose of making changes to the
standard that are in the best interest of the _community_. I'd like
to hear one reason where extensionless headers have BENEFITED the
users (us), excluding preferential opinions.

The standards committee usurped authority that it didn't have when
making the extensionless change. Fortunately the effects haven't had
too negative of an impact, but we (THE COMMUNITY) should be vigilant
for other unwarranted/unjustified changes to the standard that may
have far greater (negative) consequences...

Remember, the standards (and committee) exist for *OUR* benefit and
pleasure.


Actually it's characteristic to all collective efforts on decision making
(committees, governments, boards, etc...). That's how the world works.
There are bad decisions made by good people and vice versa. We just have
to live with it...

.... or ... we can put machines in charge...

Cheers.
Jul 22 '05 #72

71 Replies

This discussion thread is closed

Replies have been disabled for this discussion.