Win7 - 64bit
gcc (GCC) 4.8.2
g++ -w -DYYDEBUG=1 -DDEBUG_IO -c -g -MMD -MP -MF
"build/Debug/Cygwin-Windows/SlipRegister.o.d" -o
build/Debug/Cygwin-Windows/SlipRegister.o SlipRegister.cpp
There is no generated code for "retval = true;" in the conditional block. I am
including the code fragmen
Cygwin gcc 4.5.3
I have run some tests to determine the gcc 4.5.3 integer promotion policies.
The
tests show that for 'char' input, "char << long" and "char >> long" promote to
INT while other operations using a long promote to" long", and that "char <<
ulong" and "char >> ulong" promote to I
Program and particulars below.
When line 27 is commented out, line 26 is output. When line 27 is not
commented, line 26 is not output except that if x.file contains a line feed the
null line line 26 & line 27 are output. If x.file does not contain a line feed,
only line 27 is output.
Does the
Thanks to everyone.
The rock has dropped. The answer is quoted below:
"My best guess is that a header file is included twice, and lacks guards, hence
the message is correct: the function is being defined twice, from the same
source location."
I had put my friends following my 'include guard'
I forgot to say 'thanks James', thanks.
Well, spurred on by the whimsy that I need a solution to the problem (however
dolorous), I experimented. I've commented most everything at least once and the
net effect is that only the 'operator<<' gets a nasty message. I've checked the
include files th
nadulterated and full of original lacerations) -
/*
* File: irange.h
* Author: Arthur Schwarz
*
* Created on April 13, 2009, 1:23 PM
*/
#ifndef _IRANGE_H
#define _IRANGE_H
# include
# include
# include
# include
# include
# include
# include "common.h"
class iRange_L
Suggested Messaging: Messaging seems redundant in indicating that function has
been redifined twice. One of the messages should be removed. More to the point,
I think the messaging may be erroneous - code fragment follows.
g++-4 Diagnostic Messaging
In file included from partition.cpp:66:
i
The issues grow ever more complex. Suppose that we're dealing with macro's,
some similarly named, and there's a typo. Suppose several layers of template
expansion are involved and nested deep within one there is some error. Suppose,
suppose ... .
The motivation is not to expand the problem do
>
> So I guess, yes, I'm asking Arthur to suggest rules
> of relevance that would
> enable the compiler to decide what kind of user error is
> implied by a given
> syntax error.
>
> cheers,
> DaveK
>
You're asking for a lot. I've never been accused of being smart (the quip
being,
--- On Mon, 4/13/09, Joe Buck wrote:
them all.
>
> Consider
>
> #include
> struct Foo { int bar;};
> int main() {
> std::cerr << Foo();
> }
>
> Try it, the result is ugly, and I often encounter this one
(Personal opinion - not to be construed as wisdom).
The issue with the result i
> > Thanks Dave;'
> >
> > Acerbic comments below.
>
> >> Isn't that exactly what the
> compiler IS doing, as
> >> indicated by "candidates are ... "?
> >
> > I don't think so. [ ... ] A clear
> message that arg is wrong I think
> > is a better approach.
>
> But maybe arg is right an
Thanks Dave;'
Acerbic comments below.
--- On Mon, 4/13/09, Dave Korn wrote:
> > using namespace std;
> > void CommandLine(int argc, char** argv);
> > int main(int argc, char** argv) {
> > string a = "output.txt";
> > string* b = &a;
> > ofstream y;
> >
> y.open("output.txt", ios
Some messaging observations for the input code (below).
# include
# include
# include
using namespace std;
void CommandLine(int argc, char** argv);
int main(int argc, char** argv) {
string a = "output.txt";
string* b = &a;
ofstream y;
y.open("output.txt", ios::in);
y.open( a
In the following code fragment:
# include
# include
# include
using namespace std;
void CommandLine(int argc, char** argv);
int main(int argc, char** argv) {
CommandLine(argc, argv[]);
ifstream x.open(argv[1], ios:in);
ofstream y.open(argv[1], ios::in);
return 0;
};
g++-4 mes
To all, I stand abashed - don't try this without a trained instructor. I
misread the Schildt quote and (I think) wasted your time(s).
Thank you
art
--- On Fri, 4/10/09, David Fang wrote:
> From: David Fang
> Subject: Re: operator=() issue
> To: "Arthur Schwarz"
avior seen by gcc is unexpected. Given your statement it appears that an
access specifier of 'private' has no effect.
art
--- On Fri, 4/10/09, Ian Lance Taylor wrote:
> From: Ian Lance Taylor
> Subject: Re: operator=() issue
> To: "Arthur Schwarz"
> Cc: gcc@gcc.gnu.
operator=() is private in ios_base. Using private inheritance of ios_base the
program below fails in the constructor when '=' is used (but not during memory
initialization). I don't understand why assignment is prohibited.
art
Program 1 fails
# include
using namespace std;
class thing : pri
This isn't a compiler question and I apologize for that. I'm having a devil of
a time getting an answer to my issues on the C/C++ forums I'm using and, sigh,
perhaps someone can direct me to a forum where the questions can be better
addressed.
I'm trying to redirect I/O in my C++ application a
In light of the foolhardy commitment I made, here are some reprehensible
diagnostic messages and the superb recanting of the obvious. As always, the
messaging and comments are gratuitously provided and I hope accepted in the
same manner.
Two notes (made before):
1: Some messages are needlessl
I didn't mean to volunteer. I'm retired and therefor am both unhireable and
hove no free time. But if you really (really) want ... I'd be glad to
contribute in any way that I can. Provide what you need that I can do, and a
means to give you feedback and I'm yours.
(I've already provided an ind
Please take the comments as constructive and not adversarial. I use GCC
and have hopes of sending it a Valentine's Day gift.
1: Any thought to including column numbers with line numbers on
ERROR messages? Looking at a diagnostic message for a complex
statement without a column number has
21 matches
Mail list logo
