处理文件C ++中的信息 [英] Manipulate information in file C++

问题描述

我正在为嵌入式设备使用C ++开发应用程序.此应用程序必须对设备中出现的差异问题或警报进行某种历史记录.
警报用这样的线表示:
2500 1 Alarm1(第一个数字是ID，第二个数字表示警报已启动)

每次发生警报时，都会在文本文件中写入一行，而在发生警报时，文件中的前一行将被删除.

例如:
在文件中:
2500 1警报1
2450 1警报3

现在，警报2500在设备上关闭，因此删除了"2500 1 alarm1"行.

我计划在C ++中通过打开文件，进行内部研究等来实现这一目的.

我想知道有人(不是我的)有一个主意，做到这一点的方法，可以提高性能并且不占用设备中的大量内存.

在此先谢谢您.

Hi,

I am working on an application in C++ for a embedded device. This application have to make a kind of historical of the differents problems or alarms that appear in the device.
An alarm is illustrated by a line like that :
2500 1 alarm1 (the 1st number is an ID, the second indicates that the alarm is up )

At each time an alarm is up, a line is written in a text file and when the alarm is down the previous line is deleted in the file.

For example :
In the file :
2500 1 alarm1
2450 1 alarm3

Now the alarm 2500 goes down on the device so the line "2500 1 alarm1" is deleted.

I plan to make this in C++ with opening a file, research inside and so on.

I would like to know if someone have an idea, a method to do that (other than mine) which increase performance and don''t use lot of memory in the device.

Thanks in advance.

推荐答案

您是否有固定数量的可能的警报?

如果是这样，我建议将警报数据存储在固定长度的记录文件中.

每个警报说4个字节.将高位用于警报状态(打开/关闭)，将低31位用于时间戳/序列号.

然后，当警报更改状态时，您不必搜索文件，只需转到文件中的相应偏移量，然后在该偏移量处写入一个新的4字节值即可指示该警报的当前状态和当前时间戳记/序列号.

这将为您提供与您建议的文件结构相同的信息，它的优点是是固定大小的文件和可预测的执行时间(这对于嵌入式系统都是重要的).

根据可能的警报数量以及可用的非易失性存储量，可能值得为每个警报分别存储开/关的单独时间戳记-这样您将拥有更完整的历史记录. >


更好的主意(如果唯一警报的数量很少且非易失性存储已足够):

在固定长度的记录文件中，存储:上次打开时间，上次关闭时间，警报触发的次数以及警报打开的累积时间.

由此，您可以确定哪些警报最常发出以及平均持续多长时间.为您提供比文件更多的历史数据.




另一方面，如果唯一警报的数量大于可用的非易失性存储的数量，则:

只需在非易失性存储中维护一个循环缓冲区，并在发生每个开/关事件时将其写入缓冲区即可，当您填充可用缓冲区/文件时，只需从头再开始并覆盖最早的条目即可.

这可以使您更了解系统中发生的情况.例如，如果警报2450持续不断地打开和关闭，而什么也没有发生，则这将是比您最初设想的解决方案更好的解决方案.无论如何，最后N个事件可能是您历史上最重要的事件.

您还可以为每个警报存储一个历史位，以显示该警报是否曾经发生过.


无论如何，请花点时间考虑一下将如何​​准确地使用此历史数据，这将帮助您确定真正应存储的数据.

Do you have a fixed number of possible alarms?

If so, I''d suggest storing alarm data in a fixed length record file.

Say 4 bytes per alarm. Use the high order bit for the alarm state (on/off) and the lower 31 bits for a timestamp / sequence number.

Then when an alarm changes state, you don''t have to search your file, you just go to the appropriate offset in the file and write a new 4 byte value at that offset to indicate the current state of that alarm and the current timestamp / sequence number.

This will give you the same information as you have in the file structure you propose, it has the advantage of being a fixed size file and a predictable execution time (both important for an embedded system).

Depending on the number of possible alarms and how much non-volatile storage you have available, it might be worthwhile to just store separate timestamps for on/off for each alarm -- then you''ll have a more complete history.



Even better idea (if the number of unique alarms is small and non-volatile storage is adequate):

In your fixed length record file, store: last time on, last time off, number of times the alarm has triggered, and the cummulative time the alarm has been on.

From that you can determine what alarms are going off most and for how long on average. Gives you way more historical data then your file.




If, on the other hand, the number of unique alarms is large compared to tha available non-volatile storage:

Just maintain a circular buffer in non-volatile storage and write every on/off event into the buffer as it occurs, when you fill up the available buffer/file just start at the beginning again and overwrite the oldest entries.

This may give you a more useful picture of what is happenign in your system. For example if alarm 2450 is toggling on and off constantly, while nothing else is happening, this will be a much better solution than the one you originally envisioned. In any case, the last N events are probably most important in your history.

You might also store a single historical bit per alarm to show if that alarm has ever gone off.


In any case, spend a bit of time thinking about how exactly this historical data is going to be used and it will help you decide what data you really should store.

这不应该除非文件变大，否则要占用大量内存...在这种情况下，请勿将整个文件加载到内存中，不要打开文件并根据需要一次插入一行.在这种情况下，需要进行权衡，将文件加载到内存中会消耗RAM(嵌入式设备通常不会占用很多内存)，但是从非易失性内存中读取会比较慢，因此，请确定您的优先级是.

为了提高性能，请在与您的主线程不同的线程中搜索文件(不要等待它，只是让它告诉您何时完成，或者如果主线程不需要知道，它就可以了"会更好).

This shouldn''t take a lot of memory unless the file gets big... in which case, don''t load the entire file into memory, open the file and pull in one line at a time as needed. In this case, there''s a tradeoff, loading a file into memory consumes RAM (which embedded devices don''t typically have a lot of) but reading from non-volatile memory is slower, so make a decision as to what your priority is.

To increase performance, do the searching through the file in a different thread than your main (don''t wait for it, just let it tell you when its done or if the main thread doesn''t need to know, it''ll be better).

这篇关于处理文件C ++中的信息的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！