Difference between revisions of "Talk:V4 Design: epicsTypes"
(my comments) |
|||
| Line 3: | Line 3: | ||
1) As we are all already aware I feel that the unsigned types in C are useful. When problems occur it's because users convert between signed and unsigned types without proper range checking. Since data access has this range checking built in (after considerable effort on mine and Ralph's part I will add) then conversion problems are possibly no longer an issue. | 1) As we are all already aware I feel that the unsigned types in C are useful. When problems occur it's because users convert between signed and unsigned types without proper range checking. Since data access has this range checking built in (after considerable effort on mine and Ralph's part I will add) then conversion problems are possibly no longer an issue. | ||
2) You have created interface classes for buffers, arrays, enumerated, strings etc. All of these interfaces are already in data access. Was there a good justification to create new ones? In any case, it seems that we should the goal of using the same interfaces for each type of commonly used data. | 2) You have created interface classes for buffers, arrays, enumerated, strings etc. All of these interfaces are already in data access. Was there a good justification to create new ones? In any case, it seems that we should have the goal of using the same interfaces for each type of commonly used data. | ||
3) These interfaces seem to require contiguous storage of random sized blocks of characters. Doesn’t this preclude use of fixed length buffer based (free list based) memory allocation, and therefore almost guarantee fragmentation of memory. | 3) These interfaces seem to require contiguous storage of random sized blocks of characters. Doesn’t this preclude use of fixed length buffer based (free list based) memory allocation, and therefore almost guarantee fragmentation of memory. | ||
Revision as of 21:46, 14 June 2005
Here are my comments
1) As we are all already aware I feel that the unsigned types in C are useful. When problems occur it's because users convert between signed and unsigned types without proper range checking. Since data access has this range checking built in (after considerable effort on mine and Ralph's part I will add) then conversion problems are possibly no longer an issue.
2) You have created interface classes for buffers, arrays, enumerated, strings etc. All of these interfaces are already in data access. Was there a good justification to create new ones? In any case, it seems that we should have the goal of using the same interfaces for each type of commonly used data.
3) These interfaces seem to require contiguous storage of random sized blocks of characters. Doesn’t this preclude use of fixed length buffer based (free list based) memory allocation, and therefore almost guarantee fragmentation of memory.
