![]() |
|
#1
|
|||
|
|||
I/O array problem with data filesCurrently I need to read data from a file, such like this
Measurements for Lansing, Michigan during April, 2000 63 32 0.00 54 43 0.10 59 39 0.00 46 24 0.00 52 20 0.00 54 30 0.00 The first line is obviously disregarded, since all we want are the numbers. limitations are simply use arrays, no vectors. I had something like this for now, though I'm not sure if it cuts the first line out or not...I'm also cutting main() off the post, I know it works, its the I/O I don't get. CPP / C++ / C Code:
declaring the struct is CPP / C++ / C Code:
Currently the output yeilds 0 0 (some reference address) ...and thats it I know i'm somewhere close, but I'm drawing a blank. I set Num = 1 in hopes of skipping the first set in the data, which would be the string of words How do i fix the array so it yields the correct I/O? Your help is greatly appreciated |
|||
|
#2
|
||||
|
||||
Re: I/O array problem with data filesTo skip the first line of the data file, use getline().
Then, always display what was read immediately after reading it to make sure the read worked properly. __________________
The 3 Laws of the Procrastination Society: 1) Never do today that which can be put off until tomorrow 2) Tomorrow never comes |
|
#3
|
|||
|
|||
Re: I/O array problem with data filesQuote:
Mr_Peepers, you'll note that WaltP is absolutely fascinated with printf/cout... If you use the C++ streaming library functions properly, you don't need couts littering your code. All you have to do is check that the ios::good bit is set after a read. That means that "the read worked properly." Here's a simple example: CPP / C++ / C Code:
Output: Code:
Note how the contents of foo are organized. The read tries to convert to an integer in the loop. Since the first three conversions are successful, the output is as expected and "x" is "happy" each time through. When the input stream encounters data that can not be converted to "x," we get a fail bit set. Here's the code that does the work that you want to do, without a bunch of silly "displays" of the read activities...always is a fairly hefty requirement, huh?! Of course, I didn't use an array, but I didn't use a vector, either. I used dynamic memory allocation and a series of linked data structures in a very abbreviated "linked list" fashion. CPP / C++ / C Code:
Output: Code:
Code:
...you may want to add iomanip to your include directives. Also, if you add lines to your data file (I copied the same data and pasted it several times in the file to "grow" it significantly): Code:
...the code should continue to work. Code:
...of course, once you run out of memory, the code will fail and the "leak" will not be cleaned up. But that's another topic... :davis: |
|
#4
|
|||
|
|||
Re: I/O array problem with data filesThanks Davis, That really seemed to help fix reading and outputting.
I should have mentioned, with that data, some things need to be calculated, namely average x, y, and z values, and simple searches to find the smallest and largest numbers. So with this allocation method, average for x would go something like this? CPP / C++ / C Code:
having of course declared total and count, with average being total / count. |
|
#5
|
||||
|
||||
Re: I/O array problem with data filesQuote:
__________________
The 3 Laws of the Procrastination Society: 1) Never do today that which can be put off until tomorrow 2) Tomorrow never comes |
|
#6
|
|||
|
|||
Re: I/O array problem with data filesQuote:
Spoken like a true, self-proclaimed expert with over 30 years of programming experience...that is, accept no responsibility for what you post. Redirect away from yourself. Completely discount that you said "always" because Dave has "never not" mentioned using printf/cout. Why not celebrate an option to using printf/cout?! Do you feel that their presence in your own code really help you more than hurt you? How many times have you needlessly typed printf or cout followed by some string constants and data members? That time couldn't be better utilized? How many hours over the supposedly 30+ years might you have saved by employing alternatives that also "live well" in "release" code? How much time did you spend taking OUT the spew to console statements? How much time did you waste putting them in the WRONG places? Hey, you're the expert. Who are the rest of us simpletons to be suggesting that you are not the commander of your own destiny and that we mere mortals should grovel at every opportunity to partake in the blessings of coding prophecy offered by the truly Outstanding Member (graded solely on quantity, not quality) found in the glorious visionage encountered here as WaltP? How long ago was it that you were some kind of prince entering some buildings and your fairy tale wonderland of C++ was a dark place where, with a little C knowledge, you could somehow "see" your way around a bit? Remember how that started? Gather 'round children, and I'll tell you a story. ...you somehow promote yourself to "adult" status and everyone else to "children." Who was the "young prince?" By your story, he was well-versed in the art of C...that seems to imply that you meant yourself. Maybe you are the product of an environment where many, many novices come, but you are somehow an "expert" because of your modestly advanced skill compared to them? It sounds to me as if you're believing your own fairy tales... :davis: |
|
#7
|
|||||
|
|||||
Re: I/O array problem with data filesQuote:
No worries. Quote:
Luckily, the organization of data in the linked list works well for those kinds of algorithms...however, you're likely to find that "searches" and particularly sorting algorithms oftenly tend toward "array" data. Quote:
...if we're going to traverse the list, we'd probably want to try to figure out a way to do all of our calculations in a single pass through the list. Are we averaging x, y and z or are we averaging all xes, all ys and all zs? Quote:
Why use count? Didn't we already tell the user how many "chunks" we read from the input? Don't we already know how many x data points there are? Quote:
You are essentially correct. We must also assign p_tmp to the head node, which is (very unprotectedly) p_node. In my code, I didn't mention it, but the code should obviously be seen as "protecting" p_node as the "head" value for as long as we intend to access the list...elsewise, we are probably "in the weeds" and/or "leaking memory." By searching, do you mean for the lowest/highest between all of x, y and z (I used x, y, f) or the lowest/highest of the xes, the lowest/highest of the ys, etc.? I might create a separate data structure, but plain old data (POD) is fine, too. Something else to consider is that these things are sometimes cummulative. That is, what you learn about using arrays in the "previous block" will be used in the "next block" thereby building upon code you've already written. For example, let's say that you then need to sort the "arrays" of data using a simple sorting algorithm whose arguments require integer arrays. Converting from a list to an array is not very difficult, but it may require some activities that you haven't yet been exposed to. I don't know. Just note that if you don't reasonably well understand the code that I put forth, it may come back to haunt you if you build your solution based on it. I offer it here because it was expedient for me to do so. It was easier for me than creating a static array and then resizing the array (if needed) and then writing functions to do work on arrays. Here you can (should) see that you can easily pass a pointer to the head pointer into a function that would calculate the average(s) for you very easily. Another place that you can calculate the averages is AS you read the data. Why spend another cycle traversing the list when you have the data points at the point that you read them? :davis: |
|
#8
|
||||
|
||||
Re: I/O array problem with data filesdavis, what is wrong with you?
So you disagree with Walt's suggestion, post your reasons why and be done with it! Your personal attack is uncalled for. |
|
#9
|
|||
|
|||
Re: I/O array problem with data filesQuote:
I'm tired of listening to wannabe "advice" from WaltP. www.oopweb.com Here is a direct quotation: printf() debugging printf debugging is our term for a debugging technique we encounter all too often. It consists of ad hoc addition of lots of printf (C) or cerr or cout (C++) statements to track the control flow and data values in the execution of a piece of code. This technique has strong disadvantages: It is very ad hoc. Code is temporarily added, to be removed as soon as the bug at hand is solved; for the next bug, similar code is added etc. There are better ways of adding debugging information, as you shall see shortly. It clobbers the normal output of your program, and slows it down considerably. Often, it does not help. Output to stdout is buffered, and the contents of the buffer are usually lost in case of a crash. Thus, you'll most likely miss the most important information, causing you to start looking in all the wrong places [2] . If you consider using printf debugging, please check out the use of assertions (see the section called Assertions: defensive programming) and of a debugger (see the section called The debugger); these are often much more effective and time-saving. There are some circumstances where printf debugging is appropriate. If you want to use it, here are some tips: Produce your output on stderr. Unlike stdout, stderr is unbuffered. Thus using stderr, you're much less likely to miss the last information before a crash. Do not use printf directly, but define a macro around it, so that you can switch your debugging code on and off easily. Use a debugging level, to manage the amount of debugging information. Not enough? www.oopweb.com 3.1 Don't Use printf()/cout As Your Main Debugging Devices As seen above, the confirmation process often involves checking the values of variables at different points in your code and different points in time. In the past, you probably did this by adding temporary printf or cout statements to your C or C++ source file. This is very inconvenient: You have to recompile your program after you add them, and you may have to add a large number of them, say if you want to check the value of some variable at several different places in your program. Then after recompiling and running the program, you realize that there are even more places at which you need printf/cout statements, so you have to recompile again! Then after you fix that bug, you have to remove all these printf/couts, and start adding them to track down the next bug. Not only is this annoying, but it is distracting, making it difficult to concentrate, i.e. you will be apt to lose your train of thought on finding the bug. A debugging tool allows you to print out values of variables much more conveniently: You don't have to recompile, and you can ask the debugging tool to monitor any variables you like, automatically. Again, the ``convenience factor'' here is quite important. The less time you spend on recompiles, etc., the more time-and mental energy-you have available to concentrate on hunting down the bug. Even more important, the debugging tool will tell you where in your program a disastrous error (e.g. a ``segmentation fault'') occurs. In addition, it can tell you where the function generating the seg fault was called from. This is extremely useful. There are times when printf/couts are useful in conjunction with a debugging tool, but you'll be doing yourself a favor if you use the debugging tool, not printf/couts, as your main debugging device. I think that YOU should decide whether or not you want to build a forum around his very limited perspective and experiences or assault those who promote alternatives that are truly beneficial to aspiring programmers. What is wrong with saying that WaltP is fascinated with printf/cout as a debugging tool? He regularly recommends it and, if ever, rarely recommends alternatives. Why should we all jump to his perceived "aid" when he claims some kind of "attack" made by me for denouncing his "choice" of debugging tools? This is YOUR forum. You don't need me or anything that I bring to the table in order to have WaltP remind newbies that they should read the guidelines before posting. Let me know if you want me to further contribute to this forum. Nah, **** that. Delete me. I'm tired of this bullshit where a total ****ing wannabe named WaltP is the "hero" and I'm the villian because I call his shit out for it. **** you. :davis: |
Recent GIDBlog
Install Adobe Flash - Without Administrator Rights by LocalTech
| Thread Tools | Search this Thread |
| Rate This Thread | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Memory leak when nothing is happening... How can I even debug this ? | Algar | MS Visual C++ / MFC Forum | 10 | 19-Nov-2007 07:17 |
| [Include] Doubly-linked List | dsmith | C Programming Language | 6 | 14-Apr-2006 13:12 |
| Need help deleting the last element in the array | headphone69 | C++ Forum | 2 | 15-Mar-2006 19:31 |
| Strange C++ code memory leakage problem | gaoanyu | C++ Forum | 7 | 04-Nov-2005 08:09 |
| template comiling problems - need expert debugger! | crq | C++ Forum | 1 | 01-Feb-2005 21:26 |
Network Sites: GIDNetwork · GIDWebHosts · GIDSearch · Learning Journal by J de Silva, The