__attribute__ ((deprecated))
Marcus G. Daniels
SS> The obvious thing would be to add a new attribute, so that a header
SS> could have something like
SS> extern int old_bad_fn (int) __attribute__ ((deprecated));
Sounds good, but how the heck do you get the Objective C parser to
accept __attribute__ for methods?
Anthony Green
Stan wrote:
> 3. If yes, what are the implementation caveats to watch out for?
> (needs to work for all of C/ObjC/C++)
This looks cool, but how would this work with localized compilers?
> extern int worse_fn (char)
> __attribute__ ((deprecated "use new_good_fn instead"));
>
> to get
>
> warning: worse_fn is deprecated; use new_good_fn instead
We would need some scheme for localizing these messages, or just put
up with mixed language compiler warnings.
AG
Stan Shebs
already thinking of ways to change the API for the next release
(hopefully for the better, but I won't editorialize further. :-) )
To help out developers, they've asked that the compiler support some
way to warn people that a particular function or variable may
go away or be changed at some point.
The obvious thing would be to add a new attribute, so that a header
could have something like
extern int old_bad_fn (int) __attribute__ ((deprecated));
then any calls or references to old_bad_fn would get something like
warning: old_bad_fn is deprecated
As an enhancement, the library folks would also like to be able
to add a more specific message:
extern int worse_fn (char)
__attribute__ ((deprecated "use new_good_fn instead"));
to get
warning: worse_fn is deprecated; use new_good_fn instead
Before we jump into implementing this, we'd like to get some input.
1. Does this seem like a worthwhile feature to add?
2. If no, what would be an equivalent alternative?
3. If yes, what are the implementation caveats to watch out for?
(needs to work for all of C/ObjC/C++)
Thanks for any and all advice!
Stan
Anthony Green
> There should be a mechanism to convey this information to the user,
> even if it has to be in English.
...assuming the authors of the libraries are writing in English.
Why not just have the warning refer to the source of the annotated
declaration?
AG
Stan Shebs
>
> For C and C++, is arbitrary text really needed? What if we allowed:
>
> int foo (int) __attribute__ ((deprecated "bar(int)"));
>
> ... and then used `printf ("%s is deprecated; use `%s' instead")
>
> This would solve the i18n problem at the loss of some generality. Is
> the generality really a requirement?
They would want to be able to mention releases, dates or packages
"only available if QuickTime 53.89 not installed" :-) or there
might be two functions that the developer would have to choose
between.
The situation is actually similar to #warning, which Apple uses
now to warn people about header changes, but which has no way
to be localized.
So the i18n aspect is mildly interesting, but I don't think anybody
will really worry about that until after we translate all the docs
for our 20,000 function API into a language other than English...
Stan
Stan Shebs
By modifying it, presumably. :-) The immediate request is for the
Carbon API I believe, which is C-based, but yeah, if we make it
available for Carbon, the Cocoa folks will probably get envious and
want it for their framework too. Thanks for the observation, I'll
take a look at the ObjC parser and see what it would take.
Stan
Tim Hollebeek
> >>>>> "Anthony" == Anthony Green <gr...@redhat.com> writes:
>
> >> Philipp wrote:
> >> With the compiler it wouldn't be such a problem. Mark the message
> >> with N_()
> >> (which would mark it as translatable string and thus it would appear in
> >> gcc.pot) and have the compiler call gettext.
>
> Anthony> Are you sure? I guess I don't understand GCC's i18n support.
> Anthony> Stan's proposal has part of the message in the user's source
> Anthony> code. How would that ever end up in gcc.pot?
>
> I don't see how it could.
>
> Note that we already have this problem in gcj, because like other Java
> compilers gcj will recognize `@deprecated' in javadoc comments and
> print a message -- which might include user text.
>
> For C and C++, is arbitrary text really needed? What if we allowed:
>
> int foo (int) __attribute__ ((deprecated "bar(int)"));
>
> ... and then used `printf ("%s is deprecated; use `%s' instead")
>
> This would solve the i18n problem at the loss of some generality. Is
> the generality really a requirement?
I'd rather not see useful functionality be lost because of an i18n
problem. Some functions are deprecated because they are out of date;
others are deprecated because they have severe security implications.
Tom Tromey
>> Philipp wrote:
>> With the compiler it wouldn't be such a problem. Mark the message
>> with N_()
>> (which would mark it as translatable string and thus it would appear in
>> gcc.pot) and have the compiler call gettext.
Anthony> Are you sure? I guess I don't understand GCC's i18n support.
Anthony> Stan's proposal has part of the message in the user's source
Anthony> code. How would that ever end up in gcc.pot?
I don't see how it could.
Note that we already have this problem in gcj, because like other Java
compilers gcj will recognize `@deprecated' in javadoc comments and
print a message -- which might include user text.
For C and C++, is arbitrary text really needed? What if we allowed:
int foo (int) __attribute__ ((deprecated "bar(int)"));
... and then used `printf ("%s is deprecated; use `%s' instead")
This would solve the i18n problem at the loss of some generality. Is
the generality really a requirement?
Tom
Joseph S. Myers
> > Sounds good, but how the heck do you get the Objective C parser to
> > accept __attribute__ for methods?
>
> By modifying it, presumably. :-) The immediate request is for the
> Carbon API I believe, which is C-based, but yeah, if we make it
> available for Carbon, the Cocoa folks will probably get envious and
> want it for their framework too. Thanks for the observation, I'll
> take a look at the ObjC parser and see what it would take.
You might want to look first at what's needed to get rid of the
shift/reduce conflicts in the ObjC parser, since anything touching
attributes has tended to be very fragile in terms of adding more conflicts
(and so in terms of being able to be reasonably sure that the change does
not cause incorrect parsing in some cases). (Once I've checked in my C
parser patch, that is - which will be once I can get a working bootstrap
of unmodified mainline in a reasonable time (the current problem being the
libjava tests hanging that's just been noted).)
--
Joseph S. Myers
js...@cam.ac.uk
Stan Shebs
I like that idea - it's easier to be expansive on the details of a
situation in a comment block in the header, plus then we don't
have to dink around with storing the warning string in trees.
Stan
Philipp Thomas
> > (which would mark it as translatable string and thus it would appear in
> > gcc.pot) and have the compiler call gettext.
>
> Are you sure? I guess I don't understand GCC's i18n support. Stan's
> proposal has part of the message in the user's source code. How would that
> ever end up in gcc.pot?
Forget it. I wrote that much too late for me and didn't think straight. Of
course this is user code so it would always be in the language it was
written in.
Philipp
--
Penguins shall save the dinosaurs
-- Handelsblatt about Linux on S/390
Philipp Thomas
Joern Rennecke
> > proposal has part of the message in the user's source code. How would that
> > ever end up in gcc.pot?
>
> Forget it. I wrote that much too late for me and didn't think straight. Of
> course this is user code so it would always be in the language it was
> written in.
No, it is library code. The provider of the library might speak a different
labguage than the user.
So it does make sense to provide a few standard phrases with translations,
and recommend to use one of these to get internationalized warnings.