Printable View
I have begun studying C++ file processing, ofstream, ifstream and all that. I was wondering though how practical this stuff would be when everything is usually stored in databases?
Doesn't everyone have the software connect to, lets say oracle or postgres and let the database do all the file work? Or are there circumstances where C++ file processing would be useful?
I don't know if I want to live in your world, that doesn't have pictures, or music files, or movies, or...Quote:
Originally Posted by darsunt
Actually most things are NOT stored in databases. All those files on your hard drive used to boot the OS and run programs aren't in a database...
note that "databases" dont "do" anything. they do as much as this website's .php file of this page your viewing--nothing. it requires software to make it useful (ie the oracle DBMS).Quote:
Originally Posted by darsunt
also note that databases are simply special cases of files. that is, without files, databases couldnt exist. databases, in their infancy, used to be stored in regular files and were much more simple and primitive than they are now. databases today seem very different because they are designed specifically to be able to store, retrieve, and manipulate very, very, very, very large amounts of information efficiently.
What I mean is business applications. File processing for medium and large sized companies like maybe your local accounting firm, or your local retail chain. Keeping track of tax, financial or commercial transactions, or doing form processing.
I have written some software that has a GUIs, code to enable users to enter information and ask for information. Then the software would connect directly to a database and use sql statements to talk to the database, which would handle the data. The 'files' I suppose would be the tables in the database, and I never used C++ file processing capabilities ( I didn't know how to use them.) I've written the front ends with html, C++ .NET, asp and C++.
Right off hand, under these circumstances (online or offline business software) I cannot see any practical use for C++ file processing. However I had a professor who mentioned that C++ file processing could be very useful to some corporations. Are there special/important areas where C++ file processing could be more useful than databases, that I am not aware of?
Well, the obvious one in your scenario is the database. I mean, Oracle or SQL or whatever has to deal with those files somehow, right? That's not (completely) magic. (I have no idea what language either of those was developed in, but somebody had to know how to deal with files.)
You may want to write out log files (error handling is the obvious one, but also daily reports perhaps, or maybe some database updates get written to a file to be processed in a batch during off-peak hours).
I'm sure I'm missing several good examples.
Most software has some sort of config file that controls the settings used for running it... If you're using a database, it has to know the Address of the database and what username/password to use when connecting, the database name... All that would be stored in the config file (unless you're using Windows, in which case you could store it in the registry).
I'm working in a company right now which needs to crunch huge text files (tab delimited, columns of numbers) - simple filtering on specific values, some conversions, splitting or combining to destination files, etc. My coworker who doesn't know C or C++ knows how to patch together VB programs, open up some SQL query, and then complains that the program takes forever. These files can be 1 gig or more sometimes.
The program is out of his control, so-to-speak, for most of the time... thanks to reliance on magic black boxes.
Funny. He is more comfortable calling cryptic queries and linking all sorts of magic which I can't even follow nor compile if I wanted to. Whereas I do the old fopen(), read(), write(). And my programs blow his away.
"Applications" do so many different things. One can't just say that "ofstream" is not useful - that's like saying "Because the applications I've written in my life doesn't use 3D, so why should we have Direct3D?". Obviously, if your application can do all it needs to do without files, then you do not need to use filestreams in your application. I work on embedded systems, and I rarely find my code working with file streams - but that's not to say that there isn't a use for the functionality provided by files treams.
File streams have their purpose. Databases have their purpose. If you never write applications that uses files, then file streams tend to be pretty meaningless, yes. And for those who write small/medium size applications that do other things, database interfaces are pretty pointless.
Some problems can be solved with either databases or files (and about equally well). Many problems, one will be noticeably better than the other - which is better and which is worse depends on the scenario.
One of the drawbacks of using a database engine is that it requires a fair bit of overhead. If all you want to do is store a few dozen dataitems, then a database is a bit overkill. If you want to store millions of data items, then wriitng efficient code to handle that scenario is going to be hard, so using a database may be the right choice.
There are many colours out there, not all of them shades of white or black. Use the tools that solve the problem.
--
Mats
So how about this use. It seems C++ file processing could be used to create templates for, lets say, legal forms, and then use it to fill it and update these forms. I've been using Excel but it seems file processing could do it much better.
That would work (assuming you're not expecting to be able to write a .docx file out of this without a fair bit of work -- or at least I've not seen a very good explanation of the file format).
Use file streams to read and write files in the applications that you write. That is their use. But file streams will not replace the work of an application or database management software. File streams are a means to an end, not an end itself.Quote:
Originally Posted by darsunt