Very simple binary file compressor in C - C / C++ / MFC Discussion Boards

this.........+5

In Windows, you'll see "CClass" a lot (capital C as a prefix)... in Linux and a lot of standard libraries, you won't see any indication at all, for them enclosing things properly within namespaces is more important.

If you intend to follow the object-oriented paradigm, then prefixing a variable name with 'o' for 'object' makes about as much sense as prefixing it with 'v' for 'variable'. You might still consider this sensible, to visibly discern them from type names, constants, and functions though. YMMV.

As for 'c' (class) prefix, it's often used to distinguish type names from e. g. structs, integral types, enums, etc.. I used (and still use) this a lot, but the longer I think about it the less sense it appears to make: modern editors provide all the information you need by just hovering over the name in question, much more information in fact than you could ever sensibly pack into a prefix. The prefix therefore only carries valuable information if you tend to print out code and prefer analyzing code on paper. Again, not my preference, but YMMV.

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

Ok, prefixes for generic objects (like 'o' for objects, or 'v' for variables) are bad notations, but prefixes for variables type make the code more readable, like a story e.g. 'str' for strings, 'n' for numbers, 'arr' for arrays, and so on ... and they are not so hard to type ...

You're referring to the incorrect use of hungarian notation. Let me point you to this great article about why it is wrong and how to use it correctly: http://www.joelonsoftware.com/articles/Wrong.html[^]
Smile | :)

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

Interesting article ... so, the time has changed ?... Smile | :)

modified 2-Jul-15 7:39am.

I don't use Hungarian these days but oClass seems to have been the more common style (especially in VB). In C++ it was also common not to use Hungarian with objects but just with simple types, integers, floats, etc.

In the .NET world Hungarian is discouraged but there is still a widely-used concession to Hungarian with the names of UI controls. btnCustomer, etc., although really we should prefer customerButton.

Kevin

Hello as subject says i am trying to make some simple binary file compressor (for now). I started with basics.
This code opens file in binary mode reads byte by byte and input bytes writes to output "compressed" file. If byte == 0x00 counts number of 0x00's and writes 0x00 and number of 0x00's.

C++

#include<stdio.h>
#include<stdlib.h>

int main()
{
	int i, duzina, stanje=0, brojac=0;
	unsigned char chr;
	FILE* ulaz = fopen("../testapp/testapp", "rb");
	FILE* izlaz = fopen("../testapp/testapp.zip", "wb");
	
	if(ulaz == NULL)
	{
		printf("Problem with file!\n");
		exit(1);
	}
	if(izlaz == NULL)
	{
		printf("Problem with output file!\n");
		exit(1);
	}

	fseek(ulaz, 0, SEEK_END);
	duzina = ftell(ulaz);
	fseek(ulaz, 0, SEEK_SET);

	for(i=0; i<duzina; i++)
	{
		chr = fgetc(ulaz);
		if(chr == 0x00) 
		{
			if(stanje == 0)
			{
				stanje=1;
				brojac=1;
			}
			else
				brojac++;
		}
		else
		{
			if(stanje == 0)
				fputc(chr, izlaz);
			else
			{
				fputc(0x00, izlaz);
				fwrite(&brojac, sizeof(int),1,izlaz);
				fputc(chr, izlaz);
				printf("%d ", brojac);
				stanje=0;
				brojac=0;
			}
		}
	}

	fclose(izlaz);
	fclose(ulaz);
}

To "decompress" file i use this code which as input have "compressed" file and read byte by byte if byte == 0x00 reads integer and write N times 0x00 (N value = readed integer)

C++

#include<stdio.h>
#include<stdlib.h>

int main()
{
	int i,j, duzina, brojac=0;
	unsigned char chr;

	FILE* ulaz = fopen("../testapp/testapp.zip", "rb");
	FILE* izlaz = fopen("../testapp/testapp1", "wb");
	
	if(ulaz == NULL)
	{
		printf("Problem with file!\n");
		exit(1);
	}
	if(izlaz == NULL)
	{
		printf("Problem with output file!\n");
		exit(1);
	}

	fseek(ulaz, 0, SEEK_END);
	duzina = ftell(ulaz);
	fseek(ulaz, 0, SEEK_SET);

	for(i=0; i<duzina; i++)
	{
		chr = fgetc(ulaz);
		if(chr == 0x00)
		{
			fread(&brojac, sizeof(int), 1, ulaz);
			printf("%d ", brojac);
			for(j=0; j<brojac; j++)
				fputc(0x00, izlaz);
			i+=4;	
		}
		else
			fputc(chr, izlaz);
	}

	fclose(izlaz);
	fclose(ulaz);
}

So my problem is that when "decompressing" is finshed some bytes are missing (program works correct).

Byte comparing:

[stone@hero testapp]$ diff testapp1.hex testapp.hex 
443,444c443,444
< 0001c00 0001                                   
< 0001c01
---
> 0001c00 0001 0000 0000 0000 0000 0000 0000 0000
> 0001c10
[stone@hero testapp]$

I'm on: Linux hero 3.18.15-1-MANJARO #1 SMP PREEMPT Sun Jun 14 10:09:07 UTC 2015 x86_64 GNU/Linux if it matters.

Source code for test app:

C++

#include<stdio.h>
#include<time.h>

main()
{
	srand(time(NULL));
	printf("\nHello, stone... ");
	printf("Your random number is: %d\n\n", rand() % 100 + 1);
}

What can be a problem with missing bytes?

The compressor has a problem with a possibly pending 0-sequence at the end of the file, because your program outputs the 0-sequences only on changes, that is when meets a non-zero character.
You have to check for a pending 0-sequence immediately after execution of the for loop:

C

if(stanje != 0)
{
  fputc(0x00, izlaz);
  fwrite(&brojac, sizeof(int),1,izlaz);
}

Is anyone aware of a library to create a standalone executable with a Visual Studio 2013 native unit test DLL?

(I need to do some dynamic analysis on part of my code, but the tool needs to instrument the loading executable. I can't use my main executable since it runs on an embedded system with very specific and locked down hardware.)

Aren't the libs included for the unit test library?

If so, you should be able to just build your test code into a stand alone, statically-linked executable.

Tried that, but the result doesn't do anything. The VC++ Native Unit Tests have a test runner and that's the secret sauce, so to speak. (It enumerates all the exports from the test dll and runs them. I could figure this out, but was hoping someone else already has.)

Hi
Can the "CStatic" CWnd object be used (in the create of course) with the CTEXT resource definition statement

Thanks

Yes, I suppose. See, for instance, "Static Controls" at MSDN[^] and "Using the CStatic control" at CodeProject[^].

Thanks with the SS_NOTIFY
I can process the ::onCtlColor use the CWnd::GetDlgitem (for proper control) and
SetbkColor
SetTextColor
and SetWindowText of the controls before the Dialog which is the parent to the control is displayed.

Thanks

I have been using Windows Event Log in order to catch events with a C++ Project on VS2008 for a couple of years.

However, recently(means a couple of days), i cannot catch them on Windows 8.1. I have no problem with Windows 7 or Vista.

Subscribe function "EvtSubscribeFn" returns success but callback does not work.

Could it be a "permissions" issue? Could the event log be full?

"One man's wage rise is another man's price increase." - Harold Wilson

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles

modified 24-Jun-15 10:23am.

Hi David, it is not a permission issue. Code is working both windows vista and windows 7. Also current code had been worked since one years on windows 8.1. This is not sense. We have checked latest windows updates, but we have nothing. Frown | :(

modified 24-Jun-15 11:53am.

Hi all,
this is my first question in this forum. I'd like to begin it by saying hello to everyone.

I am writing a Win32 application that uses multiple sensors, such as the Kinect V2, and a couple of other sensors that complement Kinect's capabilities. These other sensors are interfaced with the PC via the Serial Port. Both the Kinect and the other sensors produce data samples periodically at similar time intervals.

The challenge I face is how to best pull all of these data samples together into my application. What I mean by that is how to best structure my program in order to get the data in effitiently. I think it's a Producer-Consumer type of a problem.

The idea I have is to read the data samples from each of the external sources in a separate Reader Thread. Each of these theads would fire an event when a new sample has been received. The Main Thread would pick up these events using the WaitForMultipleObjects() function, as described [here]. This should provide enough synchronization.

The Main Thread, I call it a Producer Thread, would copy all of the arriving data into a custom frame class. This frame would then be pushed into a FIFO queue. A Consumer Thread would pop and process these custom frames from the FIFO at full speed.

Yes, I realise that this application is resource-hungry. The Consumer Thread pops frames at a lower rate than the frames are pushed onto the FIFO. The PC I develop it on should be able to handle it with with 16GB of RAM and the latest i7 CPU. Real-time operation is not required. Also, the program should complete before RAM fills up.

I wonder if my approach and more importantly the thought process I have is correct? I wonder if there would be a better approach for this type of an application? I don't seem to see a better way.

Thanks,
MW

Quote:
The Consumer Thread pops frames at a lower rate than the frames are pushed onto the FIFO

Why?

Quote:
Also, the program should complete before RAM fills up

It all depends on what the program should do with collected data, you know that if (as you stated) the consumer is slower than the producer then the memory will be eventually filled up.

The reason why I say that the consumer pops frames at a lower rate than the producer pushes them into the FIFO is that the consumer must process each frame. This operation is time consuming. In fact, the producer pushes approximately 3 frames into the FIFO during the time it takes the consumer to process 1 popped frame.

I've written a couple of test programs to test some of the most time consuming tasks as well as how many frames would actually be needed to complete the task. This is why I made the above statements.

That's not the main concern though. I am more curious about the general approach to designing the application. I've got the individual bits and pieces working. Next, these need to be put together, integrated. I wonder about how to best achieve it?

It looks a fairly good design to me.
If you cannot speed up the frame processing, then you might consider dropping some of them (if it is a viable option).

If he produces three for every one he processes, I'd imagine he's going to have to figure out a way how to process them faster or drops will have to occur.

Unless memory is enough to buffer all the needed data.

Assuming it's not a process that goes on forever. Usually with sensors, it's an ongoing process, they're always producing data, so if you're not using it all you have to do some sort of smart data reduction (i.e. drop if it makes sense, decimate if it makes sense).