[Gametes]

#include <iostream>

int main()
{
int hf;

cout<<"Please input the number of feet your height completely fills: ";
cin>>hf;

return 0;
}

This code compiles identically under Visual C++, Solaris, and Linux. (I've tried them all)
But nooooo, on Mac OS X is compiles WRONG. (Try It!)

By ALL other compilers on earth, the cout statement occurs before the cin statement. But according the Apple's cc, the cin statement RIGHTFULLY occurs before the cout statement (not).

This is simple code. I cannot work on C++ if this crap won't work.
So, can anybody tell me how to fix cc?
Can anybody tell me how to get the gcc I downloaded from the Darwin page to work?

Please, I need to be able to compile ANSI Standard C++!!!

[LordJavac]

The compiler is just fine. The problem is that the cout buffer needs to be flushed for the data to show up. This can be accomplished by cout.flush() and your input will show up. This issue has been previously discussed on these forums.

[Gametes]

cout.flush() is doing nothing for me, no matter where I put it.
Would you please tell me where it goes in the example code, and also try it yourself to make sure you aren't wrong?

I searched, by the way, in the forums before I posted. Nothing was of any help.

[Dalgo]

You should throw in an endl in that cout in order to make it flush. For some reason flush doesn't seem to work. BTW, if you are running that under project builder putting in an endl a flush or anything else like that isn't going to help you. Project Builder doesn't play will with console IO that isn't printf. If you run your program from the terminal, and use endl, then it should be fine.

For example:

Code:
# include <iostream.h>

int main()
{
  int a;
  cout << "Hello World!";
  cin >> a;
  cout << a;
  return 0;
}

When run from the terminal you will see nothing before it wants you to cin something. If instead you do:

Code:
# include <iostream.h>

int main()
{
  int a;
  cout << "Hello World!" << endl;
  cin >> a;
  cout << a;
  return 0;
}

Then it will function correctly. The last a is shown because it flushes the output buffer automatically when it quits. If you use flush instead of endl then you will see that there is a bug somewhere because nothing appears. remember, nothing says that the output buffer MUST be flushed before an input. It's just that pretty much everything else does flush it automatically. In this case you have to flush it yourself but flush is broken so you have to use end; If you don't like this use printf and scanf. And stuff like fflush(stdout). They all work fine.

[parallax]

Code:
#include <stdio.h>

int main()
{
        int x;
        printf("Prompt> ");
        scanf("%d", x);
}

This'll work.

[This message has been edited by parallax (edited 02-21-2001).]

[Gametes]

Look, thanks for the help.
Nonetheless, this is a big issue imo. The fact that identical code compiles identically on at least 3 different operating systems, but then turns crap on X, is a big deal.

I don't want to put an endl after my cout statement. I want the user to input his age on the same line that I ask him for it.
I also don't want to go through all 316 lines of my code replacing all my cins with formatted printf statements; that is a big pain in the a$$.
Whatever happened to portability? What about compatibility? What about standards, implemented exactly for this reason?

LordJavaC is wrong. The compiler is broken, because my program is [b]wrong[/i].

Will the Darwin g++ work any better? (On Solaris, the commands cc and gcc compile my code wrong, thinking the tags are c. But calling it by g++ makes it compile perfectly. My theory is that this same thing is happening on X. So I want to use g++)
How can I install it once I've downloaded and unstuffed it? I tried running make but it errors towards the end...

[Mniot]

I only have Solaris and OSX to play with, but try this: go to these machines and compile your program with "-nostdlib" and then manually include the libraries. Are you using the same ones? My school's Solaris setup has g++ including vast libraries without consulting the user. Apple's cc includes nothing.

[LordJavac]

OK, I've researched this and here's the deal. flush seems to not work, this is probably the problem. cout should be flushed before any input on cin according to the C language spec (this is because cin is tied to cout). However this is not a fault in the compiler, but rather in the libraries.
I've found two workarounds, the first has been posted above (using stdio functions) and the second is to use cerr instead of cout. cerr works because it is an unbuffered stream. I agree that this is a serious bug, but it is in the libraries, not the compiler.

[parallax]

Gametes, refer to my above post (which I believe you read the <rant> version of).

printf() is actually a lot more flexible than cout is.

[Mniot]

printf(...) might be more flexible... but it's not c++. There's a lot of good reasons to use cin/cout/cerr. Printf can't handle overloaded output operators, printf doesn't do type checking...
If you're used to C++, streams are the way to go.

[Gametes]

Ya, but with that flexibility comes the problem of having to do all that \n, %dl, etc crap.
You guys have been really helpful. I have been wanting an answer to why this doesn't work, and I think now we have it. It's just that before people denied that this even was a problem.
So what now? Are the libraries going to get up to par with all the others?
Or is libstdc++ just going to suck forever?
Does GNU even know that their c++ library is broken?

[gorgonzola]

I'm no expert on the issue, so the standard salt grain disclaimer applies.

What I've heard is that Apple is working very hard to get their version of gcc (called cc) fully compatible with GNU's gcc (the current version). Although they're both gcc, I don't think they're both the same version, so to speak. Stan Shebs is working on this and this work should hopefully be finished by Final.

I haven't been able to find any g++ compiler for Mac OS X, it isn't at the Darwin projects page and it isn't at GNU. Hm. Someone was trying to find g++ at another forum and could not.

sorry. I do hope they fix this kind of stuff up though because I hope to finish up learning Carbon in a few months (boy does it go slow when you're doing all this stuff for the first time).

------------------
the oddball newsletter
------------------
it's only after you lose everything that you're free to do anything

[monty]

gorgonzola,

i'm not an expert either but i think that g++ on Macos X is called c++. It seems to compile my code ok.

peter

[Gametes]

Try again, using the above sample code, man.
c++ is totally different.

[sadie]

I got a similiar problem to this, using Objective-C in Project Builder. I found the solution was simply to put a newline at the end of each string that has to be flushed, so:

cout << "Please input?\n";
cin >> hf;

The problem is with the buffering. It only flushes buffers when it hits a newline. It also happened on the input - you wouldn't recieve any input until the user hits enter.

This is annoying, but hardly gets in the way of a GUI program (Carbon or Cocoa), which doesn't use any of these buffered libraries.

[Gametes]

That does not "fix" the problem. It is a stupid workaround to what is, undeniably, a problem.
I understand that this doesn't affect non-terminal apps, but it does effect me. I don't trust Apple's dev tools anymore, frankly. They do not conform to standards. I hope they can resolve this buffering error soon.

[parallax]

Exactly what is so important that you _need_ to have cout (alternative: printf) flush your buffer for you? ( \n or endl works! )

And that you _need_ to complain about it in a beta release of the system?

Use ncurses if it's that important.

If c++ stream io is broken, just use standard Unix calls. printf() works without problem, and it even fixes other strange compiler bugs that are out there.

I've run into all sorts of weird compiler bugs where valid code simply doesn't get compiled. Hopefully this madness will go away. In the meantime there are plenty of workarounds. Make bug reports and find code alternatives.

[Wixar]

Originally posted by Gametes:
That does not "fix" the problem. It is a stupid workaround to what is, undeniably, a problem.
I understand that this doesn't affect non-terminal apps, but it does effect me. I don't trust Apple's dev tools anymore, frankly. They do not conform to standards. I hope they can resolve this buffering error soon.

There is nothing broken about the developer tools (at least that you demonstrate in your example) and no evidence that they fail to conform to standards. The fact that the code compiles identically under other compilers does not imply that OS X's cc is at fault for not compiling it the same way, unless the behavior of the code is dictated by the ANSI standard.

The standard output stream may or may not be buffered by default. In the case of OS X, it apparently is. Try using cout<<"Please input the number of feet your height completely fills:
"<<flush; or perhaps cout<<"Please input the number of feet your height completely fills:
"<<endl;

Also, you need to make your code conform before you can expect the compiler's output to conform. You haven't qualified the standard library's identifier scope.

-Peter

(with props to comp.lang.c++)

[Gametes]

I don't care about comp.anything.
The only relevant fact here is that identical code compiles identically on 3 platforms, but Mac OS X is noncompliant.
Even if all other 3 are "wrong", I bet Apple wants to go wrong too just for compatability/portability.

[gorgonzola]

Have you tried compiling like this:

%> cc -traditional-cpp hello.cpp

or whatever the filename is. According to Stan Shebs, that invokes the standard GNU C/C++ compiler and should compile normally. Either way, he's working on GCC 3 right now and apparently it's coming along well, including fixes for some "beta quirks" that people noticed.

Did it work? I'm curious.

------------------
the oddball newsletter
------------------
it's only after you lose everything that you're free to do anything

[parallax]

That's not working for me.

It shouldn't be the compiler's fault. The problem, I believe, is iostream's flushing functions, which aren't working properly. printf(...) works just fine.

[This message has been edited by parallax (edited 03-13-2001).]

[Wixar]

Originally posted by Gametes:
I don't care about comp.anything.
The only relevant fact here is that identical code compiles identically on 3 platforms, but Mac OS X is noncompliant.
Even if all other 3 are "wrong", I bet Apple wants to go wrong too just for compatability/portability.

The fact that the code compiles identically on three other platforms does NOT mean that Apple's compiler is "WRONG" or noncompliant with the ANSI spec. Different compilers can produce different results for the same code without any of them being wrong. As I said, the spec allows for stdout to be buffered or nonbuffered.

The following code is fully compliant with spec and works as you intend. Notice the endl.


#include<iostream>

using namespace std;

int main(void) {
int j;
cout << "Please input the number of feet your height completely fills:" << endl;
cin >> j;
return 0;
}

There is no problem: not with Apple's compiler, with iostream, or with Mac OS X. The assumption that just because the code works the same way on three different compilers that it should work that way on Apple's is absurd. All that matters is that Apple's compiler does what the ANSI spec requires it to do...and it does.

-Peter

[Gametes]

oh wow peter! "endl"!
What is this strange operation I have hitherto not known, that you have so graciously enlightened me regarding?!
Please, share more of your amazing programming talents with us!

NOT.

I want my input on the same line as my output. That is my choice as a programmer in C.
And about all the "but it's still compliant, so touche" nonsense, I really couldn't care less. I did before, but I've already changed my concern to the more primal basis: 3 compile one way, X compiles another.
You think that is "normal and good"? gimme a break! I think it means it is broken. In fact, that is the very definition of broken, for compilers.

So just shut up with the smartmouth (did you really think I don't know hotw to use endl?) and admit that cc is unacceptable.

oh and ps - "all that matters" is that mac os x's programming mechanism works, which it does not.

------------------
you are not your signature

[Lars -1]

Originally posted by Gametes:
oh wow peter! "endl"!
What is this strange operation I have hitherto not known, that you have so graciously enlightened me regarding?!
Please, share more of your amazing programming talents with us!

NOT.

I want my input on the same line as my output. That is my choice as a programmer in C.
And about all the "but it's still compliant, so touche" nonsense, I really couldn't care less. I did before, but I've already changed my concern to the more primal basis: 3 compile one way, X compiles another.
You think that is "normal and good"? gimme a break! I think it means it is broken. In fact, that is the very definition of broken, for compilers.

So just shut up with the smartmouth (did you really think I don't know hotw to use endl?) and admit that cc is unacceptable.

oh and ps - "all that matters" is that mac os x's programming mechanism works, which it does not.

Your postings and your test for "finding out that mac os x's programming mechanism is broken" shows that you are, at least for the languages C and C++, a beginner.
There is no reason to act so rude, especially when you are wrong, and even more so because your error is so very basic. The "problem" of I/O buffers getting in your way when doing basic programming has been discussed ages ago. You should find explanations in the usual FAQs for C and C++. The behaviour of OS X is perfectly normal, and in no way wrong or broken.

RTFM, before this gets too humiliating for you.

cu
Lars

[parallax]

[ DISREGARD ]

[This message has been edited by parallax (edited 03-25-2001).]

[Gametes]

1) I am a beginner. I never said I wasn't. So? Do I have to be 1337 to talk about something around here?
2) I am not the one beating a dead horse. I only peruse this forum occasionally, and then, I only respond to this thread when others have expressed some idea (LordJavaC), insight (Dalgo), or opinion (Wixar) into the matter. Am I not supposed to do this? The only "beating" is when multiple people enter this thread, don't bother to read, and then assume my issue is just some piddly little code error on my part, where I forgot an endl. They can't/don't/won't consider that my issue is with the fact that I cannot do my homework. (<--- note the period)
3) I don't know alot about compilers, but I do know what is supposed to happen when I compile. All this discussion I thought was actually productive - we were analyzing where the fault for this divergent behavior lay: first my contention was that it was the compiler, then asserted was fault in the code, then the libraries both of these elements are using.
All of this was going well. Everyone was calm and helpful. If you or anyone else was getting frustrated (which I feel I am the only one entitled to be (I: have to do work; others: don't have to click on this thread), yet I'm not), you certainly did not show it, which I ironically appreciate.
That is, until Wixar lost his head (Hey Peter: did you notice that in this thread your ingenious endl solution had been pointed out a prior 5 times?!). Downhill from there, as we all have seen.

So go ahead. Close this thread. It's not like it's my baby. Just don't act like you're doing it because I'm such a big jerk who won't stop ranting on the same topic. Be honest, do it because of you. Others have already agreed that this is a problem, and all the so-called "fixes" sacrifice desired functionality.

PS - What standards do you use when deciding to close a thread? Do you just hate debate in a forum devoted to programming, or is there a reason this is inappropriate? I suggest you reconsider whether or not it is the right thing to do to forcefully end this, or if you ought to just act like a moderater and let nature take its course.
Also, I've already reported you: telling me to "die", to "not bother" you, and to not share my "damned opinion" is not behavior I think MacNN expects from its exemplars/moderators.

------------------
you are not your signature

[parallax]

I wouldn't be mad at all if you'd come back with some backing that said "Yes, this is a problem- because:" In fact, I'd appreciate it.

But rule #1 in *any* discussion group is RTFM.

[LordJavac]

I did RTFM on this, because it's important. I picked up my copy of "The C++ Programming Language" Third Edition by Bjarne Stroustrup (The designer of C++ for those who don't know), and it says "Of the standard streams, cout is tied to cin and wcout is tied to wcin." [21.3.7 Tying of streams (page 624)]. This means that when you ask for input on cin, cout is supposed (according to the standard) to be flushed.

According to my experimental research, the basic problem seems to lie in the flushing of cout (if not all streams). I've tried manually tying cout to cin and manual flushes of the stream.

[parallax]

Correct or incorrect is not the issue.

When you come here for a complaint, do so having done your homework.
It doesn't matter whether you're right or wrong, but if you come without sources saying where and who says what (especially while attacking something), don't expect your post to be treated much more than flamebait.

I do agree with Gametes, this is productive, and I'd like it to continue. I just don't want the same arguments back-and-forth.

(PS: Sorry if I'm somewhat evil today. Today is *not* a good one)


[This message has been edited by parallax (edited 03-16-2001).]

[AirSluf]

Adding newline's or endl's are an unacceptable workaround for many applications, including the one Gametes has. If you want the input made at the end of the line following the colon, adding an endl forces action down to the next line. This can throw formatting all out of whack.

I defer to the long term experienced folks on where the fault lies, but the fact is, Gametes compiled code does not meet spec for a standard C++ compile. Somewhere, this not insignificant bug MUST be squashed.

[tr909]

I completely read the thread, interesting how such a thing evolves.

I'm wondering, is the issue fixed in OS-X 10.0 retail ?

[PerfectlyNormalBeast]

If i had a nickle for everytime M$'s compilier did something I didn't expect, I'd have enough money to start a compilier company. There are plenty of things that ANSI C++ doesn't really specify the exact behavior of, but... if you know the spec, you then know what things do assure results, and you program accordingly. As a beginner gametes, be thankfull you're not using RTTI or something where compilier differences really show their ugly face.

Having said this, I aslo have to say that I agree with you. So long as it's within the spec, i'd rather the std::cout flush before it cins.

[Scrod]

Dang! The problem's not fixed in the Developer Tools that come with OS X 10.0! I'm getting the same issues with the cout buffer not being flushed! Is endl and/or "\n" the only work-around here?

[Lars -1]

Originally posted by Scrod:
Dang! The problem's not fixed in the Developer Tools that come with OS X 10.0! I'm getting the same issues with the cout buffer not being flushed! Is endl and/or "\n" the only work-around here?

Once again: There is no problem. The thing with endl is no work-around but rather standard-conforming. The buffers behave conforming to standards. If you rely on the buffers flushed at a specific time without taking the normal steps, you will produce unportable code. The next platform your program will be compiled on may produce different results again. Program according to standards and produce portable code.

cu
Lars

[maxintosh]

There IS a problem because you can't cin on the same line. This throws formatting off. There is no workaround. How could it not be a problem??

~Maxintosh

[Kristoff]

dammit! Did ANY of you read the standards?
This is not a bug.
It is bad programming on the part of the originator of this thread.
Please, for the love of correctness, use "\n" and all will be fine on ALL platforms. Sun, and Microsoft are certainly NOT the ones to look to for standards compliance, albeit Sun is much closer.

[This message has been edited by Kristoff (edited 03-30-2001).]

[LordJavac]

If you read my previous post, you'll see that I did read the standard and that this is non-conformance.

[Kristoff]

While we ALL have much respect for Stroustrup, please read the newest ANSI C++ standard.

[Gametes]

I want to cout and cin on the same line.
3 platforms say "ok". 1 says "sorry".
You say that is not only acceptable, but the way it ought to be?

[mkurland]

Gametes,

I want to cout and cin on the same line.
3 platforms say "ok". 1 says "sorry".
You say that is not only acceptable, but the way it ought to be?

As a C & C++ programmer of very long standing, let me tell you, I understand your indignation.

The reason posters to this thread have said that disparate behaviors across platforms and/or compilers is acceptable is because the language standards for C and/or C++ may explicitly state that certain behaviors are *not* defined as part of the standard.

Is this a bummer for writing portable code? Sure!

Why are things done that way? Many languages, especially C, were designed to be very closely tied to hardware architectures. The precision of floating point numbers or the range of integer values may be defined differently for different platforms. On older x86 machines, a C compiler would probably define an int as 16 bits... but on for compilers on 32 bit processors, ints were 32 bits. This flexibility allowed C compilers to generate tight, fast code on a variety of architectures.

Of course, we sometimes want to write portable code. And sometimes the size of an int needs to be known, or your code will break.


So we have typedefs. We use the preprocessor. As an adjunct to your homework sometime you should download some code that was written to compile on multiple platforms under multiple compilers.

You'll probably see code like this:

/*
** SYSTEM SECTION: These settings describe platform and hardware specifics.
** They are all required to be set properly or the program likely won't
** compile or run.
*/

/* #define PC Comment out this #define if you have a Unix, Mac, or other */
/* system that isn't a generic PC running DOS or MS Windows. */

#define MAC /* Comment out this #define if you're not compiling for a Mac. */

/*#define X11 Comment out this #define if you don't have X windows, or */
/* else have them and don't wish to compile in X graphics. */

I understand that it's reasonable to expect consistent behaviors from your tools. And when 3 compilers do something one way, and a fourth does it differently, it is natural to think that the 'different' one is wrong or broken. And it would sure be nice if they all worked just the same. But that isn't how sofware engineering works. Not in C. Not in C++. Heck, not even in Java.

If you want to build truly portable code, you need to a) define and b) accommodate the divergent behavior of different compilers/libraries/platforms. And, yes, it sucks. It's hard work. That's why the folks who can do it actually *deserve* the big bucks. <grin>

Miles

[SmileyDude]

Guys, this is a bug.

Well, maybe not the way it was originally thought to be.

Take this code, for example:

Code:
#include <iostream>

using namespace std;

int main(int argc, char *argv[])
{
	int a;

	cout << "Enter a number: ";
	cout.flush();

	cin >> a;

	cout << a;

	return 0;

} // of main()

This does not act as expected under OS X! The output from the cout should happen before the cin. Without even arguing about if cout should flush the buffer before a cin, the cout.flush() should take care of it.

And before anyone jumps on me about not reading the spec, I have. Like I said, the cout.flush() should take care of the problem. Under OS X, it doesn't.

This is a bug in the OS X implementation of the C++ libraries.... anyone up to fixing it under Darwin?

------------------
dennis

Umm... why would you want to use C++ on MacOS X anyway? This platform provides you with Objective-C, which is a cleanly structured object oriented language compared to the crap C++ provides.

If you're a beginner and want to learn something about object-oriented programming you should go for Objective-C. If you just want to do some imperative console programming you should go for plain C, as it is a lot simpler to learn than C++.

Just my two pence,

Sebastian

[parallax]

Umm... why would you want to use C++ on MacOS X anyway? This platform provides you with Objective-C, which is a cleanly structured object oriented language compared to the crap C++ provides.

Nobody wants to use C++. However, a lot of people have CS classes for which they need to hand in C++ code.

Yes, that flush should be a bug.

Anyways, I found this odd. Use printf and scanf. Then use printf and cin. Under printf and scanf, the buffer flushes properly. However, using cin after printf doesn't flush the buffer.

[Kristoff]

USE JAVA!

What happen?!?
Someone set up us the JVM.
All of your platforms are belong to us!

[SmileyDude]

Why would you want to use C++? Maybe because you already have code written in C++? Maybe because you want to use a OO language, but don't want to use an under-supported language like Obj-C or a VM based language like Java?

The fact-of-the-matter is that this is broke under OS X. Not what language should be used, or what APIs should be used.

This shouldn't be a flame war... just a simple bug that needs to be fixed

------------------
dennis

[SmileyDude]

Anyways, I found this odd. Use printf and scanf. Then use printf and cin. Under printf and scanf, the buffer flushes properly. However, using cin after printf doesn't flush the buffer.

I bet if someone looks at the code, they'll find that the code for cin is calling flush() properlly, but the code for cout.flush() is broke. On the other hand, the code for scanf() is calling flush(stdout) and all is well there. I would look, but I don't have access to my OS X machines at the moment...

------------------
dennis

[Gametes]

So, what do we do now?
I mean, I can't fix this problem; I'm in freakin CS150 for cryin' out loud!
Somebody needs to whip the Darwin team or d/l the source and fix it themselves!

[LordJavac]

I think the first step to resolution is to make sure that the problem is known. Does Apple (or the Darwin team) know about this bug? If not, then we should let them know in the form of a bug report. I have a feeling that this is an oversight since Apple was most likely pushing to get the Obj-C compiler working, but that does not excuse the flaw only (possibly) explain it.

[starman]

This is a ridiculous thread.

So you found a bug. Big deal. Just because your little program ran on three other platforms doesn't mean that every single million-line application will run the same on those same three platforms. At work we deal with Solaris, Linux, IRIX, Windows, and now Mac OS X. As portable as code WANTS to be, it will never, ever work exactly the same on every platform. The ANSI standard helps - God knows it was a mess beforehand - but its implementation isn't perfect on every platform.


As for sneisen's comment - you really don't understand how cross-platform code works, do you? Why not build under Objective C? Easy - because that means to run the same code on other platforms means that THEY have to compile and run under Objective C. Hmm..last time I checked there was no O-C compiler for Windows..or Linux...or Solaris. Please tell me if I'm wrong. Even if there WAS a compiler, O-C is such a niche that it's not worth the trouble in the long run to maintain. Also, some of our code gets put onto chips. Again, no O-C binary support there either (or for Java for the work we're doing). Embedded systems generally use C and C++. It's all about the target for the project you're working on.

Mike