Re: hard typdef - proposal - I know it's not in the standard
On 28 January 2013 06:18, Alec Teal wrote: the very nature of just putting the word hard before a typedef is something I find appealing I've already explained why that's not likely to be acceptable, because identifiers are allowed before 'typedef' and it would be ambiguous. You need a different syntax. That is why I'd want both, but at least in my mind n3515 would be nearer to if I really wanted it I could use classes than the hard-typedef. I've already said N3515 is not about classes. It can be used to define strong typedefs for classes, which is needed because most types in real C++ programs are class types, but it also works for scalar types.
Re: hard typdef - proposal - I know it's not in the standard
On 28/01/13 10:41, Jonathan Wakely wrote: On 28 January 2013 06:18, Alec Teal wrote: the very nature of just putting the word hard before a typedef is something I find appealing I've already explained why that's not likely to be acceptable, because identifiers are allowed before 'typedef' and it would be ambiguous. You need a different syntax. That is why I'd want both, but at least in my mind n3515 would be nearer to if I really wanted it I could use classes than the hard-typedef. I've already said N3515 is not about classes. You keep missing the point of what I mean by like classes I mean in terms of achieving the result, PLEASE think it though. It can be used to define strong typedefs for classes, which is needed because most types in real C++ programs are class types, but it also works for scalar types.
Re: hard typdef - proposal - I know it's not in the standard
On 1/28/2013 6:48 AM, Alec Teal wrote: On 28/01/13 10:41, Jonathan Wakely wrote: On 28 January 2013 06:18, Alec Teal wrote: the very nature of just putting the word hard before a typedef is something I find appealing I've already explained why that's not likely to be acceptable, because identifiers are allowed before 'typedef' and it would be ambiguous. You need a different syntax. That is why I'd want both, but at least in my mind n3515 would be nearer to if I really wanted it I could use classes than the hard-typedef. I've already said N3515 is not about classes. You keep missing the point of what I mean by like classes I mean in terms of achieving the result, PLEASE think it though. I have read this thread, and I see ZERO chance of this proposal being accepted for inclusion into gcc at the current time. Feel free to create your own version of gcc that has this feature (that after all is what freedom in software is about) and promote it elsewhere but it is really a waste of time to debate it further on this list. The burden for non-standard language extensions in gcc is very high. The current proposal is ambiguous and flawed, and in any case does not begin to meet this high standard. I think this thread should be allowed to RIP at this stage.
Re: hard typdef - proposal - I know it's not in the standard
To some up again (I've kept the quotes so it can be seen what's already been talked about) I propose something that is almost identical to a typedef as it exists now, all behaviour of this hard typedef is almost identical except: 1) the hard type is never implicitly 'cast' to anything else of the same actual type (a BookId may never become an int implicitly) 2) the hard type may be used in overloading (building on the 'may not be implicitly cast' a call to f(someBook) will never resolve to f(int), only to f(BookId) Because it is to behave like a typedef the c-style cast isn't actually a cast at all, it is a way of telling the compiler you intend to use the hard-typed variable as you have written. There is no actual cast because it's a kind of typedef the underlying data is by definition the same. If the compiler didn't complain when you tried to use a BookId as an int or visa-versa that would defeat the purpose. the c-style cast of int x = (int) some_book; or whatever is not a cast (I'm saying the same thing again, sorry) it's just telling the compiler Yes, I mean to write this Alec On 24/01/13 19:45, Lawrence Crowl wrote: On 1/24/13, Alec Teal a.t...@warwick.ac.uk wrote: Did anyone read? I can sometimes take several days to get to reading an email, particularly when travelling. I hope you see how it is nothing like a strong typedef (as its called). To me it seems like the strong one is too similar to a class to be worth adding, especially after reading that paper, it seems like it would allow new-php-user like behaviour of EVERYTHING IS A CLASS but with types, we've all been there. While this could stop some errors ... I've discussed this already. If you want your feature in mainline gcc, you will need to convince the maintainers that the feature is valuable. Likewise, if you want your extension in the C++ language, you will need to convince the C++ standards committee. Both tasks have essentially the same structure. Clearly explain the programming problem you have. You need to explain why the current language is not really working. Using examples of real failures is helpful. You should show that the problem is significant to a significant number of programmers. (They may not know they have a problem, so you will need to explain it.) The for your feature, IIUC, is that you are not proposing something that keeps track of physical units, so many examples of bad operations would not apply to your feature. You need to make the case that there is some aspect of programming that the feature captures in code. You need to examine a few alternative solutions. Presumably, your proposal is one of them. Finally, you should discuss any interaction between your feature and existing features. In your case, you appear to be changing the meaning of C casts. What about C++ casts? Do you need a new one, or do you change the meaning of existing ones? This list of tasks may seem like a lot of work, but it will likely be significantly less than the implementation work. More importantly, it will help ensure that the feature has a market of users. Alec I am eager to see what you guys think, this is a 'feature' I've wanted for a long time and you all seem approachable rather than the distant compiler gods I expected. I can also see why 'strong typedefs' were not done, it tries to do too much with the type system and becomes very object like Alec Teal a.t...@warwick.ac.uk wrote: On 23/01/13 23:07, Lawrence Crowl wrote: On 1/23/13, Jonathan Wakely jwakely@gmail.com wrote: On 23 January 2013 09:15, Alec Teal wrote: I was fearful of using the word attribute for fear of getting it wrong? What is this part of the compiler called I think attributes are handled in the front end and transformed into something in the compiler's tree data structures. FWIW I've usually seen this feature referred to as strong typedefs. That brings to mind the strong using extension G++ had for namespaces, which (prior to getting standardised as inline namespaces) used __attribute__((strong)) so that attribute already exists in the C++ front end: http://gcc.gnu.org/onlinedocs/gcc/Namespace-Association.html Note that there is a proposal before the C++ standard committee on just this topic. Consider its semantics when implementing. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3515.pdf After reading that it doesn't seem like the same thing, they are talking about - essentially - creating classes to handle types with no runtime overhead, they want to be certain the optimizer got rid of it or save the optimizer a job. I'm not saying that's bad I just think it is separate. Typdefs are supposed to be an alias, yes in light of that the title of type definition seems a little misleading when put with that paper, but none the less a typedef is an alias. While reading the book The design and evolution of C++ (I am not saying this to throw around look, from the 'founder' of C++'s mouth!, I
Re: hard typdef - proposal - I know it's not in the standard
On Sun, Jan 27, 2013 at 6:19 PM, Alec Teal a.t...@warwick.ac.uk wrote: To some up again (I've kept the quotes so it can be seen what's already been talked about) I propose something that is almost identical to a typedef as it exists now, all behaviour of this hard typedef is almost identical except: 1) the hard type is never implicitly 'cast' to anything else of the same actual type (a BookId may never become an int implicitly) So that's like a private opaque alias in n3515. 2) the hard type may be used in overloading (building on the 'may not be implicitly cast' a call to f(someBook) will never resolve to f(int), only to f(BookId) Also the same as a private opaque aias in n3515. Because it is to behave like a typedef the c-style cast isn't actually a cast at all, it is a way of telling the compiler you intend to use the hard-typed variable as you have written. There is no actual cast because it's a kind of typedef the underlying data is by definition the same. If the compiler didn't complain when you tried to use a BookId as an int or visa-versa that would defeat the purpose. the c-style cast of int x = (int) some_book; or whatever is not a cast (I'm saying the same thing again, sorry) it's just telling the compiler Yes, I mean to write this That's a cast -- an explicit request in code for a type conversion. The fact that it's a pure compile-time operation and a no-op at runtime has no bearing on whether it is a cast, just as we can static_cast beween enumerators and integers today with no run-time cost. One of the purposes of casts is to tell the compiler Yes, I mean to write this, and it's common for casts to be purely compile-time operations. n3515 is also explicit that the permitted conversions have no run-time cost. Is there anything that you propose that a private opaque alias from n3515 does not provide? -- James
Re: hard typdef - proposal - I know it's not in the standard
On 28/01/13 02:38, James Dennett wrote:
That's a cast -- an explicit request in code for a type conversion.
The fact that it's a pure compile-time operation and a no-op at
runtime has no bearing on whether it is a cast, just as we can
static_cast beween enumerators and integers today with no run-time
cost. One of the purposes of casts is to tell the compiler Yes, I
mean to write this, and it's common for casts to be purely
compile-time operations. n3515 is also explicit that the permitted
conversions have no run-time cost. Is there anything that you propose
that a private opaque alias from n3515 does not provide? -- James
No, it's the other way around, n3515 provides stuff this doesn't - but
by design. It's not an either or.
(I've deleted like 3 different responses now).
It really isn't an either or, I am not saying this over n3515, I
would want both (I think, that's the point of this discussion).
I would prefer a hard-typedef for things like vector components (if I
didn't decide to use a struct, where the components would be given by
name), or ids, the compiler would stop me mixing types unless I meant
to, the very nature of just putting the word hard before a typedef is
something I find appealing as the function of it is to stop me from
doing silly things and to allow me to be reminded of what something is
from it's definition (a BookId for example), it'll also allow
overloading, I find the idea of a function called getName returning
the name of a book, author or whatever very appealing when passed a
BookId, AuthorId or a whateverId.
The very nature of a typedef is an alias, if I alias something from an
int I have grown to expect to be able to add it and do other integer
things with it, this is true of the hard-typedef to, I don't want to (I
may have said this) be able to define a type system so rigid that an IDE
auto-complete could create a grand unified theory. I don't want to stop
and think when using this on a float type can I divide this, not all
operations form a group (this is why I mentioned groups earlier), real
numbers do not form a group under multiplication (and hence division by
requirement of an inverse) because of 0 being a real number. Despite
this we may still divide by zero. I do not want to have to use n3515 and
be faced with this temptation. Having said that I have yet to use it so
maybe it wouldn't be that big.
That is why I'd want both, but at least in my mind n3515 would be nearer
to if I really wanted it I could use classes than the hard-typedef.
I may have said this too, but I'll say it again. Typedefs are something
that go on a line and define a useful alias. I doubt this is disputed,
sticking the word hard before it and gaining this is something I find
very appealing, having to write:
using opaque-type = access-specifier underlying-class {
desired-member-trampoline-signature = default;
friend desired-nonmember-trampoline-signature = default;
};
(or something of that form)
while useful, is less appealing. I don't really care that I /could/ add
BookIds, I think the hard-typedef is more in line with how typedefs are
actually used, but abstract algebra has taught me that you cannot
rigidly define operations on things that'll always be defined or even
useful, I also see operators more as a notation than operations, I think
this is what tempts people and luls them into needlessly defining
operators, adding two BookIds doesn't have to mean the operation of
addition on integers. I am going off topic, suffice to say perhaps I
will think of a use for additive notation for a binary operation on
BookIds, it need not be the same as addition on integers. If I did
define such a thing though doesn't this blur the line between class and
a hard-or-strong typedef?
Alec
Re: hard typdef - proposal - I know it's not in the standard
I've thought of how to phrase it. Yes n3515 does allow more than the 'hard-typedef', they do (in part) do the same job, but the context where you'd use one and not the other is very clear, I like clean notations, I think that's a mathematician thing, as I am sure you know (or have touched on) the mathematicians go to great lengths to save themselves ink. I can think of many examples of this, think of ways of writing integrals, especially ones along a parameterized curve in a vector field, it just became an integral with the symbol of the curve below it. 1 doesn't mean 1 it means the multiplicative identity element of a set, 0 but for additive notation. You get the idea (I don't want to bore you or go beyond) but think of the hard-typedef as the integral symbol with a circle though it, showing over a closed curve, it's just a short hand in a case where you are integrating over a closed curve, the hard-typedef is a short hand in the case you want to 'inherit' operations from the base class. I hope this explains it better! Alec On 28/01/13 02:38, James Dennett wrote: n3515 is also explicit that the permitted conversions have no run-time cost. Is there anything that you propose that a private opaque alias from n3515 does not provide? -- James
Re: hard typdef - proposal - I know it's not in the standard
Did anyone read? I hope you see how it is nothing like a strong typedef (as its called). To me it seems like the strong one is too similar to a class to be worth adding, especially after reading that paper, it seems like it would allow new-php-user like behaviour of EVERYTHING IS A CLASS but with types, we've all been there. While this could stop some errors ... I've discussed this already. Alec I am eager to see what you guys think, this is a 'feature' I've wanted for a long time and you all seem approachable rather than the distant compiler gods I expected. I can also see why 'strong typedefs' were not done, it tries to do too much with the type system and becomes very object like Alec Teal a.t...@warwick.ac.uk wrote: On 23/01/13 23:07, Lawrence Crowl wrote: On 1/23/13, Jonathan Wakely jwakely@gmail.com wrote: On 23 January 2013 09:15, Alec Teal wrote: I was fearful of using the word attribute for fear of getting it wrong? What is this part of the compiler called I think attributes are handled in the front end and transformed into something in the compiler's tree data structures. FWIW I've usually seen this feature referred to as strong typedefs. That brings to mind the strong using extension G++ had for namespaces, which (prior to getting standardised as inline namespaces) used __attribute__((strong)) so that attribute already exists in the C++ front end: http://gcc.gnu.org/onlinedocs/gcc/Namespace-Association.html Note that there is a proposal before the C++ standard committee on just this topic. Consider its semantics when implementing. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3515.pdf After reading that it doesn't seem like the same thing, they are talking about - essentially - creating classes to handle types with no runtime overhead, they want to be certain the optimizer got rid of it or save the optimizer a job. I'm not saying that's bad I just think it is separate. Typdefs are supposed to be an alias, yes in light of that the title of type definition seems a little misleading when put with that paper, but none the less a typedef is an alias. While reading the book The design and evolution of C++ (I am not saying this to throw around look, from the 'founder' of C++'s mouth!, I read it so I could learn why things are the way they are and errors which would have happened if things had of happened differently, wow that's a weird sentence, I mean failed attempts) I did enjoy reading about the strict typing that C++ introduced and that was to catch errors. The paper has a point, you would never try to multiply two game scores, so why have compiler tell you if you do? You'd surely mean it! What if you want to computer the geometric mean (or something, go with me) ultimately it's still an int! Why not go a step further and give the compiler the concept of a group (algebraic structure see [1]) this could stop divisions by zeros! Why not say you can no longer divide an integer by another integer? MOST of the time the result wont be an integer, with their example of cartesian(3) to spherical coordinates you shouldn't have to rigidly define such stuff that it throws an error when you do something as silly as mix them up and again, when they define x there is no one-size-fits-all definition for how x operates with other types. If you were to seriously try you'd just get so much spam, the only reason the idea doesn't totally implode is because you can cast back to the base, so if all your definitions - which are more like conditions - don't allow something, you just side-step it, this is an own goal the point was you would never sidestep. There is a line between what I am proposing and what they are, I cannot define exactly where it is, by their own admitance they cant: /This issue has been one of the consistent stumbling blocks in the design of an opaque typedef// //facility. In particular, we have come to realize that there is no one consistent approach to the// //return type issue such that it will meet all expectations under all circumstances//:/ If they could this would be far more important than a proposed C++ feature and would have been 'discovered' during the Abstract Algebra boom during the times of Gauss. Back on topic! I always thought of a hard-typedef as an extension of this. I don't want it treated like a class, I don't want this to be valid: hard typdef int BookId; int x = 5; BookId my_book = x; //should fail BookId alternate = (BookId) x; //fine - no runtime overhead because it's just an alias, no compiling overhead really either. This (in the world of classes) is interesting because if anything int is the parent of BookId, but I shouldn't need a constructor or a reinterpret_cast (however it'd be applicable) because I had written (BookId) before the x, and that's probably not an accident the compiler should
Re: hard typdef - proposal - I know it's not in the standard
On 1/24/2013 9:10 AM, Alec Teal wrote: Alec I am eager to see what you guys think, this is a 'feature' I've wanted for a long time and you all seem approachable rather than the distant compiler gods I expected. I certainly see the point of this proposal, indeed introducing this kind of strong typing makes sense to anyone familiar with Ada, where it is a standard feature of the language, and the way that Ada is always used. However, I wonder whether it is simply too big a feature for gcc to add on its own to C++. For sure you would have to have language lawyers look very carefully at this proposal to see if it is indeed sound with respect to the formal rules of the language. Often features that make good sense when expressed informally turn out to be problematic when they are fully defined in the appropriate language of the standard. I can also see why 'strong typedefs' were not done, it tries to do too much with the type system and becomes very object like I don't see what this has to do with objects!
Re: hard typdef - proposal - I know it's not in the standard
On 24/01/13 14:22, Robert Dewar wrote:
On 1/24/2013 9:10 AM, Alec Teal wrote:
Alec I am eager to see what you guys think, this is a 'feature' I've
wanted for a long time and you all seem approachable rather than the
distant compiler gods I expected.
I certainly see the point of this proposal, indeed introducing
this kind of strong typing makes sense to anyone familiar with
Ada, where it is a standard feature of the language, and the
way that Ada is always used.
I came up with this because of my job, I create stuff for Android
devices this means I have to use Java - I HATE JAVA! It's crap for SO
MANY reasons.
Anyway the stuff I do must be high performance, it's for games (not all
can be done native and it's preferable to use Java where you can because
of the massive wadge of different devices). Lack of structs became a big
problem and OpenGL has a lot of flags, using hard-typing would mean the
IDE could only hint at ones that made sense (rather than the general
int), same with using SQLite on Android, I don't want to create a Java
class because I know what I'm doing and that's overkill, the class will
actually exist! Just to wrap an int, this would allow me to create an
int but not be allowed to mis-use it, it'd also let me overload stuff
based on the type, even when it's an int right down.
It isn't really a feature in the sense of a new syntax, it's just the
word hard and the result is this
no-runtime-overhead-but-otherwise-the-same case where you can overload too!
However, I wonder whether it is simply too big a feature for
gcc to add on its own to C++. For sure you would have to have
language lawyers look very carefully at this proposal to see
if it is indeed sound with respect to the formal rules of the
language. Often features that make good sense when expressed
informally turn out to be problematic when they are fully
defined in the appropriate language of the standard.
I agree sadly, even if hard was a pre-processor macro that 'became'
hard when GCC was compiling (using a simple #ifdef) and it became a
normal typedef, all that lovely overloading and purpose would be gone.
I can also see why 'strong typedefs' were not done, it tries to do
too much with the type system and becomes very object like
I don't see what this has to do with objects!
That's because this has nothing to do with objects, in the paper that
was linked (called strong typing) it implemented new types rather like
objects, using score = public int { //definitions }; for example,
extending an int effectively, this is what I mean by a PHP-noob going
class-mad.
Re: hard typdef - proposal - I know it's not in the standard
On 24 January 2013 16:21, Alec Teal wrote:
That's because this has nothing to do with objects, in the paper that was
linked (called strong typing) it implemented new types rather like
objects, using score = public int { //definitions }; for example,
extending an int effectively, this is what I mean by a PHP-noob going
class-mad.
I think you've misunderstood the proposal. The syntax you refer to
defines a strong typedef for int and defines an overloaded operator
for it, it doesn't go class-mad and has nothing to do with PHP or
everything is a class. It would add no overhead over an int either,
if implemented sensibly, it would only have compile-time properties
and not alter runtime behaviour. Reel in the hyperbole.
Re: hard typdef - proposal - I know it's not in the standard
On 24/01/13 18:45, Jonathan Wakely wrote:
On 24 January 2013 16:21, Alec Teal wrote:
That's because this has nothing to do with objects, in the paper that was
linked (called strong typing) it implemented new types rather like
objects, using score = public int { //definitions }; for example,
extending an int effectively, this is what I mean by a PHP-noob going
class-mad.
I think you've misunderstood the proposal. The syntax you refer to
defines a strong typedef for int and defines an overloaded operator
for it, it doesn't go class-mad and has nothing to do with PHP or
everything is a class. It would add no overhead over an int either,
if implemented sensibly, it would only have compile-time properties
and not alter runtime behaviour. Reel in the hyperbole.
What? No.
In PHP when people learn about objects they tend to make EVERYTHING into
an object and never use inheritance. I'm playing on that! In the paper
they define X Y and Z components, EVERYTHING is a defined type of sorts.
When it comes to runtime overhead, yes there is none in both cases, but
it's about look, the one in the document looks like a class, it makes
sense to be but it's a bulky syntax for something as small as a typedef.
I'm not saying not the above, just that it invites overuse - I do have
an extension to the idea that employs more of the abstract algebra
that'd look a lot like what that paper is on about, anyway, I propose
something simple, not different, small and not able to be over-used
without real stupidity taking over (probably)
See what I mean? Again not saying 1 or the other, just that with this,
then the strong ones.
Re: hard typdef - proposal - I know it's not in the standard
On 1/24/13, Alec Teal a.t...@warwick.ac.uk wrote: Did anyone read? I can sometimes take several days to get to reading an email, particularly when travelling. I hope you see how it is nothing like a strong typedef (as its called). To me it seems like the strong one is too similar to a class to be worth adding, especially after reading that paper, it seems like it would allow new-php-user like behaviour of EVERYTHING IS A CLASS but with types, we've all been there. While this could stop some errors ... I've discussed this already. If you want your feature in mainline gcc, you will need to convince the maintainers that the feature is valuable. Likewise, if you want your extension in the C++ language, you will need to convince the C++ standards committee. Both tasks have essentially the same structure. Clearly explain the programming problem you have. You need to explain why the current language is not really working. Using examples of real failures is helpful. You should show that the problem is significant to a significant number of programmers. (They may not know they have a problem, so you will need to explain it.) The for your feature, IIUC, is that you are not proposing something that keeps track of physical units, so many examples of bad operations would not apply to your feature. You need to make the case that there is some aspect of programming that the feature captures in code. You need to examine a few alternative solutions. Presumably, your proposal is one of them. Finally, you should discuss any interaction between your feature and existing features. In your case, you appear to be changing the meaning of C casts. What about C++ casts? Do you need a new one, or do you change the meaning of existing ones? This list of tasks may seem like a lot of work, but it will likely be significantly less than the implementation work. More importantly, it will help ensure that the feature has a market of users. Alec I am eager to see what you guys think, this is a 'feature' I've wanted for a long time and you all seem approachable rather than the distant compiler gods I expected. I can also see why 'strong typedefs' were not done, it tries to do too much with the type system and becomes very object like Alec Teal a.t...@warwick.ac.uk wrote: On 23/01/13 23:07, Lawrence Crowl wrote: On 1/23/13, Jonathan Wakely jwakely@gmail.com wrote: On 23 January 2013 09:15, Alec Teal wrote: I was fearful of using the word attribute for fear of getting it wrong? What is this part of the compiler called I think attributes are handled in the front end and transformed into something in the compiler's tree data structures. FWIW I've usually seen this feature referred to as strong typedefs. That brings to mind the strong using extension G++ had for namespaces, which (prior to getting standardised as inline namespaces) used __attribute__((strong)) so that attribute already exists in the C++ front end: http://gcc.gnu.org/onlinedocs/gcc/Namespace-Association.html Note that there is a proposal before the C++ standard committee on just this topic. Consider its semantics when implementing. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3515.pdf After reading that it doesn't seem like the same thing, they are talking about - essentially - creating classes to handle types with no runtime overhead, they want to be certain the optimizer got rid of it or save the optimizer a job. I'm not saying that's bad I just think it is separate. Typdefs are supposed to be an alias, yes in light of that the title of type definition seems a little misleading when put with that paper, but none the less a typedef is an alias. While reading the book The design and evolution of C++ (I am not saying this to throw around look, from the 'founder' of C++'s mouth!, I read it so I could learn why things are the way they are and errors which would have happened if things had of happened differently, wow that's a weird sentence, I mean failed attempts) I did enjoy reading about the strict typing that C++ introduced and that was to catch errors. The paper has a point, you would never try to multiply two game scores, so why have compiler tell you if you do? You'd surely mean it! What if you want to computer the geometric mean (or something, go with me) ultimately it's still an int! Why not go a step further and give the compiler the concept of a group (algebraic structure see [1]) this could stop divisions by zeros! Why not say you can no longer divide an integer by another integer? MOST of the time the result wont be an integer, with their example of cartesian(3) to spherical coordinates you shouldn't have to rigidly define such stuff that it throws an error when you do something as silly as mix them up and again, when they define x there is no one-size-fits-all definition for how x operates with other types. If you were to seriously try you'd just get so much spam, the only reason the idea
Re: hard typdef - proposal - I know it's not in the standard
On Thu, Jan 24, 2013 at 2:45 PM, Lawrence Crowl cr...@googlers.com wrote: On 1/24/13, Alec Teal a.t...@warwick.ac.uk wrote: ... If you want your feature in mainline gcc, you will need to convince the maintainers that the feature is valuable. Likewise, if you want your extension in the C++ language, you will need to convince the C++ standards committee. Both tasks have essentially the same structure. How does one engage the C and C++ committees? Please forgive my ignorance. Jeff
Re: hard typdef - proposal - I know it's not in the standard
FYI: Lawrence Crowl says If you want your feature in mainline gcc not I. Also I want to be the one to do this feature, implementation. On 24/01/13 19:49, Jeffrey Walton wrote: On Thu, Jan 24, 2013 at 2:45 PM, Lawrence Crowl cr...@googlers.com wrote: On 1/24/13, Alec Teal a.t...@warwick.ac.uk wrote: ... If you want your feature in mainline gcc, you will need to convince the maintainers that the feature is valuable. Likewise, if you want your extension in the C++ language, you will need to convince the C++ standards committee. Both tasks have essentially the same structure. How does one engage the C and C++ committees? Please forgive my ignorance. Jeff
Re: hard typdef - proposal - I know it's not in the standard
On Thu, 24 Jan 2013, Jeffrey Walton wrote: How does one engage the C and C++ committees? http://isocpp.org/forums -- Marc Glisse
Re: hard typdef - proposal - I know it's not in the standard
On 23 January 2013 06:53, Alec Teal wrote: Why not: make an optional keyword, hard, have a meaning if before typedef, I suggest tokenising hard as a normal token (however it is processed now why change it? I am not sure on GCCs exact grammar for c languages) but if AND ONLY if it is before a typdef treat it differently, as far as I know a typedef can only occur at the beginning of a statement so this should mean it doesn't break anything. Like other specifiers such as const and static, typedef doesn't have to come first, i.e. this is legal, if unconventional: typedef int hard; hard typedef Int; I think Basile's suggestion to implement it as an attribute is a better idea, it makes it clearer it's something non-standard and compiler-specific, and the grammar already contains attributes in declarations. Problems: 1)Not all compilers would be happy with this. Fix: I'm sure gcc must define something for the preprocessor that'll exist if and only if GCC is the compiler? Nope, Compilers that claim GCC compatibility also define __GNUC__, and as has been discussed before on this list, if we added __REALLY_GCC__ then other compilers would just add that too.
Re: hard typdef - proposal - I know it's not in the standard
On 23/01/13 08:55, Jonathan Wakely wrote: On 23 January 2013 06:53, Alec Teal wrote: Why not: make an optional keyword, hard, have a meaning if before typedef, I suggest tokenising hard as a normal token (however it is processed now why change it? I am not sure on GCCs exact grammar for c languages) but if AND ONLY if it is before a typdef treat it differently, as far as I know a typedef can only occur at the beginning of a statement so this should mean it doesn't break anything. Like other specifiers such as const and static, typedef doesn't have to come first, i.e. this is legal, if unconventional: typedef int hard; hard typedef Int; I think Basile's suggestion to implement it as an attribute is a better idea, it makes it clearer it's something non-standard and compiler-specific, and the grammar already contains attributes in declarations. Problems: 1)Not all compilers would be happy with this. Fix: I'm sure gcc must define something for the preprocessor that'll exist if and only if GCC is the compiler? Nope, Compilers that claim GCC compatibility also define __GNUC__, and as has been discussed before on this list, if we added __REALLY_GCC__ then other compilers would just add that too. I was fearful of using the word attribute for fear of getting it wrong? What is this part of the compiler called (I'm doing this with gcc@gcc.gnu.org cced in for any future mes ;-))? Are there any decent-sized documents on it? I'd love a good read! Alec
Re: hard typdef - proposal - I know it's not in the standard
On 23 January 2013 09:15, Alec Teal wrote: I was fearful of using the word attribute for fear of getting it wrong? What is this part of the compiler called I think attributes are handled in the front end and transformed into something in the compiler's tree data structures. FWIW I've usually seen this feature referred to as strong typedefs. That brings to mind the strong using extension G++ had for namespaces, which (prior to getting standardised as inline namespaces) used __attribute__((strong)) so that attribute already exists in the C++ front end: http://gcc.gnu.org/onlinedocs/gcc/Namespace-Association.html
Re: hard typdef - proposal - I know it's not in the standard
On 1/23/13, Jonathan Wakely jwakely@gmail.com wrote: On 23 January 2013 09:15, Alec Teal wrote: I was fearful of using the word attribute for fear of getting it wrong? What is this part of the compiler called I think attributes are handled in the front end and transformed into something in the compiler's tree data structures. FWIW I've usually seen this feature referred to as strong typedefs. That brings to mind the strong using extension G++ had for namespaces, which (prior to getting standardised as inline namespaces) used __attribute__((strong)) so that attribute already exists in the C++ front end: http://gcc.gnu.org/onlinedocs/gcc/Namespace-Association.html Note that there is a proposal before the C++ standard committee on just this topic. Consider its semantics when implementing. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3515.pdf -- Lawrence Crowl
Re: hard typdef - proposal - I know it's not in the standard
On 23/01/13 23:07, Lawrence Crowl wrote: On 1/23/13, Jonathan Wakely jwakely@gmail.com wrote: On 23 January 2013 09:15, Alec Teal wrote: I was fearful of using the word attribute for fear of getting it wrong? What is this part of the compiler called I think attributes are handled in the front end and transformed into something in the compiler's tree data structures. FWIW I've usually seen this feature referred to as strong typedefs. That brings to mind the strong using extension G++ had for namespaces, which (prior to getting standardised as inline namespaces) used __attribute__((strong)) so that attribute already exists in the C++ front end: http://gcc.gnu.org/onlinedocs/gcc/Namespace-Association.html Note that there is a proposal before the C++ standard committee on just this topic. Consider its semantics when implementing. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3515.pdf After reading that it doesn't seem like the same thing, they are talking about - essentially - creating classes to handle types with no runtime overhead, they want to be certain the optimizer got rid of it or save the optimizer a job. I'm not saying that's bad I just think it is separate. Typdefs are supposed to be an alias, yes in light of that the title of type definition seems a little misleading when put with that paper, but none the less a typedef is an alias. While reading the book The design and evolution of C++ (I am not saying this to throw around look, from the 'founder' of C++'s mouth!, I read it so I could learn why things are the way they are and errors which would have happened if things had of happened differently, wow that's a weird sentence, I mean failed attempts) I did enjoy reading about the strict typing that C++ introduced and that was to catch errors. The paper has a point, you would never try to multiply two game scores, so why have compiler tell you if you do? You'd surely mean it! What if you want to computer the geometric mean (or something, go with me) ultimately it's still an int! Why not go a step further and give the compiler the concept of a group (algebraic structure see [1]) this could stop divisions by zeros! Why not say you can no longer divide an integer by another integer? MOST of the time the result wont be an integer, with their example of cartesian(3) to spherical coordinates you shouldn't have to rigidly define such stuff that it throws an error when you do something as silly as mix them up and again, when they define x there is no one-size-fits-all definition for how x operates with other types. If you were to seriously try you'd just get so much spam, the only reason the idea doesn't totally implode is because you can cast back to the base, so if all your definitions - which are more like conditions - don't allow something, you just side-step it, this is an own goal the point was you would never sidestep. There is a line between what I am proposing and what they are, I cannot define exactly where it is, by their own admitance they cant: /This issue has been one of the consistent stumbling blocks in the design of an opaque typedef// //facility. In particular, we have come to realize that there is no one consistent approach to the// //return type issue such that it will meet all expectations under all circumstances//:/ If they could this would be far more important than a proposed C++ feature and would have been 'discovered' during the Abstract Algebra boom during the times of Gauss. Back on topic! I always thought of a hard-typedef as an extension of this. I don't want it treated like a class, I don't want this to be valid: hard typdef int BookId; int x = 5; BookId my_book = x; //should fail BookId alternate = (BookId) x; //fine - no runtime overhead because it's just an alias, no compiling overhead really either. This (in the world of classes) is interesting because if anything int is the parent of BookId, but I shouldn't need a constructor or a reinterpret_cast (however it'd be applicable) because I had written (BookId) before the x, and that's probably not an accident the compiler should realize I meant to do it. Now what about the other way? hard typdef int BookId; BookId x = 5; int my_book = x; //should fail int alternate = (int) x; //fine - no runtime overhead because LOOK! Now in terms of inheritance we have it going both ways, so while you could look at this as typdef system as a set of classes all storing one member of the same type with a different set of operations you cannot have implicit conversions both ways! It just makes no sense, yes it can stop you writing stupid things anyway, but what use is there in defining denominator to be nonzero or what about composite types I would never want to multiply a real by an imaginary
Re: hard typdef - proposal - I know it's not in the standard
On Wed, Jan 23, 2013 at 06:53:06AM +, Alec Teal wrote:
Hello,
This suggestion is obviously about typdefs and discusses a
*theoretical* implementation, well a few of them. Anyway please do
read this though. I'm really sorry for the poor structure, my hands
are really cold and I'm quite tired.
I understand that this issue has been discussed A LOT and there are
ways around the limitation, I suspect what I write is nothing new, I
don't claim to be the first ever.
Why not:
make an optional keyword, hard, have a meaning if before
Make your hard an attribute of variables:
http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html
Write a plugin http://gcc.gnu.org/onlinedocs/gccint/Plugins.html
or a MELT extension (http://gcc-melt.org/ is a domain specific language to
extend GCC)
dealing with that attribute.
This would be a good way to experiment your idea.
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
