|
It's just not that simple. A file is essentially an array of bytes on disc, which are written sequentially. There is no structure or other information, such as start of line, or record size or anything like that associated with a file(1). When you write a Carriage Return ('\r' hex 0D) to the file, it just appends a CR character at the current location in the file.
Exactly what you need to do, depends on what your exercise is.
If you've got a single string of text as shown above, you'll need to examine each character and decide what to do when you find either a '\n' (start a new line) or a '\r' (move to the beginning of the current line). When you find a newline character, you'll need to write that to the file, and use tellp() to record the current location. When you find a CR ('\r') you'll want to then use seekp() to move to the location returned by the previous tellp() . Don't forget to initialize the variable you use for the result of tellp() when you open the file.
If, on the other hand, you have pairs of input, e.g an initial string ("This is some text") and then the text to overwrite ("Overwrite") then its a bit simpler. You still need to record your current location in the file, but you won't need to examine each character for a CR or NL. You just need to record where you are in the file before you write the line, then use seekp() to move back there when you get the next line of input.
In both cases, you may need to think about what happens when you have multiple lines of input. Are you expected to then move to then end of the current line and continue on, or continue writing at the current file cursor location.
If you know you will only have a single line of text, followed by a single line to overwrite with, things are simpler still. In this case, you just need to write the first line of text, then seekp(0) to the beginning of the file, and write the second line of text.
Note:
(1) This might not be true for all OS's out there. But if you're using Windows, Linux or OS-X, then that is the case.
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
Saboor Sarfraz wrote: but instead of moving the cursor to the beginning of the current line it moves the cursor to the next line
Nope. A 'file' never ever does that.
Rather you are attempting to display the file using something else.
And that something else, not the file, is doing that.
Saboor Sarfraz wrote: for the purpose of overwriting the existing txt.
Your code is absolutely correct. For what you state the purpose is.
So the problem is, as I stated above.
If you are on a windows machine you can open a Powershell console or a 'cmd' console. They are NOT the same.
Presumably you are using one of those then running your exe.
So try doing it with the other one.
If perhaps you are using an Apple Mac then you are perhaps out of luck since it always interprets the '\r' in the way you are seeing it behave.
modified 21-Nov-23 11:21am.
|
|
|
|
|
what is your preference?
I'm guessing some people prefer &foo[bar] because they may find the intent to be expressed more clearly.
I find (foo + bar) to be more succinct with less steps, and therefore clearer to me.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
You probably have to be a real C nerd to use (foo + bar) . I'm not sure that anyone I work with would grok that they're both the same thing. But maybe I work with journeymen, and not craftsmen?
For me, &foo[bar] gives me a brain cramp when I try to parse it. I'd prefer &(foo[bar]) just to make it obvious what is having it's address taken. Just to be pedantic.
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
Hail to the parenthesis. I always get comments that I use unnecessary parentheses in my code when I add them to pointer arithmetic or compound statements. My response is always along the lines of "yes I know and you were able to tell at a glance the order in which those statements were executed, and how the data was manipulated". Just put the damn () in there to make it easy for someone else to follow what you're trying to do without having to resort to the language specification. It's so much more maintainable for the next person, or yourself in 18 months when you go back to it.
Be wary of strong drink. It can make you shoot at tax collectors - and miss.
Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
|
|
|
|
|
&bar[foo]
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
I used to write things like 2[array] to wind up certain colleagues.
(Often the ones that insisted on putting the constant on the LHS of a comparison operator.)
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Peter_in_2780 wrote: the ones that insisted on putting the constant on the LHS of a comparison operator.
|
|
|
|
|
No real preference, I use whichever seems (to me) to make most sense at the time.
|
|
|
|
|
If the data type is defined as an array then use it as array in expressions.
If the data type is defined as a pointer then use it as a pointer in expressions.
honey the codewitch wrote: some people prefer &foo[bar]
Rather certain that I am one that would not want to see that. I work to write code that is maintainable and using tricks just because the exist is not something that I look on favorably.
|
|
|
|
|
That's not really a trick.
It's "get me the address of the Nth array element."
It's just another way of writing (foo + bar);
If you insist on not mixing pointer and array ops than you'd be stuck with the very syntax you don't like in order to get the address of an array element, unless there's a 3rd way to do it I'm not considering?
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
So you say it is an array. Then use it as an array when you identify the element you want to take the address of.
|
|
|
|
|
that's exactly what &foo[bar] does.
Literally it reads as take the address of the bar element of foo.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Right. So use that, rather than (foo + bar).
|
|
|
|
|
honey the codewitch wrote: It's just another way of writing (foo + bar);
yes I know.
honey the codewitch wrote: If you insist on not mixing pointer and array ops
Not sure what you mean.
If I create an array of pointers then I would use it like an array.
If I create a pointer to memory that contains sequential blocks (regardless of type) then I would use it like a pointer.
The fact that syntactically the access is the same and tradable is not a consideration.
|
|
|
|
|
jschell wrote: Not sure what you mean.
I mean this
jschell wrote: If I create an array of pointers then I would use it like an array.
If I create a pointer to memory that contains sequential blocks (regardless of type) then I would use it like a pointer
So I think somewhere we started talking past each other.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
&(foo[bar])
makes it real obvious you want the address of the barth element of array foo
Be wary of strong drink. It can make you shoot at tax collectors - and miss.
Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
|
|
|
|
|
fair enough.
Edit: To me the operation is obvious, such that using parentheses never even occurred to me. Clearly that's not the case with the other people that have commented here. Not sure what that says about my code.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
It's obvious to me too, but I've been coding C since I upgraded from assembler back in the late 80's . Those who aren't as strong in C that have looked at my code always find it easier to understand pointer manipulation if I use array notation with those redundant (). They have more difficulty with foo + bar -- the idea that foo + 1 moves the pointer by (size of what foo points) bytes instead of 1 byte always blows their mind.
Be wary of strong drink. It can make you shoot at tax collectors - and miss.
Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
|
|
|
|
|
|
|
Did you intend to put an 'Enter' between 'foo' and 'bar'?
If the comma was intended as an 'Enter', I guess that the comma between, 'bar' and '+' would have fouled it up.
|
|
|
|
|
That is wrong, yes ... I was letting it slide because I was so late in on the thread that I figured no one would notice. Is it me or has the complexion of such changed lately? Anyway.
What I meant to type was "foo,bar+". I'm no programmer just an antique calculator button presser.
|
|
|
|
|
One of the things that pisses me off in this book I bought about programming GPUs is that he presents so called "pseudocode" example for presenting his solutions. This pseudocode makes extensive use of C style pointer arithmetic, such as (foo + bar) without a word of mention; the reader is supposed to understand what it means, regardless of his programming background or preferred language.
I do have enough background to understand it when I see it. But I see pseudocode as abstracted above one specific programming language, not just as an excuse for ignoring specific requirements of one chosen language. (foo+bar) is something you'll never find in any comparable language. It doesn't belong in any abstracted pseudocode.
So does it belong in concrete code in one specific language?
Well, if you strive to establish a tribal code, to distinguish between those who are in and those outside, this may be one of your tools. Those who say 'But that is an array, FGS! - Why don't you treat it as one?' - and recoil in horror. Maybe those could have been good developers for your project.
|
|
|
|
|
In Visual Studio (latest), C++ solution.
I have a project like :
project\app
project\lib1
project\lib2
project\lib3
project\util
app <-- lib1 <-- util
<-- lib2
<-- lib3
lib1 is dependant on util and app is dependant on lib1.
util needs to be build before lib1 and lib1 before app.
In the project dependencies window, I select lib1 and then check the util dependency.
I've also looked at the project references and my lib1 is setup correctly to reference the util library.
When rebuilding lib1, I expected util to be build before.
There must be something I'm missing. (obviously)
Thanks.
CI/CD = Continuous Impediment/Continuous Despair
modified 15-Nov-23 13:45pm.
|
|
|
|