I compiled with MS Visual C++ also. I used version 7.1 (.NET 2003). Are you using version 6.0? That's about 10 years old, can you upgrade to a newer version?
I compiled with MS Visual C++ also. I used version 7.1 (.NET 2003). Are you using version 6.0? That's about 10 years old, can you upgrade to a newer version?
Yeah, it appears it's a Visual C++ 6 problem (that was fixed in 7 which I don't have) Any ideas for a good compiler for windows?Originally Posted by brewbuck
Visual C++.
Just upgrade. There is an express version of 2005 or 2008 that is free if you don't want to or can't pay for the full version.
Thanks, I'll use the express version if it can actually compile and run programs/dlls. Any idea of what the restrictions are?
I think it doesn't include MFC, but there aren't many restrictions on C++ code. They use the full optimizing compiler and you're allowed to use them on commercial applications.
Thanks. I actually installed MinGW (which uses GNU's compiler, gcc and g++) because I had to install the entire Visual Studio Express if I want MS.
But now I get another problem. If I use printf( *it ); instead of std::cout it throws an exception:
no matching function for call to 'printf(std::basic_string....' (rest elided).
Any idea why and how I get around this?
Or in most cases:Code:printf( it->c_str() )
Code:printf( "%s", it->c_str() )
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
Shouldn't the inner vector be const also?Code:void getData(const std::vector< std::vector<T> > &data)
Why would you want to use printf() in a C++ program?But now I get another problem. If I use printf( *it ); instead of std::cout it throws an exception:
No, that's not how vector works.
Indeed. I have to second this notion.Why would you want to use printf() in a C++ program?
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
I'd want to use it because iostream provides no genuine advantages over stdio, and several disadvantages.
System: Debian Sid and FreeBSD 7.0. Both with GCC 4.3.
Useful resources:
comp.lang.c FAQ | C++ FQA Lite
Err ... iostream works with std::string. I call that an advantage.
More importantly, it works with generic code in general.
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
>> Err ... iostream works with std::string
And any other streamable class, many of which do not have c_str() style functions for easy workarounds.
Sure, but it works pretty sloppily.
- Try getting a line of input from cin. As we all know from C, scanf() is error-prone and we should be getting whole lines with fgets() and parsing that. So dont use std::cin >> str (it'll trip up if there are any spaces anyway) but std::cin.getline(arr, len) or std::cin.get(arr, len). Mind you, those input to char arrays. If you want std::string you need the obvious std::getline(std::cin, str, len).
- The "new and improved" way to open files is to use ifstream and ofstream. Strangely, to tell them the name of the file -- a particularly stringy kind of thing -- you have to give them an "old and evil" array of char. But anyways, just use std::ofstream logfile(filename)... oh, snap, std::string doesn't define operator const char* so make that std::ofstream logfile(filename.c_str()). Fortunately you wouldn't want to put that file anywhere in particular, otherwise you'd have to pile on the ugly with std::ofstream logfile((dir + "/" + filename).c_str()). And if dir is a C-string... well now we're getting into the deficiencies of other classes, so enough of that.
- Nevertheless iostream works with std::string a lot better than some other classes, like std::map.
Mind you, how much can you expect a foreign class to operate with iostream, when iostream's classes can't even interoperate with themselves. Maybe you have a std::ostringstream you'd like to print out (gotta do something with those). You'll likely try cout << oss which is wrong, you need cout << oss.str(). Neither can you cin to an istringstream. Once again, you need an extraneous std::string object (and God forbid your ostringstream holds a filename to open... good thing you can chain method calls: std::ofstream outfile(oss.str().c_str()).
Last edited by zx-1; 04-01-2008 at 08:31 PM. Reason: lol parens
System: Debian Sid and FreeBSD 7.0. Both with GCC 4.3.
Useful resources:
comp.lang.c FAQ | C++ FQA Lite
You listed several trivial issues, the first of which occurs in C as well so is moot, the second of which I agree with but will be fixed in the next standard (and is super trivial), and the third of which doesn't make sense (are you saying streams are worse than printf because they only work with string?).
In addition, you complain about more trivial stuff like the extra effort needed to use some streams in unobvious ways, even though you have to jump through the same (or much more difficult) hoops with the printf style solution.
And yet, you failed to address the reason given for streams being better than C style i/o, which is that they work much better with generic code. (They are also often safer.)
If you are uncomfortable with the look and feel of streams, fine, but your original assertion was wrong.
And do you really think using format specifiers with ellipsis are better?
Code:printf( "%s blah blah %d, %2.3f blah", str, num ); // Oops, forgot the 3rd arg, boom!
