#include <string>
#include <iostream>
using std::cout;
using std::endl;
void FunctionThatModifies(std::string &a)
{
a = "You've been modified.";
}
int main()
{
std::string const a("Untouchable.");
std::string &b = a; //Actually compiles with error!
FunctionThatModifies(b);
std::cout << b;
}
Compiler gives me a warning. I think it should give me a downright error,
and I want it to give me a downright error.
Firstly, does the Standard say whether this should generate a warning or
an error?
Secondly, do compilers have an option whereby you can make it give an
error? If so, I'll be using it.
-Tomás
50  2661 
* Tomás: std::string const a("Untouchable.");
std::string &b = a; //Actually compiles with error!
Compiler gives me a warning. I think it should give me a downright error,
and I want it to give me a downright error.
It should not compile.
Firstly, does the Standard say whether this should generate a warning or
an error?
An error.
Secondly, do compilers have an option whereby you can make it give an
error? If so, I'll be using it.
Compiler options are compiler-specific; check your compiler's help text
and/or documentation.
--
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?
Tomás wrote:
Compiler gives me a warning. I think it should give me a downright error,
and I want it to give me a downright error.
Firstly, does the Standard say whether this should generate a warning or
an error?
It requires "a diagnostic." The standard doesn't talk about warnings and
errors.
Secondly, do compilers have an option whereby you can make it give an
error? If so, I'll be using it.
Many do.
--
Pete Becker
Roundhouse Consulting, Ltd.
Alf P. Steinbach wrote: Firstly, does the Standard say whether this should generate a warning
or an error?
An error.
The Standard requires "a diagnostic." It does not specify the form or
the consequences of that diagnostic, and it does not distinguish between
a "warning" and an "error."
--
Pete Becker
Roundhouse Consulting, Ltd. std::string &b = a; //Actually compiles with error!
God damn typo. Should've written:
Actuall compiles *without* error!
-Tomás
On Sun, 05 Mar 2006 09:37:52 -0500, Pete Becker wrote: Alf P. Steinbach wrote:
Firstly, does the Standard say whether this should generate a warning
or an error?
An error.
The Standard requires "a diagnostic." It does not specify the form or
the consequences of that diagnostic, and it does not distinguish between
a "warning" and an "error."
What is "a diagnostic"?
Joe Van Dyk wrote: On Sun, 05 Mar 2006 09:37:52 -0500, Pete Becker wrote:
Alf P. Steinbach wrote:
Firstly, does the Standard say whether this should generate a warning >>> or an error?
An error.
The Standard requires "a diagnostic." It does not specify the form
or the consequences of that diagnostic, and it does not distinguish
between a "warning" and an "error."
What is "a diagnostic"?
From the standard, under Terms and definitions:
1.3.2 diagnostic message
a message belonging to an implementation-defined subset of the
implementation's output messages.
Brian
"Default User" writes: What is "a diagnostic"?
From the standard, under Terms and definitions:
1.3.2 diagnostic message
a message belonging to an implementation-defined subset of the
implementation's output messages.
There must be a word for that. You actually know *less* after reading the
definition than you did before you read it!
In article <47************@individual.net>, r124c4u102
@comcast.net says...
[ ... ] There must be a word for that. You actually know *less* after reading the
definition than you did before you read it!
I don't agree that's the case here, but where it is I
think "Schildtism" would be an appropriate term.
--
Later,
Jerry.
The universe is a figment of its own imagination.
* Pete Becker: Alf P. Steinbach wrote: Firstly, does the Standard say whether this should generate a warning
or an error?
An error.
The Standard requires "a diagnostic." It does not specify the form or
the consequences of that diagnostic, and it does not distinguish between
a "warning" and an "error."
I didn't see this erronous nit-picking posting when you made it, but
I'll clear that up anyway.
The 1998 C++ standard contains 135 instances of "error" being used as a
synonym for "ill-formed".
I.e., you chose the wrong term to look up, you should have looked up
"ill-formed", not "diagnostic".
"Error" and "warning" are however not terms _defined_ by the standard.
They are terms used by actual compilers. "Error" means the program does
not compile, and "warning" means that at least that part of it compiles,
but with some probably dubious construct that may not do what you intended.
Just to repeat: the standard's official term corresponding to "error", a
program that does not compile, is not "diagnostic", it is "ill-formed"
--
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?
* Pete Becker: Tomás wrote:
Compiler gives me a warning. I think it should give me a downright
error, and I want it to give me a downright error.
Firstly, does the Standard say whether this should generate a warning
or an error?
It requires "a diagnostic." The standard doesn't talk about warnings and
errors.
It really does.
The 1998 C++ standard contains 135 instances of "error" being used as a
synonym for "ill-formed".
It also contains 1 usage of "warning", exemplifying that that is a term
it is assumed that readers of the standard should understand.
--
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?
"Default User" <de***********@yahoo.com> wrote in message
news:47************@individual.net... Joe Van Dyk wrote:
On Sun, 05 Mar 2006 09:37:52 -0500, Pete Becker wrote:
> Alf P. Steinbach wrote:
>
>
>>
>>> Firstly, does the Standard say whether this should generate a
warning >>> or an error? >>
>>
>> An error.
>>
>
> The Standard requires "a diagnostic." It does not specify the form
> or the consequences of that diagnostic, and it does not distinguish
> between a "warning" and an "error."
What is "a diagnostic"?
From the standard, under Terms and definitions:
1.3.2 diagnostic message
a message belonging to an implementation-defined subset of the
implementation's output messages.
Umm.. if I'm reading htat right, it basically says that a diagnostic message
is an output message. Not exactly specific is it?
* Jim Langston: * "Default User":
1.3.2 diagnostic message
a message belonging to an implementation-defined subset of the
implementation's output messages.
Umm.. if I'm reading htat right, it basically says that a diagnostic message
is an output message. Not exactly specific is it?
"diagnostic" isn't the part being defined, you're assumed to understand
what "diagnostic" means. What's defined, in a badly worded way, is that
a compiler ("translator" in the standard's terminology) is allowed to
output other messages than those corresponding to "requires a
diagnostic", including non-diagnostic messages. If you go the route of
trying to find definitions of common-sense terms you won't find a
definition of "translator" either, although the term is used.
--
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?
Alf P. Steinbach wrote:
Just to repeat: the standard's official term corresponding to "error", a
program that does not compile, is not "diagnostic", it is "ill-formed"
The standard does not require that anything not compile. An ill-formed
program requires a diagnostic. Nothing more.
--
Pete Becker
Roundhouse Consulting, Ltd.
Alf P. Steinbach wrote: * Pete Becker:
Tomás wrote:
Compiler gives me a warning. I think it should give me a downright
error, and I want it to give me a downright error.
Firstly, does the Standard say whether this should generate a warning
or an error?
It requires "a diagnostic." The standard doesn't talk about warnings
and errors.
It really does.
The 1998 C++ standard contains 135 instances of "error" being used as a
synonym for "ill-formed".
Nevertheless, it does not require "a warning" nor "an error" (not even
"a downright error") as used in the original message. Context matters.
It also contains 1 usage of "warning", exemplifying that that is a term
it is assumed that readers of the standard should understand.
The standard does not require "error" messages nor "warnings". It does
not require that anything not compile. The only requirement on
ill-formed programs is that the compiler issue a diagnostic.
--
Pete Becker
Roundhouse Consulting, Ltd.
Jim Langston wrote:
Umm.. if I'm reading htat right, it basically says that a diagnostic message
is an output message. Not exactly specific is it?
Nope. Could be text, could be beeps from the speaker, could be flashing
the screen. It's up to the implementation.
--
Pete Becker
Roundhouse Consulting, Ltd.
"Alf P. Steinbach" <al***@start.no> skrev i meddelandet
news:47************@individual.net...
"Error" and "warning" are however not terms _defined_ by the
standard. They are terms used by actual compilers. "Error" means
the program does not compile, and "warning" means that at least that
part of it compiles, but with some probably dubious construct that
may not do what you intended.
There is no requirement to compile the program, it could be
interpreted. :-)
Just to repeat: the standard's official term corresponding to
"error", a program that does not compile, is not "diagnostic", it is
"ill-formed"
Even if there is an "error" the translator can issue its diagnostic
(required), see that it was an obvious typo, and then continue with
the translation.
Bo Persson
osmium wrote: "Default User" writes:
What is "a diagnostic"?
From the standard, under Terms and definitions:
1.3.2 diagnostic message
a message belonging to an implementation-defined subset of the
implementation's output messages.
There must be a word for that. You actually know less after reading
the definition than you did before you read it!
Actually, it lets you know you all you're going to be able to tell
about it. A diagnostic is an output message. It's
implementation-defined, which means that the implementation must
document the messages. That's all you can count on. There's no talk of
"warnings" or "errors", no indication that compilation must continue or
stop.
Brian
Jim Langston wrote: "Default User" <de***********@yahoo.com> wrote in message
news:47************@individual.net... Joe Van Dyk wrote:
What is "a diagnostic"?
From the standard, under Terms and definitions:
1.3.2 diagnostic message
a message belonging to an implementation-defined subset of the
implementation's output messages.
Umm.. if I'm reading htat right, it basically says that a diagnostic
message is an output message. Not exactly specific is it?
The key is that it is implementation-defined. The implementation is
required to document the diagostics. Of course, that doesn't mean that
they have to be meaningful (and we've all seen some pretty obscure or
misleading messages). Printing, "your code sucks and so do you" for
every diagnostic would be perfectly within the standard.
Brian
* Pete Becker: Alf P. Steinbach wrote:
Just to repeat: the standard's official term corresponding to "error",
a program that does not compile, is not "diagnostic", it is "ill-formed"
The standard does not require that anything not compile. An ill-formed
program requires a diagnostic. Nothing more.
That is correct, at last.
--
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?
* Bo Persson: "Alf P. Steinbach" <al***@start.no> skrev i meddelandet
news:47************@individual.net... "Error" and "warning" are however not terms _defined_ by the
standard. They are terms used by actual compilers. "Error" means
the program does not compile, and "warning" means that at least that
part of it compiles, but with some probably dubious construct that
may not do what you intended.
There is no requirement to compile the program, it could be
interpreted. :-)
The standard simply assumes the reader is competent enough to understand
what's meant by e.g. "translation" and "error". Just to repeat: the standard's official term corresponding to
"error", a program that does not compile, is not "diagnostic", it is
"ill-formed"
Even if there is an "error" the translator can issue its diagnostic
(required), see that it was an obvious typo, and then continue with
the translation.
Most compilers -- unfortunately -- do. If they hadn't they could
have been superfast. The idea of continuing is some idiocy from the
1950's that compiler writers haven't managed to rid themselves of.
--
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?
* Pete Becker: The standard does not require "error" messages nor "warnings".
That is literally correct, it requires diagnostics.
It does not require that anything not compile.
That is literally correct, the word "compiler" occured just once in an
early version, then was removed.
The only requirement on
ill-formed programs is that the compiler issue a diagnostic.
And I think that is literally correct, too.
But this feels like talking to a robot.
All your comments are completely irrelevant. Do you not understand what
"error" means? Do you not understand the 135 relevant usages of that
word in the standard? Do you not understand what the OP asked?
--
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?
Bo Persson wrote:
Even if there is an "error" the translator can issue its diagnostic
(required), see that it was an obvious typo, and then continue with
the translation.
Or do whatever the implementor decides. The requirement for an
ill-formed program is only that the compiler issue a diagnostic. That's
the hook for implementation-specific extensions: the compiler issues a
diagnostic then handles the extension.
--
Pete Becker
Roundhouse Consulting, Ltd.
Alf P. Steinbach wrote:
All your comments are completely irrelevant. Do you not understand what
"error" means? Do you not understand the 135 relevant usages of that
word in the standard? Do you not understand what the OP asked?
To repeat the original question, which may have gotten lost in the noise:
Compiler gives me a warning. I think it should give me a downright error,
and I want it to give me a downright error.
Seems quite clear: he's disappointed that the compiler only gave a
warning message, he wants it to give an error message and decline to
compile the program. There is no such requirement in the language
definition. In particular, "It should not compile" is wrong.
--
Pete Becker
Roundhouse Consulting, Ltd.
* Pete Becker: Alf P. Steinbach wrote:
All your comments are completely irrelevant. Do you not understand
what "error" means? Do you not understand the 135 relevant usages of
that word in the standard? Do you not understand what the OP asked?
To repeat the original question, which may have gotten lost in the noise:
Compiler gives me a warning. I think it should give me a downright
error, and I want it to give me a downright error.
Seems quite clear: he's disappointed that the compiler only gave a
warning message, he wants it to give an error message and decline to
compile the program. There is no such requirement in the language
definition.
In one sense you're right about that.
Formally, a C++ compiler is free to compile ill-formed Visual Basic
source code, or a letter to mom.
As long as it issues some diagnostic, which could be as subtle as doing
absolutely nothing (the diagnostic in this case being the absence of a
toggling of the NumLock LED indicator on the keyboard, for example).
In particular, "It should not compile" is wrong.
Nope.
You have substituted a context where you interpret the question as to
what the standard literally requires of a compiler, which is nothing,
since the standard does not mention compilers; in particular, it does
not define that they are C++ implementations.
But let's assume that a compiler (plus runtime support, etc.) is a C++
implementation, and not just an implementation, but a conforming one.
Can that compiler accept an ill-formed program text? Yes, formally it
can, and you have stated that yourself. Can it decline to accept a
well-formed program text? Yes, formally it can, it can say, by not
blinking the keyboard's NumLock LED, "Sorry, I ran out of memory", or
whatever (the standard uses language such as "within its resource
limits" to cater for this possibility), and also because when you follow
requirements down into their most basic details, you must always find
them expressed using words that are not themselves defined by the
standard. Does the standard then place any real hard constraints on
this conforming implementation? Nope, none whatsoever.
In the literally formal, the viewpoint you have chosen, there is
therefore no such thing as a C++ implementation, because it could be
anything, and still literally satisfy the standard's rules.
Therefore that is /meaningless/.
--
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?
Alf P. Steinbach wrote:
Sigh. The original question asked, in part, Firstly, does the Standard say whether this should generate a warning or an error?
And you replied to that with:
An error.
Where in the standard did you find this?
--
Pete Becker
Roundhouse Consulting, Ltd.
osmium wrote: "Default User" writes:
What is "a diagnostic"?
From the standard, under Terms and definitions:
1.3.2 diagnostic message
a message belonging to an implementation-defined subset of the
implementation's output messages.
There must be a word for that. You actually know *less* after reading the
definition than you did before you read it!
You know that an implementation has output messages, and that not all
of them are necessarily considered diagnostics.
The implementation defines which messages are diagnostics, which means
that there has to be an accompanying document that lists them or
indicates how they can be recognized from among other messages.
When the standard requires a situation to be diagnosed, one of these
messages must appear from the implementation.
* Pete Becker: Alf P. Steinbach wrote:
Sigh. The original question asked, in part,
Firstly, does the Standard say whether this should generate a warning
or an error?
And you replied to that with:
An error.
Where in the standard did you find this?
By now you should have understood what "error" means, as the word is
used in the standard and by the OP.
But I'll explain it once more: it means "ill-formed".
Regarding the standard's rules for cv-qualification and conversions, I
don't think it's true that you're unable to find them. I don't think
your question is truthful, I think it is argumentative. However, for
the sake of discussion I'll /assume/ that your question is truthful,
that you really want a little help here.
A quick search now yielded that a very similar example is given at the
end §8.5.3/5 with the explanation "error: type qualifiers dropped". You
should understand that I did not consult the standard regarding the
original question, and in particular I did not check out this example,
which I now have provided on your direct request. The question was and
is basic, trivial, and it's just coincidental that this example exists.
But in spite of my assumption above, I'm sure that if you respond it
will be along the lines of examples in the standard not being normative,
or some such context-switching and literal-minded irrelevant argument,
at a stroke rendering all 135 examples meaningless to win a discussion.
--
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?
Alf P. Steinbach wrote: * Pete Becker:
Alf P. Steinbach wrote:
Sigh. The original question asked, in part,
Firstly, does the Standard say whether this should generate a
warning or an error?
And you replied to that with:
An error.
Where in the standard did you find this?
By now you should have understood what "error" means, as the word is
used in the standard and by the OP.
Again: the OP asked whether this should "generate a warning or an error".
But I'll explain it once more: it means "ill-formed".
I see. So your answer to the question whether that should "generate a
warning or an error" is that it should "generate an ill-formed".
Regarding the standard's rules for cv-qualification and conversions, I
don't think it's true that you're unable to find them.
I didn't say anything about the rules for cv-qualification. I asked you
where you found a requirement to issue an error message rather than a
warning, since that's what the question explicitly asked about.
--
Pete Becker
Roundhouse Consulting, Ltd.
* Pete Becker: Alf P. Steinbach wrote: * Pete Becker:
Alf P. Steinbach wrote:
Sigh. The original question asked, in part,
> Firstly, does the Standard say whether this should generate a
> warning or an error?
And you replied to that with:
An error.
Where in the standard did you find this?
By now you should have understood what "error" means, as the word is
used in the standard and by the OP.
Again: the OP asked whether this should "generate a warning or an error".
But I'll explain it once more: it means "ill-formed".
I see. So your answer to the question whether that should "generate a
warning or an error" is that it should "generate an ill-formed".
Is that a question? Regarding the standard's rules for cv-qualification and conversions, I
don't think it's true that you're unable to find them.
I didn't say anything about the rules for cv-qualification. I asked you
where you found a requirement to issue an error message rather than a
warning, since that's what the question explicitly asked about.
It might seem, from this posting, that you still haven't understood what
"error" means.
But you snippped the standard's example I gave in response to your
question, which to my mind means you now really do understand what
"error" means as used in the standard and by the OP, and that you are
now just obstinately argumentative.
With "error" meaning "ill-formed", the meaning of "warning" is easy to
deduce, given the definition of "diagnostic": it is the set of other
possible diagnostics. Current compilers label them as warnings. Given
that, you don't need to deduce the meaning: you should already know it.
--
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?
Alf P. Steinbach wrote: With "error" meaning "ill-formed", the meaning of "warning" is easy
to > deduce, given the definition of "diagnostic": it is the set of other possible diagnostics. Current compilers label them as warnings.
Remarkable. You've turned no normative words in the standard into a
requirement that no compiler conforms to.
Once again, for the benefit of anyone who may still be reading this
well-named thread: the C++ Standard requires "a diagnostic" for an
ill-formed program. That's all.
--
Pete Becker
Roundhouse Consulting, Ltd.
Pete Becker wrote:
Once again, for the benefit of anyone who may still be reading this
well-named thread: the C++ Standard requires "a diagnostic" for an
ill-formed program. That's all.
Whoops, it requires less than that. It requires "a diagnostic message"
for a program that violates any diagnosable rule. Some of the rule whose
violation makes a program ill-formed are not diagnosable rules.
--
Pete Becker
Roundhouse Consulting, Ltd.
* Pete Becker: Alf P. Steinbach wrote: > With "error" meaning "ill-formed", the meaning of "warning" is easy to > deduce, given the definition of "diagnostic": it is the set of other > possible diagnostics. Current compilers label them as warnings.
Remarkable. You've turned no normative words in the standard into a
requirement that no compiler conforms to.
That's incorrect in several ways.
Including that your statement is at odds with reality: most modern
compilers do issue compilation errors for the OP's construct.
But the most basic error in your statement is the flawed deduction that
a compiler that compiles the OP's source code can be conforming, in any
practical sense.
A compiler that compiles that is not conforming in any practical sense.
Are you still going on about what you can deduce from literal
definitions, ignoring reality and context? As should be clear by now,
that's /nothing/. The C++ standard is not a completely formal document,
nor could it be, and so via the literal interpretation rule you end up
with undefined words (like "diagnostic"), always; moreover, with the
literal interpretation the standard is formally inconsistent in several
places, and nothing (or anything at all, depending on your preferences)
can be deduced from inconsistency, which is a well-known fallacy.
Once again, for the benefit of anyone who may still be reading this
well-named thread: the C++ Standard requires "a diagnostic" for an
ill-formed program. That's all.
Yes. And the C++ standard differentiates between different kinds of
diagnostics. And includes at least one example, shown earlier, where
this particular kind of ill-formedness is labeled an "error".
--
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?
Alf P. Steinbach wrote:
But the most basic error in your statement is the flawed deduction that
a compiler that compiles the OP's source code can be conforming, in any
practical sense.
There's no deduction involved. The standard requires the implementation
to issue a diagnostic. It did.
--
Pete Becker
Roundhouse Consulting, Ltd.
In article <47************@individual.net>, al***@start.no says...
[ ... ] By now you should have understood what "error" means, as the word is
used in the standard and by the OP.
But I'll explain it once more: it means "ill-formed".
Sorry Alf, but here you're just plain wrong.
The standard (at least generally) uses phrasing like "it
is an error if ..." to mean something like "code is ill
formed if ...", that much is true.
The OP, in strong contrast, was clearly using "error" to
mean an error message. Specifically, that the code in
question would NOT be successfully translated.
The standard does not require any such thing under any
circumstances.
The standard requires the implementation to issue a
diagnostic message if any diagnosable rule is violated.
The standard defines the diagnosable rules, and requires
the implementation to define what it considers a
diagnostic.
The marketplace, not the standard, decides anything
beyond that. In particular, most compilers (including the
OP's, apparently) issue a warning for his code. Most
compilers also allow you to elevate warnings to be
treated as error messages (i.e. that code that produces
that message will not be successfully translated). Some
do so only on a blanket basis (i.e. all warnings are
treated as errors) while others allow more selectivity in
doing so -- i.e. you have greater granularity in choosing
which warnings will be treated as errors.
The details of that, however, are clearly specific to the
compiler and off-topic here though, because they have to
do with how you run the compiler, not with the language.
--
Later,
Jerry.
The universe is a figment of its own imagination.
* Jerry Coffin: In article <47************@individual.net>,
al***@start.no says...
[ ... ]
By now you should have understood what "error" means, as the word is
used in the standard and by the OP.
But I'll explain it once more: it means "ill-formed".
Sorry Alf, but here you're just plain wrong.
The standard (at least generally) uses phrasing like "it
is an error if ..." to mean something like "code is ill
formed if ...", that much is true.
The OP, in strong contrast, was clearly using "error" to
mean an error message. Specifically, that the code in
question would NOT be successfully translated.
The standard does not require any such thing under any
circumstances.
The standard requires the implementation to issue a
diagnostic message if any diagnosable rule is violated.
The standard defines the diagnosable rules, and requires
the implementation to define what it considers a
diagnostic.
The marketplace, not the standard, decides anything
beyond that. In particular, most compilers (including the
OP's, apparently) issue a warning for his code. Most
compilers also allow you to elevate warnings to be
treated as error messages (i.e. that code that produces
that message will not be successfully translated). Some
do so only on a blanket basis (i.e. all warnings are
treated as errors) while others allow more selectivity in
doing so -- i.e. you have greater granularity in choosing
which warnings will be treated as errors.
The details of that, however, are clearly specific to the
compiler and off-topic here though, because they have to
do with how you run the compiler, not with the language.
Apart from the phrasing "most compilers" (I really don't think that's
correct) the above sounds eminently reasonable.
It makes it seem as if it's just a matter of degree, outside the scope
of the standard; warning, error, one can be treated as the other,
they're all just diagnostics.
Until you consider the following seemingly conforming C++
implementation, which you can implement in a few minutes time using a
script language. It is a C++ implementation, let's call it OhLaLa
because it is 100% conforming, perfect!, that takes a C++ source file,
or fileset (translation unit that comprises a program), and executes it,
all according to the C++ standard's rules. It's done as follows:
1) If the source code compiles with no errors (output suppressed)
using a compiler B that compiles and only compiles well-formed
source code without errors, delete all result files and issue a
diagnostic "error: out of memory, sorry". This per the "available
resources" clause in §1.4/2 of the standard.
2) Otherwise, if B fails to compile the source code, issue a
diagnostic "warning: extension used", and run a program that spams
all heads of state in Europe (it will always be the same program)
and calls the OS' process exit function; which program, let's call
it S, constitutes the effect of the provided C++ source code. The
language extension is simply that any compilation failure using B
means that the effect of S should be prepended to the effect of the
code minimally adjusted, in some sense, so that it would compile
using B. This is per §1.4/8, which allows extensions that do not
alter the behavior of well-formed programs.
Effectively the OhLaLa C++ implementation is, as I see it, a 100%
conforming C++ implementation when all that's required is what a literal
reading of the standard imposes on a conforming implementation.
However, _I_ wouldn't call OhLaLa a conforming implementation. I would
not even call it a C++ implementation, since the C++ source code does
not influence any effect of submitting the source code to OhLaLa, other
than turning off the single pre-defined effect (and we could, if not for
dramatic impact, turn off that effect so that the C++ source code would
influence absolutely nothing). So as I see it there's something missing
from the literal interpretation picture, and it even begins to seem a
teeny tiny bit unreasonable, don't you think?
--
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?
In article <47************@individual.net>, al***@start.no says...
[ ... ] Apart from the phrasing "most compilers" (I really don't think that's
correct) the above sounds eminently reasonable.
Would you settle for "many compilers" instead? I haven't
tried to do a survey (especially in the embedded space
and such) so maybe I'm just deceived by the compilers I
happen to use, and falsely assume most of the others have
similar capabilities.
[ ... ]
Effectively the OhLaLa C++ implementation is, as I see it, a 100%
conforming C++ implementation when all that's required is what a literal
reading of the standard imposes on a conforming implementation.
In terms purely of conforming with the standard, I think
that's probably correct.
However, _I_ wouldn't call OhLaLa a conforming implementation. I would
not even call it a C++ implementation, since the C++ source code does
not influence any effect of submitting the source code to OhLaLa, other
than turning off the single pre-defined effect (and we could, if not for
dramatic impact, turn off that effect so that the C++ source code would
influence absolutely nothing). So as I see it there's something missing
from the literal interpretation picture, and it even begins to seem a
teeny tiny bit unreasonable, don't you think?
Actually, I think you could leave out most (all?) of
section 2 of your description of OhLaLa and still have a
conforming implementation of C++.
You seem to want the standard to require enough that a
conforming implementation at least stands some chance of
being useful. At one time I'd have agreed vehemently. I
can still sympathize, but can't really agree anymore. The
reason is simple: such rules would take considerable time
and effort to make, but I seriously doubt they'd make any
real difference. Right now Comeau is the only C++
compiler that makes a serious attempt at full conformance
(though rumor has it that Intel unofficially supports
export as well) At the same time, most compilers go well
beyond the requirements of the standard in terms of
attempting to provide useful warnings, error messages,
etc.
Given that I think it would take a lot of time and effort
and provide no real benefit, I think I'd rather see time
spent on endeavors I think would be more fruitful.
I don't believe, however, that just because the standard
makes no meaningful requirements in a given area that we
can treat it as requiring things that just aren't there.
If you're really convinced that the standard _should_
have stronger requirements in this area, the obvious
thing to do would be to write up a proposal, and submit
it to the committee. It wouldn't be a new language
feature, so I believe the committee would still accept it
as a proposal for the next version of the standard. I
really think it's a waste of time though -- there are
enough good compilers being given away freely today that
I really don't think stopping a useless one from being
able to claim it's conforming would really accomplish
much.
--
Later,
Jerry.
The universe is a figment of its own imagination.
* Jerry Coffin: In article <47************@individual.net>,
al***@start.no says...
[ ... ]
Apart from the phrasing "most compilers" (I really don't think that's
correct) the above sounds eminently reasonable.
Would you settle for "many compilers" instead? I haven't
tried to do a survey (especially in the embedded space
and such) so maybe I'm just deceived by the compilers I
happen to use, and falsely assume most of the others have
similar capabilities.
[ ... ]
Effectively the OhLaLa C++ implementation is, as I see it, a 100%
conforming C++ implementation when all that's required is what a literal
reading of the standard imposes on a conforming implementation.
In terms purely of conforming with the standard, I think
that's probably correct.
However, _I_ wouldn't call OhLaLa a conforming implementation. I would
not even call it a C++ implementation, since the C++ source code does
not influence any effect of submitting the source code to OhLaLa, other
than turning off the single pre-defined effect (and we could, if not for
dramatic impact, turn off that effect so that the C++ source code would
influence absolutely nothing). So as I see it there's something missing
from the literal interpretation picture, and it even begins to seem a
teeny tiny bit unreasonable, don't you think?
Actually, I think you could leave out most (all?) of
section 2 of your description of OhLaLa and still have a
conforming implementation of C++.
You seem to want the standard to require enough that a
conforming implementation at least stands some chance of
being useful.
Well, it's much stronger than that: wherever the standard does not
explictly require anything at all (and I mean a non-requirement, the
non-requirement of /anything/, as with the 100% conforming OhLaLa "C++
implementation" which isn't a C++ implementation at all), there is IMO
an implicit requirement. OhLaLa, while being literally formally
correct, would not pass any C++ conformance test, I think. That's
because such tests reflect the implicit requirement of usefullness,
which out of any context might seem wooly, but which constrains things.
[snip] I don't believe, however, that just because the standard
makes no meaningful requirements in a given area that we
can treat it as requiring things that just aren't there.
Here's what I think is in the standard regarding the OP's question.
First, that as standard C++ this ill-formed code. Second, that it's
ill-formed code that requires a diagnostic. And third, implicitly, that
that diagnostic should make it clear that the code is ill-formed as
standard C++, which AFAIK is the case for all diagnostics that the
standard requires, there being no requirement (AFAIK) of diagnostics for
well-formed code.
The third, implicit requirement is, as I see it, the only way to make
sense of the standard's definition of "diagnostic", which just makes the
diagnostics a subset of the implementation's "output messages".
Current compilers and compilers back to the 1950s or thereabouts make it
clear that an output message refers to ill-formed code by labeling the
message as an "error", and/or by including phrases such as "language
extension", and make clear that messages that don't refer to ill-formed
code are such by labeling them as "warnings" (w/o "language extension").
The effective requirement on such a compiler is then to produce an
"error" message, unless a language extension is involved, in which case
the message might include the phrase "language extension" or the like.
If you're really convinced that the standard _should_
have stronger requirements in this area, the obvious
thing to do would be to write up a proposal, and submit
it to the committee.
No, as I see it the requirement is already there. What's not there is
how a compiler should distinguish output messages that refer to
ill-formed code, i.e. standards violations for pure C++. I don't think
that how-to belongs in the standard, but for a compiler that has
mutually exclusive and exhaustive subsets X and Y of output messages, Y
being the subset distinguished as denoting ill-formed program text, the
requirement in the OP's case is as I see that the compiler issues a Y
message; which with a conventional warning/error-compiler such as the
OP's compiler means an error message (subject to the little caveat about
language extensions I mentioned above -- with such a big sub-thread
evolving I don't save any keystrokes by omitting it!).
Cheers,
- Alf
--
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?
* Alf P. Steinbach: Current compilers and compilers back to the 1950s or thereabouts
Before some nit-picker steps in here: I'm not referring to only C++
compilers, but to compilers back to early Fortran and Cobol.
--
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?
Jerry Coffin wrote:
The standard (at least generally) uses phrasing like "it
is an error if ..." to mean something like "code is ill
formed if ...", that much is true.
And, specifically, the standard never uses the word "error" in running
text to refer to a violation of a syntactic rule or semantic constraint.
What it does do is follow Stroustrup's pattern of giving code examples
with comments:
some_constuct; // error: explanation
some_other_constuct; // OK: explanation
--
Pete Becker
Roundhouse Consulting, Ltd.
In article <47************@individual.net>, al***@start.no says...
[ ... ] Current compilers and compilers back to the 1950s or thereabouts make it
clear that an output message refers to ill-formed code by labeling the
message as an "error", and/or by including phrases such as "language
extension", and make clear that messages that don't refer to ill-formed
code are such by labeling them as "warnings" (w/o "language extension").
Fifteen years ago, national standards bodies (e.g ANSI
and BSI) had programs to validate and certify compilers
as conforming implementations of C.
As I recall, when I looked up the conditions for a couple
of validated compilers, they specified that most of the
official "diagnostics" were error messages, but at least
a couple were warning messages.
TTBOMK, there's never been an officially sanctioned
validation program in place for C++, but if there was,
I'd rather expect the same to be true for many C++
compilers as well.
The effective requirement on such a compiler is then to produce an
"error" message, unless a language extension is involved, in which case
the message might include the phrase "language extension" or the like.
While it might make good sense for such a thing to be
required, the simple fact is that it isn't -- and never
has been, and frankly I doubt it ever will be. If we ever
return to a situation where compiler validation is a hot
issue again (which wouldn't surprise me at some point) I
suspect that a message that say "warning" will still be
accepted as a diagnostic -- as long as it's thoroughly
documented.
[ ... ]
No, as I see it the requirement is already there.
From a marketing viewpoint, I agree -- most countries
have laws about "implied fitness for merchantability" or
something on that order.
From a standards viewpoint, I think you're dead wrong.
The C and C++ standards both do their best to state as
clearly as possible that there are no requirements above
or beyond those that are _explicitly_ stated in the
standard.
What's not there is
how a compiler should distinguish output messages that refer to
ill-formed code, i.e. standards violations for pure C++.
It requires documentation of what constitutes a
diagnostic. Admittedly, it doesn't attempt to define the
form of that documentation, but that would strike me as a
particularly poor idea.
I don't think
that how-to belongs in the standard, but for a compiler that has
mutually exclusive and exhaustive subsets X and Y of output messages, Y
being the subset distinguished as denoting ill-formed program text, the
requirement in the OP's case is as I see that the compiler issues a Y
message; which with a conventional warning/error-compiler such as the
OP's compiler means an error message (subject to the little caveat about
language extensions I mentioned above -- with such a big sub-thread
evolving I don't save any keystrokes by omitting it!).
The standard requires that it be documented. I suppose if
an implementation wanted to document it as being
distinguished by "error" vs. "warning" in the text of the
message, it could do so. Most compilers I've seen that
attempt to conform with this requirement have explicitly
listed the messages that were officially deemed to be
diagnostics. At least IIRC, the difference between
diagnostics and otherwise did not cleanly separate into
errors vs. warnings, at least in the cases I looked at.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Tomás wrote: std::string &b = a; //Actually compiles with error!
God damn typo. Should've written:
Actuall compiles *without* error!
-Tomás
Interesting discussion anyHow!.
I tried the program on gcc version 4.0.2 20050901 (prerelease) (SUSE
Linux).
and it did not compile.
error: invalid initialization of reference of type 'std::string&'
from expression of type 'const std::string
Alf P. Steinbach wrote: * Pete Becker: Tomás wrote:
Compiler gives me a warning. I think it should give me a downright
error, and I want it to give me a downright error.
Firstly, does the Standard say whether this should generate a warning
or an error?
It requires "a diagnostic." The standard doesn't talk about warnings and
errors.
It really does.
The 1998 C++ standard contains 135 instances of "error" being used as a
synonym for "ill-formed".
Is English your first language? You're confusing two different
meanings of the word "error". The meanings are:
1. Ill-formed code
2. A diagnostic that indicates the compiler found ill-formed code.
The OP was asking about error[2].
If this isn't clear; consider what would happen if the OP were
actually asking about error[1]. His sentence would become:
Firstly, does the Standard say whether this should
generate a warning or ill-formed code?
which is nonsensical. It's very clear to me (and to most English
speakers I would imagine) that the OP is asking about error[2],
ie. whether this code should generate a diagnostic indicative of
ill-formed code.
The Standard talks about error[1], as you point out,
but it does not talk about error[2] at all.
Pete Becker's entirely correct answer is that the C++ standard
requires the implementation to generate a diagnostic, but
this diagnostic is not required to bear any resemblance to
the ill-formed code.
The implementation is also permitted to generate an executable
which will exhibit undefined behaviour at runtime (which may
manifest itself as the const object appearing to change).
In another post you tried this counter-argument:
1. If the C++ standard actually means that, then [insert
ridiculous implementation] is valid.
2. Therefore, the standard does not mean what it says.
I'm sure you can see the problems in this line of
reasoning...
* Old Wolf: Alf P. Steinbach wrote: * Pete Becker: Tomás wrote:
Compiler gives me a warning. I think it should give me a downright
error, and I want it to give me a downright error.
Firstly, does the Standard say whether this should generate a warning
or an error?
It requires "a diagnostic." The standard doesn't talk about warnings and
errors. It really does.
The 1998 C++ standard contains 135 instances of "error" being used as a
synonym for "ill-formed".
Is English your first language? You're confusing two different
meanings of the word "error". The meanings are:
1. Ill-formed code
2. A diagnostic that indicates the compiler found ill-formed code.
The OP was asking about error[2].
If this isn't clear; consider what would happen if the OP were
actually asking about error[1]. His sentence would become:
Firstly, does the Standard say whether this should
generate a warning or ill-formed code?
which is nonsensical. It's very clear to me (and to most English
speakers I would imagine) that the OP is asking about error[2],
ie. whether this code should generate a diagnostic indicative of
ill-formed code.
Natural language doesn't work like mathematical substitution. The base
meaning of "error" as as ill-formed code is the same in [1] and [2].
You might ponder why the pharse "ill-formed code" occurs in both your
points [1] and [2] if there is no connection...
The Standard talks about error[1], as you point out,
but it does not talk about error[2] at all.
It does. What it doesn't do is to say what form the error message
should have, e.g. whether it should include the word "error", or show
the face of Osama bin Laden on the screen, or implicitly refer to some
documentation that lists message numbers of messages diagnosing
violations of the standard's diagnosable rules, or what. The OP's
compiler evidently identifies error messages by including the word
"error" (although this is Usenet, and the information provided less than
complete, so there could be other possibilities, or special cases).
[snip]
In another post you tried this counter-argument:
1. If the C++ standard actually means that, then [insert
ridiculous implementation] is valid.
2. Therefore, the standard does not mean what it says.
I'm sure you can see the problems in this line of
reasoning...
Yes, your premise in 1 is incorrect, and even it were correct, the
conclusion in point 2 would be incorrect.
What I wrote was, paraphrased, that if only a literal reading of the
standard is adopted, then it allows a non-implemention of C++ to
formally be a 100% conforming implementation. It was not ridicolous, it
was simply not a C++ implementation in any respect. Furthermore, I
noted elsewhere that if only a literal reading of the standard is
adopted, then it's inconsistent in several places.
The two remaining unresolved points in this thread are (1) whether the
standard explicitly requires diagnostics of rule violations to be
identified as such, or only requires that implicitly (detrimental to my
argument, I have maintained that that is only an implicit requirement,
following from the kind of consideration you tried to mock above,
whereas others who have the opposing point of view on the error issue,
paradoxically maintain that it's an explicit requirement), and (2)
whether compilers actually _do_ identify such diagnostics, e.g. via use
of the words "error" versus "warning", and here I think they do and have
always done, albeit with the usual imperfectness of compilers, whereas
others maintain that they generally don't, which I find unconvincing.
Cheers,
- Alf
--
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?
Alf P. Steinbach wrote: Old Wolf wrote: You're confusing two different
meanings of the word "error". The meanings are:
1. Ill-formed code
2. A diagnostic that indicates the compiler found ill-formed code.
The OP was asking about error[2].
Natural language doesn't work like mathematical substitution.
The base meaning of "error" as as ill-formed code is the same
in [1] and [2].
No, it isn't. [1] is referring to code, and [2] is referring to an
indication. These are separate entities.
You might ponder why the pharse "ill-formed code" occurs in
both your points [1] and [2] if there is no connection...
There is a connection, but the meanings are not identical!
The message was generated in response to the piece of code,
but they are still two distinct items (really!) The Standard talks about error[1], as you point out,
but it does not talk about error[2] at all.
It does. What it doesn't do is to say what form the error message
should have, e.g. whether it should include the word "error", or show
the face of Osama bin Laden on the screen
Right, what I should have said was: it does not make any
distinction between error indications, and other indications;
and in particular there is no discussion of differences between
an "error message" and a "warning message".
Whether a compiler labels a message as "error" or "warning"
is up to that compiler, and it does not render the implementation
non-conforming if a required diagnostic is labelled "warning".
* Old Wolf: Alf P. Steinbach wrote: Old Wolf wrote: You're confusing two different
meanings of the word "error". The meanings are:
1. Ill-formed code
2. A diagnostic that indicates the compiler found ill-formed code.
The OP was asking about error[2]. Natural language doesn't work like mathematical substitution.
The base meaning of "error" as as ill-formed code is the same
in [1] and [2].
No, it isn't. [1] is referring to code, and [2] is referring to an
indication. These are separate entities.
The base meaning is the same: ill-formed code. That's why you found it
necessary to include the phrase "ill-formed code" in both points. In
point [2] you're /using/ that meaning to talk about a diagnostic.
[snip] Right, what I should have said was: it does not make any
distinction between error indications, and other indications;
Well, Jerry Coffin wrote, in response to "What's not [in the standard]
is how a compiler should distinguish output messages that refer to
ill-formed code, i.e. standards violations for pure C++", that
"The standard requires that it be documented."
Let's call this Requirement X.
I happen to not share Jerry's viewpoint, so as you can see there is no
universal agreement on this. You're on one end of the scale,
maintaining there is no requirement X; I'm in the middle somewhere,
maintaining there is an implicit requirement X; and Jerry is at the
other end, maintaining that there is an explicit requirement X.
and in particular there is no discussion of differences between
an "error message" and a "warning message".
That's generally not within the standard's domain.
So it's generally quite irrelevant.
There is however one exceptional case where I think it would be
appropriate if the standard made a distinction about what kind of
diagnostic should be issued, at a sufficient high level of abstraction
(i.e. not dictating the form of message class identification), namely
where you have a language extension. Alas, the standard only
distinguishes this diagnostic by noting that after issuing it, an
implementation can go on to translate (heh, here the standard actually
uses the word "compile", I didn't notice that!) and execute the program.
One implication is that in other error cases the implementation can't
or shouldn't execute the program, but that's nowhere stated outright; it
just makes the clarification meaningless if that was not the intent.
Whether a compiler labels a message as "error" or "warning"
is up to that compiler, and it does not render the implementation
non-conforming if a required diagnostic is labelled "warning".
That's right, but, so what?
There are several cases where that can happen. One is that the compiler
does not employ the "warning" versus "error" distinction, but some other
way of identifying standard violations. Another is that the compiler
implements a language extension, in which case a "warning" is IMO most
appropriate, since the code is not in error with respect to the extended
language (the standard still requires that use of the language extension
be diagnosed, and a quality compiler will offer a standards mode where
use of such extensions are diagnosed as plain errors). A third is that
the compiler is simply non-conforming, in that it doesn't identify
standard rule violations as such, in which case it cannot be rendered
non-conforming: it already is (assuming there is a requirement X).
--
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?
In article <47************@individual.net>, al***@start.no says...
[ ... ] Well, Jerry Coffin wrote, in response to "What's not [in the standard]
is how a compiler should distinguish output messages that refer to
ill-formed code, i.e. standards violations for pure C++", that
"The standard requires that it be documented."
Let's call this Requirement X.
I happen to not share Jerry's viewpoint, so as you can see there is no
universal agreement on this. You're on one end of the scale,
maintaining there is no requirement X; I'm in the middle somewhere,
maintaining there is an implicit requirement X; and Jerry is at the
other end, maintaining that there is an explicit requirement X.
Section 1.3.2 defines "diagnostic message" as: "an
implementation-defined subset of the implementation's
output messages."
Section 1.3.5 defines implementation defined behavior
saying that it's something that "...each implementation
shall document."
Section 1.4/2 says: "If a program contains a violation of
any diagnosable rule, a conforming implementation shall
issue at least one diagnostic message."
The only room for argument I see there is that 1.3.2 uses
only "implementation defined" rather than "implementation
defined behavior". While I generally favor reading the
standard pretty literally, I think in this case the
intent is obvious: an implementation is required to
document which messages are officially "diagnostics" and
which aren't. and in particular there is no discussion of differences between
an "error message" and a "warning message".
That's generally not within the standard's domain.
So it's generally quite irrelevant.
Yes and no -- the standard (by my reading) requires that
the messages that are diagnostics be documented. How
that's documented is more or less irrelevant, but the
fact that it has to be documented in some way seems
pretty clear, at least to me.
--
Later,
Jerry.
The universe is a figment of its own imagination.
visual studio has a option which put all the warns to errors
Jerry Coffin wrote: Yes and no -- the standard (by my reading) requires that
the messages that are diagnostics be documented. How
that's documented is more or less irrelevant, but the
fact that it has to be documented in some way seems
pretty clear, at least to me.
Agree with that. But it would be tedious for the user to look
up the documentation for every message to find out if it is
a required diagnostic or not; IMHO the standard ought to
say that the diagnostic itself contain a clue as to whether
it is one that's required by the standard, or whether it is
something specific to that implementation. (eg. [E] for
required diagnostics and [W] for others).
A slightly pedantic point: the pages you quote don't
guarantee that a user can distinguish between required
diagnostics and other ones, because other ones could
use exactly the same message text as a required
diagnostic (eg. consider a compiler that beeps once for
each diagnostic).
Old Wolf wrote: Jerry Coffin wrote: Yes and no -- the standard (by my reading) requires that
the messages that are diagnostics be documented. How
that's documented is more or less irrelevant, but the
fact that it has to be documented in some way seems
pretty clear, at least to me.
Agree with that. But it would be tedious for the user to look
up the documentation for every message to find out if it is
a required diagnostic or not; IMHO the standard ought to
say that the diagnostic itself contain a clue as to whether
it is one that's required by the standard, or whether it is
something specific to that implementation. (eg. [E] for
required diagnostics and [W] for others).
Such requirements would trample into the area of implementation design.
The users and implementors should decide whether they need such a
feature.
As a user, you should know the language well enough to know what is a
required diagnostic and what is not.
As an implementor, by distinguishing required diagnostics from the
superfluous ones, you are only helping the user write code that will be
portable to competitive compilers.
You are also being forced to separate the messages into two obvious
classes, which gives users a kind of license to ignore any of the
lesser ones that are not marked [E]. Implementors should be allowed to
decide what diagnostics are important.
Then there is the problem that there are errors which do not require
diagnostics. If the impelmentation finds undefined behavior, a
legitimate response is to stop translating the program. A [W]
diagnostic would not be appropriate for that situation.
The classification would have to be three-valued, something like [D]
[E] [W]: diagnosable syntax, constraint or semantic rule violation;
other kind of error such as undefined behavior, and stylistic warning.
This still sucks because some undefined behaviors are hard to analyze
for accurately. The analysis becomes a lot easier and cheaper if the
result does not have to be conclusive, but only come up with a
suspicion that something is wrong.
A suspected undefined behavior can't be classified as an error, whereby
translation of the program terminates. It's a warning: under some
conditions, perhaps undefined behavior can occur here. If you have some
run-time undefined behavior in an expression, it's not an error unless
you can prove that the final, linked executable program will actually
execute that expression, regardless of what inputs it is given. If a
division expression, x / y, occurs in the program, then a division
by zero can occur there only if execution reaches it, and the value of
y is zero. There may be some reason to suspect that it will happen,
without adequate proof that it does happen. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Vamsi Mudrageda |
last post by:
I am kind of new to Python, and after trying and using wxPython, I found
it kind of lacking in easy-to-read documentation, speed at loading, and
GUI response-time.
So I am looking for an another...
|
by: Vladimir Grul |
last post by:
Hello,
I have a class member function declared as
class some_class {
....
virtual int call(void);
};
Can I use this-> inside the function body?
|
by: Schraalhans Keukenmeester |
last post by:
I have no clue why below code (found it somewhere and altered it a wee
bit to my needs) will run without problem in both IE and Mozilla FireFox
1.0 but in the latter it takes up close to 100% cpu....
|
by: Darklight |
last post by:
Question taken from a book
Write a function that accepts two strings. Use the malloc()
function to allocate enough memory to hold two strings after
they have been concatenated(linked). Return a...
|
by: RichG |
last post by:
Does anyone remember this:
Set datapath to "c:\somewhere"
dNetUse "SomeTable"
do some db work
I asked the question a couple of days ago about how to attach a recordset or
some form of data to...
| | |
by: Raman |
last post by:
Hi All,
Here is a small Code,
int main(void)
{
char *p=(char *) malloc(100);
strcpy(p,"Test1234567890");
p=p+10;
free(p);
|
by: Bill Reid |
last post by:
#define MAX_VALUES 64
typedef struct {
unsigned value_1;
double value_2;
double value_3;
double value_4;
} VALUES;
typedef struct {
|
by: Tomás Ó hÉilidhe |
last post by:
Has anyone here got access to a ridiculous computer? Something like:
CHAR_BIT == 9
PADDING_BITS(int) != 0
NUMBER_SYSTEM == SIGN_MAGNITUDE
Null pointer bit pattern == All ones
I'm writing...
|
by: Dave |
last post by:
Hello,
I'm teaching myself C by working my way through Steve Summit's tutorial
(http://www.eskimo.com/~scs/cclass/cclass.html). In one of the questions
(assignment 6, exercise 7), you have to...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
| | |
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
| | |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence...
| |
