Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Control Flow

2 (2.2%)

Arrays, Strings, Pointers, and References

8 (9%)

Functions

4 (4.5%)

Basic object-oriented programming

30 (33.7%)

A bit more advanced OOP (Composition, Operator overloading, Inheritance, Virtual Functions)

18 (20.2%)

Templates

8 (9%)

Other (Explain)

4 (4.5%)

Working with files?  (Streams)

15 (16.9%)

Total Members Voted: 89

[Outcast Orange]

Thank you very much Blacken.

I found that first link, but not that second example.
Much more useful.

[Blacken]

I am sure you found a link to Google, yes. Google mastery assures you find the right one.

Signed,
Apparently A Goddamn Google Master

[Jamp]

big and awesome post by blacken

Hi, I have some prior programming experience, but my education in this area is very non-consistent (still high school), so I decided to do the exercises, in Python, and then maybe in C or C++.
I am at third item now ( hope I will make it to the end), but there are some things I am not sure about. There maybe could be list of basic methods for each data structure to implement, because I don't actually know what to program . Like I made insert, append, set, get but there are also mentioned things like searching for linked list, what does it? Also a Python-specific questions (but may relate to other higher-level languages), there is no mechanism for getting memory, i made malloc function returning array chunks and interface in python just means class with empty methods? And thinking about sane api for tree, again not sure what is it, maybe I'll just try to make all the methods in "Common Operations" section.
I may provide my code when I get done more of the exercises if somebody wants, for my and hopefully others reference.

[Outcast Orange]

Does anyone know how to change the amount of lines the console window will hold?

The scroll history isn't long enough for me, so I'm hoping there is a way to extend it.

[Normandy]

I'm assuming you're on windows, because you're calling it a console.

There's 300 lines, if you need more than 300 lines, you may wish to reconsider your method of output.

Right-click the window bar and click on properties. Screen Buffer Size is the size of the history, and Window Size is the size of the window.

[Outcast Orange]

If that is possible, it should be possible to set that in my program code.

I'll look up the windows commands for that myself.

[Normandy]

I wouldn't do that if I were you. Just program.exe > output.txt or something like that. It'll pipe the standard output of your program to a text file for you (or program.exe 2> output.txt if you're outputting to stderr).

Once again, is there any unavoidable reason you need more than 300 lines of history? I'm just curious. We might be able to suggest better alternatives.

EDIT:
Scratch that. We will be able to suggest better alternatives.

[Outcast Orange]

That output thing sounds great. How do I do that output text thing?

Maybe a tiny sample, a dabbling few lines of C++?

I'm making a text based adventure that has optional debug text,
 and it prints out huge swaths of primarily useless information
 which only becomes useful in the event of a bug.

[eerr]

Spoiler (click to show/hide)

well, I know the procedure in C

instead of printf(string ptr);
fprintf(File outputstream, string ptr);

assuming you know the directory your C program starts in,

File f= fopen(filename.txt, "a"));

will open a new file named filename.txt, or just open it if it already exists in the current directory.
When writing, the letters are appended to the end.

fclose(fp);

I'll look up the C++ methods in a sec, maybe.
Edit: found an example, you can submit a whole directory path if you want, or just the filename to use the same directory.

Code: [Select]

    #include <fstream.h>
    int main()
    {
        fstream file_op("c:\\CoderSource_file.txt",ios::out);

        file_op<<"Test Write to file";
        file_op.close();
        return 0;
    }
easy as pie. Even more impressive, is if you split them up into two different programs so you can have one programs input connected to another program's output.

one program writes to in, one program writes to out.
reciever < source.
I know this works in C, and I expect no different from C++

hell if filereciever is a text file, you don't actually need to open a different stream type.
just invoke your program with a cmd, filerecieve.txt < output
 

I'm assuming

[Normandy]

It's when you run the program. It's not a code thing. eerr is correct, but if you're working with outside APIs that's not always possible. When you run the program, you'll do something like this on the command line:

myprogram.exe

Instead of just doing that, type this:

myprogram.exe > output.txt

[Outcast Orange]

Wait, so should I just open a file at the beginning of main and write everything both to the console window, and a text file?
That doesn't sound intuitive.

I just want everything that goes console to be mirror into text.
Is there a better way to do that?

[eerr]

In C, and I assume C++

three streams are opened by default.
a standard in,
a standard out,
a standard error.

when opened plain with the console,
standard out prints to the console, and standard in reads console input.
coute, and cin, I think?

you just need to open a file (which works as a stream,) and print to that, as well.
(identical to coute, if you open it with "a" for append? I dunno)

Theres also a pipe-shenanigan method that I don't know.

Wait, so should I just open a file at the beginning of main and write everything both to the console window, and a text file?
That doesn't sound intuitive.

I just want everything that goes console to be mirror into text.
Is there a better way to do that?

reading more carefully,
Theres a command for forking a stream into two streams, I just don't know it.
It's not hard to write twice instead of once -.-

[Normandy]

Just write a method output_string(string str) { cout << str; file_op << str; }. file_op is a global variable that you open during your main method. There is an even better way of doing it, but it's slightly more complex.

EDIT:
Now that it's not late at night / early in the morning and I'm more lucid:

You should not be outputting giant swaths of information to the console for you to read. That is the job of the debugger and the computer. gdb will output large swaths of debug information if you really need it, but I doubt it. When you're debugging, you should be using asserts, not outputting information for yourself to read. And when an assert goes wrong, you can use your debugger to print a stack trace, output the relevant variables, whatever. It's not just good programming practice, it's actually far easier.

Suppose you want to make sure your movement function is working properly. You do something like this:

Code: [Select]

oldX = player.x
player.moveLeft()
assert(oldX - player.x == 1) //this is assuming moving left will decrease the x coordinate by one
You should not be reading debug data off the console to make sure that the player is moving correctly. Don't fix bugs as they happen; check them ahead of time. Of course, this is a very simple example, but when you're dealing with very complex examples (especially with large calculations), this is a godsend.

[alway]

What's the best and/or easiest way of figuring out how long a particular section of code spends running in C++ (for optimization purposes)?
I'm using MSVC++ 2008 EE if that helps.

[eerr]

*shrug*