|
Hi,
I have following C++ code:
double ** data = NULL;
data = new double*[num_cols];for(int i = 0; i < num_cols; i++)
data[i] = new double[num_rows];
I have converted them into following C-language code:
double ** data = NULL;
data = (double *) malloc(num_cols * sizeof(double));
for(int i = 0; i < num_cols; i++)
data[i] = (double *) malloc(num_rows * sizeof(double));
I am getting following error message with gcc:
Quote: In function ‘main’:
gaussian.c:73:8: warning: assignment from incompatible pointer type [-Wincompatible-pointer-types]
data = (double *) malloc(num_cols * sizeof(double));
Some body please guide me.
Zulfi.
|
|
|
|
|
zak100 wrote:
double ** data = NULL;
data = (double *) malloc(num_cols * sizeof(double));
for(int i = 0; i < num_cols; i++)
data[i] = (double *) malloc(num_rows * sizeof(double));
Shouldn't it be
data = (double *) malloc(num_cols * sizeof(double*));
|
|
|
|
|
It should ... it's a standard dynamic 2D array of double in C.
The code as written is stupid for C++ it's clearly a matrix and there are a dozen better ways to do that.
You can also just flatten it in C to a linear 1D allocation if you are happy to manually do the indexing.
In vino veritas
modified 25-Apr-19 8:24am.
|
|
|
|
|
Victor Nijegorodov wrote: Shouldn't it be
data = (double *) malloc(num_cols * sizeof(double*));
I think that should be
data = (double **)malloc(num_cols * sizeof(double *));
The warning he is getting is about an incompatible pointer assignment. For myself I'd write that as
data = (double **)malloc(num_cols * sizeof *data); Since C doesn't require malloc() to be cast, you could omit the cast to (double **) when calling malloc().
|
|
|
|
|
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.
In vino veritas
|
|
|
|
|
|
Thanks. I want to do some work instead of using the cooked code. Also it would provide me two versions so I can test both and find which one is better.
Zulfi.
|
|
|
|
|
I've yet to work on an embedded project where there wasn't a C++ computer. (Even in the late 90s, I was using C++ in the embedded space. Yes, it was mostly procedural C++, but it was still C++.)
|
|
|
|
|
|
leon de boer wrote: Lets list the ones I know that don't have a c++ compiler
Whereupon only one doesn't have a C++ compiler. 
|
|
|
|
|
Hi,
I am still getting the same message:
Quote: $ 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 *));
^
$
I forget my C++ so I want to do this conversion.
Some body please guide me.
Zulfi.
|
|
|
|
|
Hi,
I have solved this problem:
The solution is:
data = (double **) malloc(num_cols * sizeof(double **));
/*???? data = new double*[num_cols];*/
for(int i = 0; i < num_cols; i++)
data[i] = (double *) malloc(num_rows * 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
data = (double **) malloc(num_cols * sizeof(double *));
for(int i = 0; i < num_cols; i++)
data[i] = (double *) malloc(num_rows * sizeof(double));
So you end up using more space this way because you have the actual array data (column x row) plus row number of pointers.
If you flat 1D the array you can just allocate
double* data1D = (double*) malloc(num_rows * num_cols * sizeof(double));
It is smaller but you can't just reference it via
data[i][j] you have to reference if via a formula
data1D[j*num_cols + i]
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.
In vino veritas
modified 25-Apr-19 14:22pm.
|
|
|
|
|
Hi my friends,
t t
Thanks for your help.
Its really a good idea to have faster application and for last 2 assignments, just because of this fact that the grader has to wait a lot to see my results, I am not a good scorer.
However at this point, I dont know the trick to do it. So I am interested in a C language working solution and I am close to it. Once I am done I have to focus on performance.
Thanks for your good intentions. But I would really do it. I have one more part left after this one.
Zulfi.
|
|
|
|
|
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).
You can either download cfront version 3.0.3 from May 1994 (as a gzip'd tar archive), or as an alternative if you prefer, you can browse the source tree (in a new browser window).
|
|
|
|
|
ChrisFromWales wrote: 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)
|
|
|
|
|
Hi!
I am having difficulty processing the following problem.
modified 25-Apr-19 3:55am.
|
|
|
|
|
In what part exactly (1, 2a, 2b, 2c, 3) do you have "difficulty"?
What are the types of "difficulty"?
|
|
|
|
|
Quote: 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.
|
|
|
|
|
Hi,
I want to convert the following C++ code into C-language.
For the following code,
<pre> ifstream inFile;
inFile >> num_rows;
file_buffer.resize(num_rows);
I wrote:
FILE* inFile;
inFile = fopen(argv[1], "r");
fgets(strNum_rows, 20, inFile);
num_rows = atoi(strNum_rows);
But I can't understand how to declare file_buffer and how to convert :
vector<double> file_buffer;
file_buffer.resize(num_rows);
in 'C' language?
Somebody please guide me.
Zulfi.
|
|
|
|
|
Is file_buffer a vector? If so, you could have something like:
int *file_buffer = malloc(num_rows * sizeof(int)); 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
|
|
|
|
|
Hi,
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:
22
1111.909
12.3456
0.000345
and so on.
First line is a integer and tells the count of data in the file.
Okay if I have somehing like:
send_buffer = new double[num_rows];
Then its equivalent C-code would be:
send_buffer = (double *)malloc(num_rows * sizeof(double);
Please let me know.
Zulfi.
|
|
|
|
|
zak100 wrote:
Please let me know.
Looks okay from my vantage point. Have you tried it?
"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
|
|
|
|
|
There is one slight difference which may or may not be important in some situations.
C++ new usually zeros the allocated memory
In C you can use calloc for that it has the format
void *calloc(size_t nitems, size_t size)
So you can actually remove the multiply because you have the number of items and the size of each item
send_buffer = (double *)calloc(num_rows, sizeof(double));
Now it allocates and zeros the allocation.
In vino veritas
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
