Never use pure built in types
-
Hi, instead of using types like int, float or bool, I came to the thinking of typedeffing/classing all the built in types to what they actually represent in the code. (in language, that support this feature) e.g. (c++)
typedef int Age;
typedef int Number
Age ageOfAPerson;
Number donatedMoney
...Reasons for doing so: * having full control over what type the variable really represents. scenarios: - an ID is a *number* at first and changes to have letters in it later - the System (connected with a database) was not designed for having so many users and now we're running out of IDs (getting closer to max-integer) * throughout all code it's rather easy to see which variables represent the same functional meaning. * range-changes can be made rather easy: just change the typedef * deciding that one former "just-variable" should be a class with a function or some range checking can be implemented rather easy. * avoid uncareful castings(anti-temptating): it's easy to cast a "integer" to an "unsigned integer". But it's rather hard to cast a "second" to a "user-id", even if both is an "integer" behind the scenes. On the cons-side of course, we have a massive overhead (at first) what do you think about that? Would be pleased to hear some experiences or opinions :) regards
-
Hi, instead of using types like int, float or bool, I came to the thinking of typedeffing/classing all the built in types to what they actually represent in the code. (in language, that support this feature) e.g. (c++)
typedef int Age;
typedef int Number
Age ageOfAPerson;
Number donatedMoney
...Reasons for doing so: * having full control over what type the variable really represents. scenarios: - an ID is a *number* at first and changes to have letters in it later - the System (connected with a database) was not designed for having so many users and now we're running out of IDs (getting closer to max-integer) * throughout all code it's rather easy to see which variables represent the same functional meaning. * range-changes can be made rather easy: just change the typedef * deciding that one former "just-variable" should be a class with a function or some range checking can be implemented rather easy. * avoid uncareful castings(anti-temptating): it's easy to cast a "integer" to an "unsigned integer". But it's rather hard to cast a "second" to a "user-id", even if both is an "integer" behind the scenes. On the cons-side of course, we have a massive overhead (at first) what do you think about that? Would be pleased to hear some experiences or opinions :) regards
There is no reason not to, but if you miss the
typedefit is easy to think that this type is a class rather than a basic type. I would definitely not do this in a project that would be worked on by other developers. Trying to maintain other people's code is not easy at the best of times. -
Hi, instead of using types like int, float or bool, I came to the thinking of typedeffing/classing all the built in types to what they actually represent in the code. (in language, that support this feature) e.g. (c++)
typedef int Age;
typedef int Number
Age ageOfAPerson;
Number donatedMoney
...Reasons for doing so: * having full control over what type the variable really represents. scenarios: - an ID is a *number* at first and changes to have letters in it later - the System (connected with a database) was not designed for having so many users and now we're running out of IDs (getting closer to max-integer) * throughout all code it's rather easy to see which variables represent the same functional meaning. * range-changes can be made rather easy: just change the typedef * deciding that one former "just-variable" should be a class with a function or some range checking can be implemented rather easy. * avoid uncareful castings(anti-temptating): it's easy to cast a "integer" to an "unsigned integer". But it's rather hard to cast a "second" to a "user-id", even if both is an "integer" behind the scenes. On the cons-side of course, we have a massive overhead (at first) what do you think about that? Would be pleased to hear some experiences or opinions :) regards
It's a good choice for APIs or libraries that should be given to other developers, because if you keep the interface the same you can change implementation easily should the need arise. Another good reason to use this pattern is when you have ever-shifting technologies, if you need to heavily multiplatform your project you could hide some code in the type class to arrange for different word sizes, signed/unsigned mismatches and so on. In any other case I would be reluctant to use it because it is a massive overhead over simple operations - it would be good to use in the frontier classes but not in the inner worker functions. Not only that, but debugging may rapidly become complicated, passing through constructors and methods of all sorts for simple operations. Also the size of the code grows and that too can be a performance and deploy problem. That said, I admit my vision is biased towards intensive high performance semi-embedded systems, probably for business applications and network middleware a more diligent and safe approach is better - but I wouldn't know, having no consistent experience in the field. My 2 cents.
Geek code v 3.12 GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- r++>+++ y+++* Weapons extension: ma- k++ F+2 X
-
Hi, instead of using types like int, float or bool, I came to the thinking of typedeffing/classing all the built in types to what they actually represent in the code. (in language, that support this feature) e.g. (c++)
typedef int Age;
typedef int Number
Age ageOfAPerson;
Number donatedMoney
...Reasons for doing so: * having full control over what type the variable really represents. scenarios: - an ID is a *number* at first and changes to have letters in it later - the System (connected with a database) was not designed for having so many users and now we're running out of IDs (getting closer to max-integer) * throughout all code it's rather easy to see which variables represent the same functional meaning. * range-changes can be made rather easy: just change the typedef * deciding that one former "just-variable" should be a class with a function or some range checking can be implemented rather easy. * avoid uncareful castings(anti-temptating): it's easy to cast a "integer" to an "unsigned integer". But it's rather hard to cast a "second" to a "user-id", even if both is an "integer" behind the scenes. On the cons-side of course, we have a massive overhead (at first) what do you think about that? Would be pleased to hear some experiences or opinions :) regards
Ricky Rick wrote:
* having full control over what type the variable really represents.
scenarios:
- an ID is a *number* at first and changes to have letters in it later
- the System (connected with a database) was not designed for having so many users and now we're running out of IDs (getting closer to max-integer)Nope. Certainly can use "int ID" in a million lines of code and then expect to do nothing if you change it to "string ID".
Ricky Rick wrote:
* throughout all code it's rather easy to see which variables represent the same functional meaning.
Throughout all of the code the data probably will not have the same meaning. For example as a database designer I might need to store a time stamp in a database using two columns (seconds and nanos), the business logic uses a timestamp (single value) and the UI uses a formatted text value localized for the user.
Ricky Rick wrote:
* range-changes can be made rather easy: just change the typedef
Normal sequential numerics in a database do not extend for the full binary range of something like an integer. Only positive values need apply. And I do NOT want to find out I have run out of ids in the database when the entire application fails because the id is too big. So I need a range check before that. And although a medical database might allow a birthday of Jan 1 1901, it shouldn't allow one for Jan 1 1001.
Ricky Rick wrote:
* avoid uncareful castings(anti-temptating): it's easy to cast a "integer" to an "unsigned integer". But it's rather hard to cast a "second" to a "user-id", even if both is an "integer" behind the scenes.
Been a few years since I worked in C++ but rather positive than I can do exactly that. Matter of fact it is easier to do it that way than the right way. And assignment still works so why would anyone be attempting to cast (per your example)?
Ricky Rick wrote:
On the cons-side of course, we have a massive overhead (at first)
Presumably you mean managing the types rather than anything to do with performance. The real problem here is that you are going to end up with a non-trivial number of types that exist for one instance.
Ricky Rick
-
It's a good choice for APIs or libraries that should be given to other developers, because if you keep the interface the same you can change implementation easily should the need arise. Another good reason to use this pattern is when you have ever-shifting technologies, if you need to heavily multiplatform your project you could hide some code in the type class to arrange for different word sizes, signed/unsigned mismatches and so on. In any other case I would be reluctant to use it because it is a massive overhead over simple operations - it would be good to use in the frontier classes but not in the inner worker functions. Not only that, but debugging may rapidly become complicated, passing through constructors and methods of all sorts for simple operations. Also the size of the code grows and that too can be a performance and deploy problem. That said, I admit my vision is biased towards intensive high performance semi-embedded systems, probably for business applications and network middleware a more diligent and safe approach is better - but I wouldn't know, having no consistent experience in the field. My 2 cents.
Geek code v 3.12 GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- r++>+++ y+++* Weapons extension: ma- k++ F+2 X
den2k88 wrote:
In any other case I would be reluctant to use it because it is a massive overhead over simple operations - it would be good to use in the frontier classes but not in the inner worker functions.
Not only that, but debugging may rapidly become complicated, passing through constructors and methods of all sorts for simple operations. Also the size of the code grows and that too can be a performance and deploy problem.Huh? In C++. A typedef for an int is erased in the binary. Excluding perhaps meta data it has no impact on how the code runs. Maybe you are thinking of replacing every type with a class rather than just simple type? Although I question that as well. If a class only has a single data member and that data member is an int then the most efficient compiler optimization would be to allocate storage for just the int. Thus all forms of method passing would have exactly the same cost as the int itself. As far as code growth at least in standard desktop applications the actual code size (binary) is never a problem. It is the runtime memory usage that can become a problem. If you have a C++ application that compiles down to a 1 gig binary then good for you but that certainly isn't the standard app. Conversely many smaller apps can easily using 1 gig of memory while running for data. But maybe you meant something else that I was thinking of?
-
den2k88 wrote:
In any other case I would be reluctant to use it because it is a massive overhead over simple operations - it would be good to use in the frontier classes but not in the inner worker functions.
Not only that, but debugging may rapidly become complicated, passing through constructors and methods of all sorts for simple operations. Also the size of the code grows and that too can be a performance and deploy problem.Huh? In C++. A typedef for an int is erased in the binary. Excluding perhaps meta data it has no impact on how the code runs. Maybe you are thinking of replacing every type with a class rather than just simple type? Although I question that as well. If a class only has a single data member and that data member is an int then the most efficient compiler optimization would be to allocate storage for just the int. Thus all forms of method passing would have exactly the same cost as the int itself. As far as code growth at least in standard desktop applications the actual code size (binary) is never a problem. It is the runtime memory usage that can become a problem. If you have a C++ application that compiles down to a 1 gig binary then good for you but that certainly isn't the standard app. Conversely many smaller apps can easily using 1 gig of memory while running for data. But maybe you meant something else that I was thinking of?
jschell wrote:
Maybe you are thinking of replacing every type with a class rather than just simple type?
Precisely - otherwise it has little sense if not to allow further modifications to the API, as time_t that can expand either to _time32_t or _time64_t (I have no code at hand so I may be making some naming error but i trust it is inteligible). As I was saying, this is useful if you provide APIs and want to keep the interface changes at the bare minimum, internally it has no sense.
jschell wrote:
If a class only has a single data member and that data member is an int then the most efficient compiler optimization would be to allocate storage for just the int.
Never rely on compiler optimizations unless you can force them, undertand them completely and enable/disable them at will for every single block of code inside the code itself - and then prepare to fight hard when you upgrade the compiler to a new version (yes, we're still using VS6 for that reason, and it's all out of support, like one day will be VS2008, the one which is our "future"). Using classes with only one data member in the inner working of a component is overkill at best, makes debugging much more convoluted. Classes IMHO should be used to express composite concepts where the single data members may change but leaving externally the same interface. One class per type is really messy. Of course none of the above are destructive problems, these are only the reasons for which I, with my small luggage of experience and my viewpoint, wouldn't use this design pattern unless it is prove to be the most effective way in some context. :cool:
Geek code v 3.12 GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- r++>+++ y+++* Weapons extension: ma- k++ F+2 X
-
jschell wrote:
Maybe you are thinking of replacing every type with a class rather than just simple type?
Precisely - otherwise it has little sense if not to allow further modifications to the API, as time_t that can expand either to _time32_t or _time64_t (I have no code at hand so I may be making some naming error but i trust it is inteligible). As I was saying, this is useful if you provide APIs and want to keep the interface changes at the bare minimum, internally it has no sense.
jschell wrote:
If a class only has a single data member and that data member is an int then the most efficient compiler optimization would be to allocate storage for just the int.
Never rely on compiler optimizations unless you can force them, undertand them completely and enable/disable them at will for every single block of code inside the code itself - and then prepare to fight hard when you upgrade the compiler to a new version (yes, we're still using VS6 for that reason, and it's all out of support, like one day will be VS2008, the one which is our "future"). Using classes with only one data member in the inner working of a component is overkill at best, makes debugging much more convoluted. Classes IMHO should be used to express composite concepts where the single data members may change but leaving externally the same interface. One class per type is really messy. Of course none of the above are destructive problems, these are only the reasons for which I, with my small luggage of experience and my viewpoint, wouldn't use this design pattern unless it is prove to be the most effective way in some context. :cool:
Geek code v 3.12 GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- r++>+++ y+++* Weapons extension: ma- k++ F+2 X
-
jschell wrote:
Maybe you are thinking of replacing every type with a class rather than just simple type?
Precisely - otherwise it has little sense if not to allow further modifications to the API, as time_t that can expand either to _time32_t or _time64_t (I have no code at hand so I may be making some naming error but i trust it is inteligible). As I was saying, this is useful if you provide APIs and want to keep the interface changes at the bare minimum, internally it has no sense.
jschell wrote:
If a class only has a single data member and that data member is an int then the most efficient compiler optimization would be to allocate storage for just the int.
Never rely on compiler optimizations unless you can force them, undertand them completely and enable/disable them at will for every single block of code inside the code itself - and then prepare to fight hard when you upgrade the compiler to a new version (yes, we're still using VS6 for that reason, and it's all out of support, like one day will be VS2008, the one which is our "future"). Using classes with only one data member in the inner working of a component is overkill at best, makes debugging much more convoluted. Classes IMHO should be used to express composite concepts where the single data members may change but leaving externally the same interface. One class per type is really messy. Of course none of the above are destructive problems, these are only the reasons for which I, with my small luggage of experience and my viewpoint, wouldn't use this design pattern unless it is prove to be the most effective way in some context. :cool:
Geek code v 3.12 GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- r++>+++ y+++* Weapons extension: ma- k++ F+2 X
den2k88 wrote:
Never rely on compiler optimizations unless you can force them, undertand them completely and enable/disable them at will for every single block of code inside the code itself
Perhaps but the original poster, at least as I read it, wasn't suggesting using a class for every type. That was your suggestion. And it isn't an optimization to allow the class to take the same number of bytes as the data type if in fact 1. The data type fits the word boundary 2. The compiler is not adding virtual support to every single class.
den2k88 wrote:
Using classes with only one data member in the inner working of a component is overkill at best, makes debugging much more convoluted
Again - that was your interpretation, not mine, of what the OP said. Certainly the example code posted did not suggest that.
den2k88 wrote:
wouldn't use this design pattern unless it is prove to be the most effective way in some context
Thus my first response with the specifics about that.
-
Ricky Rick wrote:
* having full control over what type the variable really represents.
scenarios:
- an ID is a *number* at first and changes to have letters in it later
- the System (connected with a database) was not designed for having so many users and now we're running out of IDs (getting closer to max-integer)Nope. Certainly can use "int ID" in a million lines of code and then expect to do nothing if you change it to "string ID".
Ricky Rick wrote:
* throughout all code it's rather easy to see which variables represent the same functional meaning.
Throughout all of the code the data probably will not have the same meaning. For example as a database designer I might need to store a time stamp in a database using two columns (seconds and nanos), the business logic uses a timestamp (single value) and the UI uses a formatted text value localized for the user.
Ricky Rick wrote:
* range-changes can be made rather easy: just change the typedef
Normal sequential numerics in a database do not extend for the full binary range of something like an integer. Only positive values need apply. And I do NOT want to find out I have run out of ids in the database when the entire application fails because the id is too big. So I need a range check before that. And although a medical database might allow a birthday of Jan 1 1901, it shouldn't allow one for Jan 1 1001.
Ricky Rick wrote:
* avoid uncareful castings(anti-temptating): it's easy to cast a "integer" to an "unsigned integer". But it's rather hard to cast a "second" to a "user-id", even if both is an "integer" behind the scenes.
Been a few years since I worked in C++ but rather positive than I can do exactly that. Matter of fact it is easier to do it that way than the right way. And assignment still works so why would anyone be attempting to cast (per your example)?
Ricky Rick wrote:
On the cons-side of course, we have a massive overhead (at first)
Presumably you mean managing the types rather than anything to do with performance. The real problem here is that you are going to end up with a non-trivial number of types that exist for one instance.
Ricky Rick
Hi,
jschell wrote:
Nope. Certainly can use "int ID" in a million lines of code and then expect to do nothing if you change it to "string ID".
that's true. But if you *have to* change it anyway. I'd say it's better this way, as you don't forget to change any places. And then you can see all the consequences at once, instead of forgetting something, that somehow manages itself to production code.
jschell wrote:
Throughout all of the code the data probably will not have the same meaning.
This sentence - taken as it is - would be a serious design problem that crashes in the long view. But with your example, it gets clearer, what you mean :)
jschell wrote:
For example as a database designer I might need to store a time stamp in a database using two columns (seconds and nanos), the business logic uses a timestamp (single value) and the UI uses a formatted text value localized for the user.
In that case I'd have three different types (as you have in the code at the moment) - or one class, that supports every representation.
jschell wrote:
Normal sequential numerics in a database do not extend for the full binary range of something like an integer.
jschell wrote:
So I need a range check before that.
I guess you mean a range check in the DB, right? I'd say, that it's rather dangerous to rely on the databases ranges and functionalities.
jschell wrote:
And I do NOT want to find out I have run out of ids in the database when the entire application fails because the id is too big
but what if you do? then you need to search the whole application for every appearance or every function (even the generic ones, that might not be named well) and change/adjust the behaviour. (You need to do in both versions, but - as above - the compiler will help you in one version, as it becomes a static error, not a runtime one)
jschell wrote:
it shouldn't allow one for Jan 1 1001.
so what to do if Jesus walks in because he's reawoken? "Sorry sir, you must be born after 1970 to get medical care" :D
jschell wrote:
Been a few years since
-
There is no reason not to, but if you miss the
typedefit is easy to think that this type is a class rather than a basic type. I would definitely not do this in a project that would be worked on by other developers. Trying to maintain other people's code is not easy at the best of times.Hi,
Quote:
There is no reason not to, but if you miss the typedef it is easy to think that this type is a class rather than a basic type.
I think, it should matter what it really is. This would basically the reason to do it. Masking the types. Only then it would be no Problem to make it a class later.