Just finished testing the dynamic allocation of memory for the array of structures contain widget configuration options. Althought the code is correct, initialization errors occur. My suspicion now is that the const and enum variable types contained within the structure typef are not compatible with malloc operations. (I've quickly scouted through K&R and found no reference to the allocation of these types, maybe these are in the compiler specifications.)
The solution that I opted to follow then, is to statically create 'empty' entries in the option structure array and to assign values as necessary during run time. My initial tests show that the 'empty' entries cause no operational problems to my code for the creation of the gnocl::drawArea widget. At first glance it may appear that such a static allocation of memory is wasteful, but then if this was true it would be an argument against the static allocation of memory for any of the gnocl widgets which of course, it isn't.
The positive side is, however, that the run-time creation of new options for the gnocl::drawingArea provides the basis for a megawidget development context within Gnocl itself -neat.
So, on reflection, whilst I'm staying with the code I originally had I now know why this is, understand more of the underpinning memory issues surrounding the creation of statically built arrays, constants and enumerators and, of course how to dynamically create and resize structure arrays.
The solution that I opted to follow then, is to statically create 'empty' entries in the option structure array and to assign values as necessary during run time. My initial tests show that the 'empty' entries cause no operational problems to my code for the creation of the gnocl::drawArea widget. At first glance it may appear that such a static allocation of memory is wasteful, but then if this was true it would be an argument against the static allocation of memory for any of the gnocl widgets which of course, it isn't.
The positive side is, however, that the run-time creation of new options for the gnocl::drawingArea provides the basis for a megawidget development context within Gnocl itself -neat.
So, on reflection, whilst I'm staying with the code I originally had I now know why this is, understand more of the underpinning memory issues surrounding the creation of statically built arrays, constants and enumerators and, of course how to dynamically create and resize structure arrays.
Comments