Pointer to Pointer: Conversion from- C++ to C-language
-
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*));
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 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.
-
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*));
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 callingmalloc(). -
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
/* 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. 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
-
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. 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
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.
-
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
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++.)
-
Hi, I have following C++ code:
double ** data = NULL;
data = new double*[num_cols];//Is the asterisk required or is an error
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.
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). -
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++.)
Lets list the ones I know that don't have a c++ compiler unless you consider paying big bucks for 3rd party IAR or GreenHills. MicroChip (PIC 16F,24F) on the XC32 range has C++ which is a relicensed ARM and why it has C++ MPLAB- XC Compilers | Microchip Technology[^] NEC (78K0, 78K4, and V850 range) C only, RX family has C++ without IDE again via GCC C Compiler Package for V850 Family | Renesas Electronics[^] ST Electronics .. STM8 C only, STM32 C or 3rd party crippled C++ (free versions with up to 64 Kbytes of code are available) STM8 Software Development Tools - STMicroelectronics[^] STM32 MCU MPU Software Development Tools - STMicroelectronics[^] Zilog only C all ranges http://ixapps.ixys.com/DataSheet/PB0097.pdf[^] Fujitsu/Cypress only C on most of the range C++ on some 32 bit cpu SOFTUNE C compiler (F2MC-16 Family, F2MC-8FX Family) SOFTUNE C/C++ compiler (FR Family) https://www.cypress.com/documentation/software-and-drivers/softune-ide-language-tools https://www.cypress.com/products/psoc-designer The only ones I know that usually have C++ are TI, Intel and Hitachi. That is a huge hunk of the industry which is why we won't employee anyone who can't write in C.
In vino veritas
-
Lets list the ones I know that don't have a c++ compiler unless you consider paying big bucks for 3rd party IAR or GreenHills. MicroChip (PIC 16F,24F) on the XC32 range has C++ which is a relicensed ARM and why it has C++ MPLAB- XC Compilers | Microchip Technology[^] NEC (78K0, 78K4, and V850 range) C only, RX family has C++ without IDE again via GCC C Compiler Package for V850 Family | Renesas Electronics[^] ST Electronics .. STM8 C only, STM32 C or 3rd party crippled C++ (free versions with up to 64 Kbytes of code are available) STM8 Software Development Tools - STMicroelectronics[^] STM32 MCU MPU Software Development Tools - STMicroelectronics[^] Zilog only C all ranges http://ixapps.ixys.com/DataSheet/PB0097.pdf[^] Fujitsu/Cypress only C on most of the range C++ on some 32 bit cpu SOFTUNE C compiler (F2MC-16 Family, F2MC-8FX Family) SOFTUNE C/C++ compiler (FR Family) https://www.cypress.com/documentation/software-and-drivers/softune-ide-language-tools https://www.cypress.com/products/psoc-designer The only ones I know that usually have C++ are TI, Intel and Hitachi. That is a huge hunk of the industry which is why we won't employee anyone who can't write in C.
In vino veritas
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. :)
-
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)