C++ question

can't help you mate but what textbook are you using? I have been thinking about learning a bit of programming lately because I know almost nothing about computers beyond basic Windows shit and it has been bothering me a bit.

>>383077
I'm using this one: https://www.amazon.com/gp/product/0134498372/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1

It's expensive but there is an eighth edition of it for free if you google "Starting Out with C++ from Control Structures to Objects (8th Edition).pdf" and click the first result.

>>383074
In better detail, I would just like it explained in the context of the the disk the file is stored in, the RAM, locations of the file in disk and RAM, and the file stream object (if all of that makes sense).

Hey OP - a couple of preliminary questions:
How well would you say you understand the IOStream in C++? That's going to be the largest difference you'll have to wrap your mind around.

And, how do you feel about memory structures in C++? For instance, here's the method signature for the open() method:

void open(const char *filename, ios::openmode mode);

How do you feel about what is going on in "*filename"? Because, that's the key to how the underlying memory structure is going to treat the filestream object.

I'll try to get more specific based on your answers.

>>383074
basically it's your way of interfacing with the input/output file through your program

for example, if you want to write to "exmaple.txt", how would you even do it in the program?
You'd need code that can locate and write to a file, which the file stream object contains.

>>383074
>so far it has explained everything very well in a good amount of detail.
Clearly it hasn't, because if you know what files are, you know what streams are, and you know what objects are, then you'd know what a file stream object is.

Objects let you wrap data with code that encapsulates the data and implements an interface around it, transforming it, controlling access to it, etc.
Streams are C++'s batshit-insane syntactic sugar around certain forms of I/O, that let you combine I/O and formatting by writing shit like

cout << "An error occurred opening the file" << endl;

Where cout is an object that represents the standard output, and will print onto the screen stuff that's "shoved into it" by "<<", the text string is also an object by dynamic typing, which allows the endl object to shove a "\n" into it.

To read an IOstream statement, you need to see which way round the >>s are going (for reasons, you need to use ">>" and go left-to-right when the destinations are variables, and use "<<" and go right-to-left when the destination is a stream), then read along the direction of the arrows all the way to the end of the line. This will tell you where the data is actually going. Then (assuming none of the things in the stream are objects that do something batshit):
- all the stuff on the line with <<s gets munged together in the order it is on the line, and shoved out the stream on the left.
or
- all the stuff in the start of the line with >> gets smeared across the variables to the right of it, in the order the variables are in the line

You can use >> and << on the same line, to create something only the compiler will ever understand.

Once you have a file stream object, you can use it in stream statements just like you use cout and cin.

>>383088
Thanks for your response. I'm still kind of in the basics (Chapter 5) but I'm trying to learn basics as well as I can so I could build up new information onto them.

Well, I understand that the iostream header file creates a way for the program to interact with the console, where you can display information you write in your code, and also store information from (meaning taking text from console and putting it into a variable using the cin object). I guess I never really felt the need to question iostream as much as fstream.

>void open(const char *filename, ios::openmode mode);
I didn't get to functions yet so I don't know them in detail. But it looks like this function will take 2 arguments because I know they start with void, and would define a char variable for you, which would be the file name. I don't know what * in the *filename means or ios::openmode mode.

It seems like it might take you a lot of effort to explain to me, but see if my reply to the person below you is correct.

>>383090
So what the file stream object does is just provides code that can locate where and what type of file it is, and puts it in a variable? And then I can use member functions like "open", to import the file contents into the variable and work with them using other member functions?

File: 300px-File_table_and_inode_table.svg[1].png (4KB, 300x147px) Image search: [Google]

4KB, 300x147px

>>383087
C++ streams just wrap C filehandles, so read up on how C treats files, and then imagine a C++ object encapsulating it so you can do OO stuff on it.

C++ doesn't get involved in the actual IO, it just converts C++ stream calls into C filehandle operations.

>>383096
Didn't think about using >> and << on the same line. I did learn that >> and << dictate the flow of information like arrows.

Could you write a simple single statement with both << and >>?

>>383097
So, the relevant idea is that C++ is built around using pointers as addressable locations in memory-space, which is what the asterisk in front of *filename is doing - providing a pointer to the location of some memory. The system is keeping track of *where* it can find the rest of the data that's being pointed to by that address, but you don't need to load it all into RAM at once, and that's because of the file stream object. You get a serial interface to the byte array that we're calling a file, and read it in chunks from the filesystem into RAM.

>>383111
I tried out this idea, and it seems like it doesn't compile. May be because they're really just bitshift operators pushing streams into an output/input object, and you can't go both ways.

>>383117
Ok I think I'm starting to understand enough about it so that it wouldn't bother me. It provides a location in memory of where the file is so the member functions of the object could work with it?

Yeah I'm thinking how would I use >> and << in the same statement. I wouldn't know how to use >> and << without first starting with either cin or cout.

File: figure1[1].gif (14KB, 571x361px) Image search: [Google]

14KB, 571x361px

>>383117
>>383119
The data isn't actually in RAM at all: what comes back from open() is a "file handle": information that can be used to remind the kernel about a contract it made to provide access to a file.

When you open a file, what actually happens is that the kernel opens the file (you, the program, don't need to know what "opening a file" actually entails, and the process can be different depending on what file you're opening*), and returns you a file handle. You can then use this handle to read and write the file, or to "mmap" the file into your own address space. If you want to read, you tell the kernel "I want to read, here's the filehandle you gave me, this is what I want to read, and this is where I want it", and the kernel suspends you, reads the data for you and puts it where you asked, then wakes you up again. Writing works similarly. In all cases, you don't need to care how the file gets read or written, you just act like you're calling a function, and when you wake up again, you think you're returning from a function and the work has been done.

This process of asking the kernel, being suspended, and being awoken when the work's done just as if you'd called a function is called a "syscall".


* for example, opening a file on disk, on tempfs, or on nfs will be a very different procedure

File: 1497908506474.jpg (406KB, 1546x1024px) Image search: [Google]

406KB, 1546x1024px

>>383121
Ah okay, I think this makes it clearer. I think the problem was when the fact that, so far, everything felt like it was happening within the program itself (like if I would define a variable, write to it, and display it in console. The contents of the variable, which is in my code, was also written in my code or in the console. But now, some connection/link between a file somewhere on my disk and the code was made. That confused me and I couldn't understand this invisible connection. But what you wrote there cleared it up. It makes sense that I don't need to know whats going on in the kernel exactly.

Thanks a lot for spending the time to explain this stuff to a pleb like me. However, I'm still curious to use >> and << in the same line. Maybe my book will get to it eventually.

>>383134
Here's one:

int val=0;
std::cout<<"You wrote : "<<val<<std::endl<<(std::cin>>val)<<"\r"<<"\t\r\n"<<std::flush;

( https://stackoverflow.com/questions/6597654/output-and-input-at-same-line-using-iostream )

I'm pretty sure you shouldn't do this though. It's not very common, and it's not exactly easy to read. If it's not in your book, this is probably because it's not something you should be doing.

>>383139
Why does he write std::?

Also I tried doing this:
#include <iostream>

using namespace std;

int firstNum = 2, secondNum = 0;

int main()
{
cout << firstNum << (cin >> secondNum) << endl;

return 0;
}


But it won't work. And yeah, it does make it hard to read and I wouldn't do that, but if I got it to work I might understand everything better.

>>383156
>Why does he write std::?
You need to tell the compiler what namespace to find your objects in.
You can either tell it explicitly where everything is (std::cout, std::endl, etc.) or you can tell it where it should be looking (using namespace std;).

If you take one of your programs that works, and take out the "using namespace std;" line, it will stop working (because the compiler now can't find the objects you're asking for). If you then add std:: to all your couts, cins, etc. it will start working again.

>>383162
One of the things I don't understand well is "using namespace std;" I just reread the explanation in the book but I'm still not sure. What is a namespace exactly? And the std part? Also, if you don't have time to respond then don't worry. I can always Google at the end of the day. You've helped me a great deal.

>>383166
It's basically the equivalent of a surname. John Smith vs. John Jacobs. Without "using namespace std", you would have to type cout as std::cout so that the compiler actually know what cout refers to. But simple programs will put the using part at top, and then when they say cout, the compiler automatically sees it as std::cout. This system exists because in real life, it'd suck if we all needed entirely unique names to be distinguishable, and the same's true in code.

>>383170
Thanks a lot for your help, man! I'm gonna continue finishing up studying the chapter. Have a good one!

>>383182
No prob. I (>>383170) am not the guy who was replying previously, just FYI.