Edit the file using c++ without creating new file

I got lot of solution from your forum but my problem is little bit different to the other.
Problem is how to edit file without creating new file. Suppose i have student file and in that file i have lots of record but now i want to change particular student information so for that i want to search the position and then i have to modify that particular position. So without creating new file how to make change.
Plz help me ASAP...

Waiting for your earlier response.
Thanks...
Pankaj.

Well Im not sure if I get what the problem is because I dont think this is really a "problem", but maybe structs could help you... Saving a struct to a file(in binary format) and then load it later, change the desired value and save it again should work, no?

now if you're willing to change a text file directly, you could search for the desired value using some function for that purpose, and then change it.. But Im afraid you would not be able to write more characters than the current value, because you would overwrite the other characters.. BUT you could save the rest of the file, write the desired value and then append it to the file again.


Well, if I understood it right, I believe that in theory it is quite easy..

I have a class and i am storing object in text file and now i want to change only name and that name may contain more character or may be less. So without creating new file can i do the same?
If yes can i have that few line edit code.

Thanks...
Pankaj

Dont know if it is what you're looking for friend, but I made some code trying to teach how to change a single value in a file without changing other values

The header file:

Code:

#ifndef dataToStoreHeader
#define dataToStoreHeader

#include <stdio.h>
#include <stdlib.h>
#include <iostream>
#include <fstream>
using namespace std;

class dataToStore
{
private:
    char someString[256];
    int someInt;

    std::fstream *dataStream;
public:
    dataToStore(char *someString, int someInt){
        strcpy(this->someString, someString);
        this->someInt = someInt;
    }
    dataToStore(void){
    }
    int getInt(void){
        return(this->someInt);
    }
    char *getStr(void){
        return(this->someString);
    }
    void setStr(char *someString){
        strcpy(this->someString, someString);
    }
    void setInt(int someInt){
        this->someInt = someInt;
    }
};

#endif

and the main file:

Code:

#include "dataToStore.h"

#define FILE "data.dnl"
#define OUT_MODE std::ios::out | std::ios::binary
#define IN_MODE std::ios::in | std::ios::binary
#define DATA_SIZE sizeof(dataToStore)

int main(void)
{
    // here we declare a new dataToStore object
    dataToStore *data = new dataToStore("Hello, ", 7);

    // and here we declare a pointer to the begining of the
    // memory area where the new data varibable is
    char *dataPtr = (char *)data;

    // here we make a ofstream to write data to,
    // and a ifstream to read data from the file
    std::ofstream out;
    std::ifstream in;

    // we open the file in binary mode, write the data to it and then close it
    out.open(FILE, OUT_MODE);
    out.write(dataPtr, DATA_SIZE);
    out.close();

    // change the values just to see that only the right
    // values will appear on the screen
    data->setInt(0);
    data->setStr("this is a string");

    // we now open the same file in binary mode to load the data
    in.open(FILE, IN_MODE);
    in.read(dataPtr, DATA_SIZE);
    data = (dataToStore *)dataPtr;
    in.close();

    // print the values...
    std::cout << data->getInt() << "\n" << data->getStr() << endl;
    // ...and change the string value, keeping the int value unchanged
    data->setStr("World!");

    // Now lets save the new string value to the file
    // Open the file and save the data
    out.open(FILE, OUT_MODE);
    out.write(dataPtr, DATA_SIZE);
    out.close();
    data = (dataToStore *)dataPtr;

    // The file is saved. Lets change both values again.
    // These values will never apear on the screen
    data->setInt(666);
    data->setStr("Mwahahahahaha!");

    // Load the data
    in.open(FILE, OUT_MODE);
    in.read(dataPtr, DATA_SIZE);
    in.close();
    data = (dataToStore *)dataPtr;

    /* Ok, now simply print the values.
       As you can see, the int value is unchanged, but the string value
       now contains "World", not "Hello" */
    std::cout << data->getInt() << "\n" << data->getStr() << endl;

    delete data;

    getchar();
    return(0);
}

You could write the content of the class to a text file instead of printing it on the screen...

If you wish to change a value inside a text file without a binary file to store the data(a normal txt file, for example), just create a function that will look for the desired value, then save the rest of the file, change the value, and append it again.

Seems like a homework for me. I haven't got the slightest idea about what you want to do here. Maybe you can elaborate more?

If you want to edit a file, you must open the file with read/write option. And it won't create a new file. Maybe you should read this to figure out how to do file I/O. And maybe then you can think of the solution yourself.

Dante, not to rain on your parade, but I have a few issues with your code, as well.
First off, how about using a std::string instead of a char array?
Secondly, there is absolutely no need to use new in main. You're just making it hard on yourself.
Thirdly, it would be better to simply use the >> operator to write the stuff to the file instead of raw binary. This breaks encapsulation. And since you have a class, this could easily lead to maintenance nightmare and/or undefined behavior.
Instead you should have the class overload the >> operator to control how the data is written to file. Similarly, you overload the << operator to read it back.

Originally Posted by Elysia

First off, how about using a std::string instead of a char array?

I knew someone would say something about that... No reason actually, I just like using char arrays... It works ok for me...

Secondly, there is absolutely no need to use new in main. You're just making it hard on yourself.

I know... Like there is no need to use a char * variable, that was my choice...

Thirdly, it would be better to simply use the >> operator to write the stuff to the file instead of raw binary. This breaks encapsulation. And since you have a class, this could easily lead to maintenance nightmare and/or undefined behavior.
Instead you should have the class overload the >> operator to control how the data is written to file. Similarly, you overload the << operator to read it back.

Maybe, but write() is there to be used, isnt it? No one is going to mantain that, but if it was necessary there are comments all over the code.

Anyway, thanks for the tips

The problem is that while it is your choice to use these or not, when teaching newbies, you should teach them good C++ code, not your choice of C++ code.
So while it is certainly OK for you to use it in your own projects, it is preferable that you do not show it to newbies. They are sensitive to learning things the wrong way.

Also, re: read/write.
Mostly they are there because you might need them sometime. Especially for C code. But it isn't portable and it is not safe to use them on classes. Try doing that on a vector or a string (not a char array), and read them back. Do you think it will work?
With >> and <<, it will always work. One should expect similar for your own classes.

Originally Posted by Elysia

The problem is that while it is your choice to use these or not, when teaching newbies, you should teach them good C++ code, not your choice of C++ code.

I dont think my code is that bad to the point of being called "not good C++ code". Isnt what you're saying about good C++ code your own choice of C++ code? That being the case, there should be a standadized way of code to teach people, but as far as I know there is not. My choice of C++ code is my own good C++ code. I can't teach him how to code some better way because that is the best way I believe there is to teach someone something.

Originally Posted by Elysia

So while it is certainly OK for you to use it in your own projects, it is preferable that you do not show it to newbies. They are sensitive to learning things the wrong way.

Yet you said I should overload operators in an example for a newbie. What if he doesnt even know what is operator overloading yet? I would have to try and teach him what is happening while trying to explain something else. That not only would change the whole subject, but as you said "they are sensitve to learning things the wrong way".

Also, re: read/write.

Originally Posted by Elysia

Mostly they are there because you might need them sometime. Especially for C code. But it isn't portable and it is not safe to use them on classes. Try doing that on a vector or a string (not a char array), and read them back. Do you think it will work?
With >> and <<, it will always work. One should expect similar for your own classes.

I see what you mean and agreed, but the problem is that today people are used to depend on ready to use functions, classes, etc, etc... There is nothing I hate more than that... If he is a newbie, I believe he should first be able to write his own string class before using std::string. This way he would not only understand more about how things work, but would think of data just as a simple array of bytes, as it should be in my opinion. A string is nothing more than a char array.

Originally Posted by Dante Wingates

I dont think my code is that bad to the point of being called "not good C++ code". Isnt what you're saying about good C++ code your own choice of C++ code? That being the case, there should be a standadized way of code to teach people, but as far as I know there is not. My choice of C++ code is my own good C++ code. I can't teach him how to code some better way because that is the best way I believe there is to teach someone something.

The problem is that there is a different way of doing C++ than C.
You seem like a typical example of someone who has a C background. By C++ purists, this is the "wrong" way. If you're going to learn a language, then you should do it after the standard practices adopted by that language.
The idea is to teach newbies the purist way, and then they may derive a way that works from them from that.
If the OP is not someone with a C background, then you are needlessly complicating things by including things that really aren't the "C++ way". Therefore it is bad.

Yet you said I should overload operators in an example for a newbie. What if he doesnt even know what is operator overloading yet? I would have to try and teach him what is happening while trying to explain something else. That not only would change the whole subject, but as you said "they are sensitve to learning things the wrong way".

What if they don't know arrays and how they are contiguous in memory? What if they don't understand the concept of writing and reading raw?
We're arguing semantics here. If you are a C++ programmer, then it is better to learn operator overloading than reading and writing raw.

I see what you mean and agreed, but the problem is that today people are used to depend on ready to use functions, classes, etc, etc... There is nothing I hate more than that... If he is a newbie, I believe he should first be able to write his own string class before using std::string. This way he would not only understand more about how things work, but would think of data just as a simple array of bytes, as it should be in my opinion. A string is nothing more than a char array.

While I vehemently disagree with that, it doesn't change the facts. You should write operator for your string class as you would for any other. Then you can use << and >> outside the class, as with everything else.
Now, when you implement those operators, you can go ahead and do read/write raw because the class knows how it's implemented and therefore knows how to serialize itself.

Originally Posted by Elysia

The problem is that there is a different way of doing C++ than C.
You seem like a typical example of someone who has a C background. By C++ purists, this is the "wrong" way. If you're going to learn a language, then you should do it after the standard practices adopted by that language.

The "purist" streak of C++ is unfortunate, and it's obviously just political. While I try to use C++ alternatives (because I already know the C ones, and you might as well learn both), I don't understand the finicky anal objection about using standard C either (unless it means using too many libraries, which some forms of it might).

Here's an inverse version of the politics: perl purists swear by "TMTOWTDI" (there's more than one way to do it).

There's more than one way to do it - Wikipedia, the free encyclopedia

The language was designed with this idea in mind, in that it "doesn't try to tell the programmer how to program." This makes it easy to write extremely messy programs, but, as proponents of this motto argue, it also makes it easy to write beautiful and concise ones.

It seems to me that C++ may or may not have been designed with this in mind, but it certainly has that potential. If "C++ purists" don't like C syntax, it should be removed from the standard. It should fail the compiler. Otherwise, what's the problem?

Again, I do use std::string in place of char but I think the syntax is actually more awkward, ugly, and unintuitive by contrast, for many things, so I don't see any harm in exposing "C++ purist newbies" to some freedom of choice, unless we are afraid of debunking some myths about "evolution"

So to me this is just politics: on the one hand, you have people exercising a choice, on the other, you have people who want the option banned or to convince everyone that there is only one correct choice (which amounts to the same thing). If the only supporting evidence you can conjure up here is about style, "purism", or whatever, who cares?

There is a place and time for everything. C++ was designed a safer and higher-level alternative to C.
Using C within C++ is usually going backwards to the plain old, and usually unsafe, C.
It's like using the Win32 API within managed language. WHY??? It's pointless to do so unless you must.

C++ is backwards compatible with C and for a good reason. Not for you to mix C and C++ as you will, but to be able to interface with C code. It allows you to transition to C++ code gradually without having to rewrite everything.
Using C facilities in C++ also reduces encapsulation, safety and increases maintenance costs.
C++ is a multi-paradigm language that has a lot of tools. That means YOU must be able to use these tools correctly, and it is part of our "job" here to make sure the newbie understands when to use these tools.

Dante's example could certainly be written in only C++ code. When you expose a newbie to a lot of C code within C++ they will think it's the "only" way to do it.
If you are like that, you might as well go use C instead of C++.
Now. Enough rants.

Learn C++. Learn C. Then do whatever fancies you. But keep it pure when teaching other newbies. They will learn in due time to find "their" path.
The last thing we want is some C/C++ hybrid out in the world who doesn't know the consequences of that.

Originally Posted by Elysia

The problem is that there is a different way of doing C++ than C.
You seem like a typical example of someone who has a C background. By C++ purists, this is the "wrong" way. If you're going to learn a language, then you should do it after the standard practices adopted by that language.
The idea is to teach newbies the purist way, and then they may derive a way that works from them from that.
If the OP is not someone with a C background, then you are needlessly complicating things by including things that really aren't the "C++ way". Therefore it is bad.

Yes I do have C background... Anyway I still dont believe that mixing C and C++ makes the code "bad", but I have to agreed that it can make the code a little more confusing for those who arent very familiar with the C programming language and is different from "pure" C++ code. But I like programming the "C way", and as long as it works for me I'll keep doing it... As I said before, I can't teach someone to code diferently than I do... Now if you believe that I shouldnt try to help C++ programmers just because Im more of a C programmer than a C++ programmer, I cant help you... I'll still try to help the way I can and am comfortable with.

Originally Posted by Elysia

What if they don't know arrays and how they are contiguous in memory? What if they don't understand the concept of writing and reading raw?
We're arguing semantics here. If you are a C++ programmer, then it is better to learn operator overloading than reading and writing raw.

And if you're a programmer, you should learn what is an array and how it works. I believe one of the first things one do when starting to learn any programming language is counting to n using a for loop and an int array, not overloading an operator.

Originally Posted by Elysia

While I vehemently disagree with that, it doesn't change the facts. You should write operator for your string class as you would for any other. Then you can use << and >> outside the class, as with everything else.
Now, when you implement those operators, you can go ahead and do read/write raw because the class knows how it's implemented and therefore knows how to serialize itself.

Most programmers I know do disagree with that, but I still believe someone who is still learning should first learn how a function works, not what it does. I cant really say what kind of code I should show him since I have no ideia of his current level, so just be happy with the C mix code and keep reading your book, because Im not your teacher here, just a member trying to help using my everyday style. I wont change my style just because someone thinks it is wrong to use C style, even though I understand his point

Originally Posted by Dante Wingates

Yes I do have C background... Anyway I still dont believe that mixing C and C++ makes the code "bad", but I have to agreed that it can make the code a little more confusing for those who arent very familiar with the C programming language and is different from "pure" C++ code. But I like programming the "C way", and as long as it works for me I'll keep doing it... As I said before, I can't teach someone to code diferently than I do... Now if you believe that I shouldnt try to help C++ programmers just because Im more of a C programmer than a C++ programmer, I cant help you... I'll still try to help the way I can and am comfortable with.

No, the way you write code yourself is up to you. But you should adapt when teaching others code. You are well-versed with your programming style. Others are not.
In the C++ forum, you should strive to teach principals of C++: encapsulation, type safety, etc. You don't show up in the C++ forum and throw some C code at newbies. That's just wrong.
So, all I'm saying is that you should strive to follow the C++ principles and write "pure" C++ code when showing it to newbies. Code that you write for yourself you can do whatever you want with.

And if you're a programmer, you should learn what is an array and how it works. I believe one of the first things one do when starting to learn any programming language is counting to n using a for loop and an int array, not overloading an operator.

But basic array understanding and raw reading/writing and string handling are different concepts.

Most programmers I know do disagree with that, but I still believe someone who is still learning should first learn how a function works, not what it does. I cant really say what kind of code I should show him since I have no ideia of his current level, so just be happy with the C mix code and keep reading your book, because Im not your teacher here, just a member trying to help using my everyday style. I wont change my style just because someone thinks it is wrong to use C style, even though I understand his point

Most programmers who think that have a C background. They are not well versed with C++ or fully utilize it. They are different languages. You must accept that.
For example, you may use char arrays and even fflush(stdin) in your apps, if it works. We don't care. But we do care when someone tries to teach that to newbies.
Part of C++ is to be able to use something without knowing how it works. That is part of encapsulation, which is a very important and powerful concept in C++.

Originally Posted by Elysia

No, the way you write code yourself is up to you. But you should adapt when teaching others code. You are well-versed with your programming style. Others are not.
In the C++ forum, you should strive to teach principals of C++: encapsulation, type safety, etc. You don't show up in the C++ forum and throw some C code at newbies. That's just wrong.
So, all I'm saying is that you should strive to follow the C++ principles and write "pure" C++ code when showing it to newbies. Code that you write for yourself you can do whatever you want with.

Ok, ok.. This is like a loop... Is that part of the forum rules? Not showing C style code to a newbie?

Originally Posted by Elysia

But basic array understanding and raw reading/writing and string handling are different concepts.


Most programmers who think that have a C background. They are not well versed with C++ or fully utilize it. They are different languages. You must accept that.
For example, you may use char arrays and even fflush(stdin) in your apps, if it works. We don't care. But we do care when someone tries to teach that to newbies.
Part of C++ is to be able to use something without knowing how it works. That is part of encapsulation, which is a very important and powerful concept in C++.

We who? You're the only one complaining... I said a lot of times I do understand your point, but you cant seem to get what I said a lot of times: I still dont believe that mixing C and C++ makes "bad" code. You believe it is bad, and I do not, so dont mix it... I tried to keep it simple for him and anyone who reads it, and I'll keep trying to keep it simple my way.

He wont stop programming just because he saw some C with C++ code, C++ programmers can easily read C code.

Have a nice day... Hallelujah