- Now i want to talk about Strong typed safety systems - 2 Updates
- uninitialized build-in types - 1 Update
| Paavo Helde <myfirstname@osa.pri.ee>: Jan 01 08:41AM -0600 > (Not as defined in that C++ fragment anyway. Maybe (I don't know C++) > you could wrap a class around 'float', do all the work needed, and use > that to create derived versions which inherit all the usual operations.) This can be done via C++ templates. Anyway, another important aspect here is that something like 'length' typically makes sense only in a broader context (length of what?). Length of a road and length of a molecule chain are not the same and probably it would not be a good idea to add them up even if the measured physical quantity is basically the same. If length is considered as a property of something else, then typically it will appear as a private member in some other class. The class will provide needed operations which make sense for the objects of the class (e.g. a road or a molecule) and which may or may not involve changing the length property. This means that the length property is already encapsulated pretty well inside the class and there might not be much use of having a specific type for that, a simple float would do as well. In this sense the ability to define different float-like types might not be so important after all. Things were different in the original Ada, which did not support OOP. There an ability to define different float-like classes might have been useful indeed, because of the lack of better encapsulation means. From the viewpoint of C++ encapsulating a simple float would often mean creating a too low-level abstraction. Cheers Paavo |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 01 09:02PM On Fri, 2016-01-01, Paavo Helde wrote: > of a road and length of a molecule chain are not the same and probably it > would not be a good idea to add them up even if the measured physical > quantity is basically the same. True. > of having a specific type for that, a simple float would do as well. In > this sense the ability to define different float-like types might not be > so important after all. However, if I wrote a program for manipulating roads, or one for manipulating molecules, I might write a length class /for use in that context/. I've seen that strategy work well so often: to create types for things which at first look like just plain integers or floats. But like you noted above, it's not something you want to do once, for all possible applications; it has to be application-specific. > useful indeed, because of the lack of better encapsulation means. From > the viewpoint of C++ encapsulating a simple float would often mean > creating a too low-level abstraction. To me there's no such thing. If I identify "the length of a molecule" as a type, I can make a C++ type out of it, and benefit from it. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 01 01:40PM > this issue alone was enough to show me that I'm expecting too much > out of a single language in a world of increasingly complex > software. I'm not sure software necessarily grows more complex ... but it doesn't matter; there have always been good reasons to use multiple languages. Where I come from -- Unix -- we had shell scripts as first-class citizens from the very beginning. Then Perl etc showed up. Plus all the domain-specific languages. Personally, I don't see a need for more than C++ in the "static strong typing" category. But if you want something for rapid prototyping (I suspect that was what your "iterative style" meant), check out Python or Ruby. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment