Looking at this, and your other post prompts the obvious question: why are you trying to convert working code from C++ to C? Since all modern compilers support C++ it would be better to stick with what works.
That is a rash statement in the embedded space there is rarely a C++ compiler.
Then the second kicker few in the industry would accept C++ code because of the notorious problems with memory on a confined system.
Definitely not a problem on the PC market but you can't make that sweeping statement.
$ mpicc gaussian.c
gaussian.c: In function ‘main’:
gaussian.c:73:8: warning: assignment from incompatible pointer type [-Wincompatible-pointer-types]
data = (double *) malloc(num_cols * sizeof(double *));
That isn't correct but you are getting away with it because the pointer size is standard double* and double** are the same size.
If you are handing this in for a uni assignment they will ping you for it.
Lets put the comments over it so you get it
/* First you malloc a set of pointers to a double ... not a pointer to a pointer to a double *//* data is a pointer to a pointer of double .. so you need to allocate pointers to doubles */
data = (double **) malloc(num_cols * sizeof(double *));
/* Then for each pointer of double you malloc a 1D array of doubles to that pointer */for(int i = 0; i < num_cols; i++)
data[i] = (double *) malloc(num_rows * sizeof(double));
/* see how the thing inside the sizeof is always one asterix less than what malloc returns */
So you end up using more space this way because you have the actual array data (column x row) plus row number of pointers.
So there is a trade off being made between memory size and ease of indexing.
The flat 1D array is usually faster if you know you pointer arithmetic but more prone to beginner error.
It's clearly a M x N matrix and most commercial programmers would flatten it to a 1D array because you are likely going to do matrix arithmetic and there are tricks you can use with a flat 1D array and memmove.
I guess this won't be the reply you expect or want, but …
In the early 1980s, when the C++ language was first being developed at Bell Labs, the first (and for a long time the only) "compiler" for C++ was a tool called cfront. It converted C++ source code into valid C source code (for which there were already a gazillion compilers, of course) The cfront compiler was actually maintained for over a decade, ending with the release of version 3.0.3 (the last official version of which I am aware) in May 1994.
Your current project (as I understand it), is to convert some existing C++ source code (that allegedly works correctly) into C source code (presumably also with the works correctly option). I suspect the ultimate target is a platform for which no C++ compiler is available.
If the original C++ source that you are porting does NOT make extensive use of some of the more modern additions to the language, then you might consider running cfront on the original C++ source. I am not suggesting that it should replace your manual porting efforts to date, but to act merely as your assistant in a purely advisory capacity.
The last version of cfront was released around the time that the C++ language added templates (which are implemented) and exceptions (which are not implemented). If you are interested, you can download cfront or browse the source code courtesy of the Software Preservation Group (which is part of the Computer History Museum in Mountain View, California (Silicon Valley).
The last version of cfront was released around the time that the C++ language added templates
cfront version 3.0.3 from May 1994 [...]
This can't be right. I remember programming templates around ~1988 when I was at university, working with PHIGS[^] . cfront did require multiple passes to correctly translate some templates, and was restricted more than the language specification would allow in theory. But for the most part it could handle templates back then.
Since there was no C++ standard in existence, it's hard to say at what time, exactly, cfront supported templates fully though: it led a catch-up races with the C++ designers who kept introducing new features.
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)
The purpose of this Task is to let you express your problem-solving skills, programing skills, as well as to reveal your style of coding.
The question is clear, it is to test your skills, not the skills of some strangers on the internet. Show what you have tried, explain what you are having a problem with, and people will try to help you. But no one is going to do your work for you.
Is file_buffer a vector? If so, you could have something like:
int *file_buffer = malloc(num_rows * sizeof(int)); // assumes you are reading ints from file
Note: your fgets() call could be the source of an issue. It'll read 19 characters, or until an EOF or newline character is encountered. If it reads too many, then any subsequent fgets() calls will start at the wrong spot in the file stream.
"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
Thanks for your response. God bless you.
Yes, file_buffer is a vector. Thanks for your comments about fegts(). I am reading from a file which has following contents:
and so on.
First line is a integer and tells the count of data in the file.
Okay if I have somehing like: