const cleanup... where do consts in namespaces go
Hi, I was thinking of doing some general const cleanup in the (probably very few) places that may need it (if any at all). I'm thinking of it w/o looking at the code yet (just downloaded from CVS) so please forgive if it doesn't directly apply. What's the general karma of having something like const int blah = 123; in a header file, inside a namespace (or not)? As far as I take it, it's a declaration and definition in one. So, if the header is included in multiple modules, will the constant be replicated (defined) in the object files of all those modules? That would seem like a waste of space... Especially if the constant would be a large array. I'm in the new year cleanup mood and I thought I could do a couple of trivial things just for fun :) Cheers, Kuba Ober
Re: const cleanup... where do consts in namespaces go
Kuba Ober [EMAIL PROTECTED] writes: | Hi, | I was thinking of doing some general const cleanup in the (probably very few) | places that may need it (if any at all). I'm thinking of it w/o looking at | the code yet (just downloaded from CVS) so please forgive if it doesn't | directly apply. | What's the general karma of having something like | const int blah = 123; | in a header file, inside a namespace (or not)? As far as I take it, | it's a Do we have those in header files? that is not good. and if we had them it should be int const blah = 123; and it would still be bad. -- Lgb
Re: const cleanup... where do consts in namespaces go
| What's the general karma of having something like | | const int blah = 123; | | in a header file, inside a namespace (or not)? As far as I take it, | it's a Do we have those in header files? that is not good. and if we had them it should be int const blah = 123; and it would still be bad. Is there a practical difference between const int var and int const var ? Consider me dumb :( So, if there are constants that need to be made accessible to users of say given class, what's the best way to expose them? If int const blah = 123 is not the way, then what would be the way? I don't know whether LyX has those in header files yet, I'm just building a list of things to go over quickly. Kuba
Re: const cleanup... where do consts in namespaces go
Kuba Ober [EMAIL PROTECTED] writes: | What's the general karma of having something like | | const int blah = 123; | | in a header file, inside a namespace (or not)? As far as I take it, | it's a Do we have those in header files? that is not good. and if we had them it should be int const blah = 123; and it would still be bad. | Is there a practical difference between const int var and int const var ? | Consider me dumb :( Yes :-) Consistency. extern int const blah; // in the header file int const blah = 123; // in the source file -- Lgb
Re: const cleanup... where do consts in namespaces go
| Is there a practical difference between const int var and int const var ? | Consider me dumb :( Yes :-) Consistency. extern int const blah; // in the header file int const blah = 123; // in the source file OK, gotcha. Thanks. Kuba
const cleanup... where do consts in namespaces go
Hi, I was thinking of doing some general const cleanup in the (probably very few) places that may need it (if any at all). I'm thinking of it w/o looking at the code yet (just downloaded from CVS) so please forgive if it doesn't directly apply. What's the general karma of having something like const int blah = 123; in a header file, inside a namespace (or not)? As far as I take it, it's a declaration and definition in one. So, if the header is included in multiple modules, will the constant be replicated (defined) in the object files of all those modules? That would seem like a waste of space... Especially if the constant would be a large array. I'm in the "new year cleanup" mood and I thought I could do a couple of trivial things just for fun :) Cheers, Kuba Ober
Re: const cleanup... where do consts in namespaces go
Kuba Ober <[EMAIL PROTECTED]> writes: | Hi, > | I was thinking of doing some general const cleanup in the (probably very few) | places that may need it (if any at all). I'm thinking of it w/o looking at | the code yet (just downloaded from CVS) so please forgive if it doesn't | directly apply. > | What's the general karma of having something like > | const int blah = 123; > | in a header file, inside a namespace (or not)? As far as I take it, | it's a Do we have those in header files? that is not good. and if we had them it should be int const blah = 123; and it would still be bad. -- Lgb
Re: const cleanup... where do consts in namespaces go
> | What's the general karma of having something like > | > | const int blah = 123; > | > | in a header file, inside a namespace (or not)? As far as I take it, > | it's a > > Do we have those in header files? > that is not good. > and if we had them it should be > int const blah = 123; > and it would still be bad. Is there a practical difference between const int var and int const var ? Consider me dumb :( So, if there are constants that need to be made accessible to users of say given class, what's the best way to expose them? If int const blah = 123 is not the way, then what would be the way? I don't know whether LyX has those in header files yet, I'm just building a list of things to go over quickly. Kuba
Re: const cleanup... where do consts in namespaces go
Kuba Ober <[EMAIL PROTECTED]> writes: >> | What's the general karma of having something like >> | >> | const int blah = 123; >> | >> | in a header file, inside a namespace (or not)? As far as I take it, >> | it's a >> >> Do we have those in header files? >> that is not good. >> and if we had them it should be >> int const blah = 123; >> and it would still be bad. > | Is there a practical difference between const int var and int const var ? | Consider me dumb :( Yes :-) Consistency. extern int const blah; // in the header file int const blah = 123; // in the source file -- Lgb
Re: const cleanup... where do consts in namespaces go
> | Is there a practical difference between const int var and int const var ? > | Consider me dumb :( > > Yes :-) Consistency. > > extern int const blah; // in the header file > > int const blah = 123; // in the source file OK, gotcha. Thanks. Kuba
Re: LyX 1.1.6fix3 and namespaces, take two
Yves == Yves Bastide [EMAIL PROTECTED] writes: Yves Here is a second patch for building 1.1.6fix with gcc 3.0. This Yves one should be less bad :) I applied it. Thanks. JMarc
Re: LyX 1.1.6fix3 and namespaces, take two
> "Yves" == Yves Bastide <[EMAIL PROTECTED]> writes: Yves> Here is a second patch for building 1.1.6fix with gcc 3.0. This Yves> one should be less bad :) I applied it. Thanks. JMarc
Re: LyX 1.1.6fix3 and namespaces, take two
Yves == Yves Bastide [EMAIL PROTECTED] writes: Yves Here is a second patch for building 1.1.6fix with gcc 3.0. This Yves one should be less bad :) This looks very good to me. So, unless Lars objects, I'll apply it. JMarc
Re: LyX 1.1.6fix3 and namespaces, take two
> "Yves" == Yves Bastide <[EMAIL PROTECTED]> writes: Yves> Here is a second patch for building 1.1.6fix with gcc 3.0. This Yves> one should be less bad :) This looks very good to me. So, unless Lars objects, I'll apply it. JMarc
Re: LyX 1.1.6fix3 and namespaces
On 07-Jun-2001 Lars Gullik Bjønnes wrote: I just fixed that... Jürgen added something to a file that he shouldn't have... I'll commit in a little bit. Sorry you're right! Hopefully you can fix it for all of us. Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Tempt me with a spoon!
Re: LyX 1.1.6fix3 and namespaces
Juergen Vigna [EMAIL PROTECTED] writes: | On 07-Jun-2001 Lars Gullik Bjønnes wrote: | | I just fixed that... Jürgen added something to a file that he | shouldn't have... | | I'll commit in a little bit. | | Sorry you're right! Hopefully you can fix it for all of us. If your --with-included-string does not work you have to tell the errors. -- Lgb
Re: LyX 1.1.6fix3 and namespaces
On 08-Jun-2001 Lars Gullik Bjønnes wrote: If your --with-included-string does not work you have to tell the errors. Well the errors are easy. LString does not define __BASTRING__ and so the BOOST_NO_LIMITS is not defined. As I don't have a limits on my RedHat 7.1 system the #include limits then fails! I'll make for now with -DBOOST_NO_LIMITS that should do the trick, but obviously this should be somehow fixed. Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ If someone says he will do something without fail, he won't.
Re: LyX 1.1.6fix3 and namespaces
Juergen Vigna [EMAIL PROTECTED] writes: | On 08-Jun-2001 Lars Gullik Bjønnes wrote: | | If your --with-included-string does not work you have to tell the | errors. | | Well the errors are easy. LString does not define __BASTRING__ and so the | BOOST_NO_LIMITS is not defined. As I don't have a limits on my RedHat 7.1 | system the #include limits then fails! I'll make for now with -DBOOST_NO_LIMITS | that should do the trick, but obviously this should be somehow | fixed. You already tried to fix this with the LString.h in boost/config.hpp... and this is included with gcc 2.96. Also we now check for limits in configure, and BOOST_NO_LIMITS should be set if HAVE_LIMITS is not defined. So where is the error... -- Lgb
Re: LyX 1.1.6fix3 and namespaces
On 08-Jun-2001 Lars Gullik Bjønnes wrote: Juergen Vigna [EMAIL PROTECTED] writes: | On 08-Jun-2001 Lars Gullik Bjønnes wrote: | | If your --with-included-string does not work you have to tell the | errors. | | Well the errors are easy. LString does not define __BASTRING__ and so the | BOOST_NO_LIMITS is not defined. As I don't have a limits on my RedHat 7.1 | system the #include limits then fails! I'll make for now with -DBOOST_NO_LIMITS | that should do the trick, but obviously this should be somehow | fixed. You already tried to fix this with the LString.h in boost/config.hpp... and this is included with gcc 2.96. Also we now check for limits in configure, and BOOST_NO_LIMITS should be set if HAVE_LIMITS is not defined. So where is the error... From config.h: /* Define if you have the limits header file. */ /* #undef HAVE_LIMITS */ /* Define if you have the limits.h header file. */ #define HAVE_LIMITS_H 1 IMO (well actually I'm quite sure about this!) that it is not as you tell it above. I don't have HAVE_LIMITS defined and BOOST_NO_LIMITS is not defined so something seems to be wrong with the configure script, don't you think so? One more thing limits != limits.h!!! Including later gives compile errors! Jürgen P.S.: It's really easy for you to try this out you're working on RedHat 7.1 as I am aren't you? (I know its easier to get bug reports ;) -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Your business will assume vast proportions.
Re: LyX 1.1.6fix3 and namespaces
Juergen Vigna [EMAIL PROTECTED] writes: | On 08-Jun-2001 Lars Gullik Bjønnes wrote: | Juergen Vigna [EMAIL PROTECTED] writes: | | | On 08-Jun-2001 Lars Gullik Bjønnes wrote: | | | | If your --with-included-string does not work you have to tell the | | errors. | | | | Well the errors are easy. LString does not define __BASTRING__ and so the | | BOOST_NO_LIMITS is not defined. As I don't have a limits on my RedHat 7.1 | | system the #include limits then fails! I'll make for now with -DBOOST_NO_LIMITS | | that should do the trick, but obviously this should be somehow | | fixed. | | You already tried to fix this with the LString.h in | boost/config.hpp... and this is included with gcc 2.96. | Also we now check for limits in configure, and BOOST_NO_LIMITS | should be set if HAVE_LIMITS is not defined. So where is the error... | | From config.h: | | /* Define if you have the limits header file. */ | /* #undef HAVE_LIMITS */ no this is correct | /* Define if you have the limits.h header file. */ | #define HAVE_LIMITS_H 1 | | IMO (well actually I'm quite sure about this!) that it is not as you tell | it above. I don't have HAVE_LIMITS defined and BOOST_NO_LIMITS is not defined | so something seems to be wrong with the configure script, don't you think so? And the end of the configure script there should be a #ifndef HAVE_LIMITS #define BOOST_NO_LIMITS #endif are you missing that? | One more thing limits != limits.h!!! Including later gives | compile errors! limits == limits limits.h == climits | P.S.: It's really easy for you to try this out you're working on RedHat 7.1 as | I am aren't you? (I know its easier to get bug reports ;) I let you try it out... since you are one that want the lyxstring to work -- Lgb
Re: LyX 1.1.6fix3 and namespaces
On 08-Jun-2001 Lars Gullik Bjønnes wrote: And the end of the configure script there should be a #ifndef HAVE_LIMITS #define BOOST_NO_LIMITS #endif are you missing that? Yes I'm missing this one! Shouldn't that be too in config.h.in? It's missing there to! | One more thing limits != limits.h!!! Including later gives | compile errors! limits == limits limits.h == climits Thanks for the explanations! I let you try it out... since you are one that want the lyxstring to work Sure no problem at all! I just upgraded my system to latest rawhide 'gcc-*-85' glibc-2.2.3 and XFree-4.1.0 ;) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Treat your friend as if he might become an enemy. -- Publilius Syrus
Re: LyX 1.1.6fix3 and namespaces
Juergen Vigna [EMAIL PROTECTED] writes: | On 08-Jun-2001 Lars Gullik Bjønnes wrote: | | And the end of the configure script there should be a | | #ifndef HAVE_LIMITS | #define BOOST_NO_LIMITS | #endif | | are you missing that? | | Yes I'm missing this one! Shouldn't that be too in config.h.in? It's missing | there to! No, config.h.in is autogenerated. acconfig.h is the file you are looking for. hmm... autogen.sh should take care of this... -- Lgb
Re: LyX 1.1.6fix3 and namespaces
On 08-Jun-2001 Lars Gullik Bjønnes wrote: hmm... autogen.sh should take care of this... Well I more or less never run ./autogen.sh, I'll try if that helps! Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Q: How can you tell when a Burroughs salesman is lying? A: When his lips move.
Re: LyX 1.1.6fix3 and namespaces
Yves == Yves Bastide [EMAIL PROTECTED] writes: Yves Here's a patch; I finally didn't try to go and test the kde and Yves gnome frontends, since the versions of the libraries I have are Yves themselves to-be-cleaned. I do not like much the lstring.h solution... How come the main branch does not have this problem? Same goes for the separation of statements in paragraph.C... JMarc
Re: LyX 1.1.6fix3 and namespaces
On Fri, Jun 08, 2001 at 04:36:10PM +0200, Jean-Marc Lasgouttes wrote: Yves == Yves Bastide [EMAIL PROTECTED] writes: Yves Here's a patch; I finally didn't try to go and test the kde and Yves gnome frontends, since the versions of the libraries I have are Yves themselves to-be-cleaned. I do not like much the lstring.h solution... How come the main branch does not have this problem? Same goes for the separation of statements in paragraph.C... Hmm... Yes, I should have looked better. About lstring: lstring.h doesn't include cstring in the main branch, and use the #ifndef CXX_GLOBAL_CSTD trick (just as Lars told me %) paragraph.C: s/os.tellp()/int(os.tellp())/ JMarc -- Yves
LyX 1.1.6fix3 and namespaces, take two
Here is a second patch for building 1.1.6fix with gcc 3.0. This one should be less bad :) -- Yves std-try2.patch.gz
Re: LyX 1.1.6fix3 and namespaces
On 07-Jun-2001 Lars Gullik Bjønnes wrote: > I just fixed that... Jürgen added something to a file that he > shouldn't have... > > I'll commit in a little bit. Sorry you're right! Hopefully you can fix it for all of us. Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Tempt me with a spoon!
Re: LyX 1.1.6fix3 and namespaces
Juergen Vigna <[EMAIL PROTECTED]> writes: | On 07-Jun-2001 Lars Gullik Bjønnes wrote: | | > I just fixed that... Jürgen added something to a file that he | > shouldn't have... | > | > I'll commit in a little bit. | | Sorry you're right! Hopefully you can fix it for all of us. If your --with-included-string does not work you have to tell the errors. -- Lgb
Re: LyX 1.1.6fix3 and namespaces
On 08-Jun-2001 Lars Gullik Bjønnes wrote: > If your --with-included-string does not work you have to tell the > errors. Well the errors are easy. LString does not define __BASTRING__ and so the BOOST_NO_LIMITS is not defined. As I don't have a on my RedHat 7.1 system the #include then fails! I'll make for now with -DBOOST_NO_LIMITS that should do the trick, but obviously this should be somehow fixed. Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ If someone says he will do something "without fail", he won't.
Re: LyX 1.1.6fix3 and namespaces
Juergen Vigna <[EMAIL PROTECTED]> writes: | On 08-Jun-2001 Lars Gullik Bjønnes wrote: | | > If your --with-included-string does not work you have to tell the | > errors. | | Well the errors are easy. LString does not define __BASTRING__ and so the | BOOST_NO_LIMITS is not defined. As I don't have a on my RedHat 7.1 | system the #include then fails! I'll make for now with -DBOOST_NO_LIMITS | that should do the trick, but obviously this should be somehow | fixed. You already tried to fix this with the "LString.h" in boost/config.hpp... and this is included with gcc 2.96. Also we now check for in configure, and BOOST_NO_LIMITS should be set if HAVE_LIMITS is not defined. So where is the error... -- Lgb
Re: LyX 1.1.6fix3 and namespaces
On 08-Jun-2001 Lars Gullik Bjønnes wrote: > Juergen Vigna <[EMAIL PROTECTED]> writes: > >| On 08-Jun-2001 Lars Gullik Bjønnes wrote: >| >| > If your --with-included-string does not work you have to tell the >| > errors. >| >| Well the errors are easy. LString does not define __BASTRING__ and so the >| BOOST_NO_LIMITS is not defined. As I don't have a on my RedHat 7.1 >| system the #include then fails! I'll make for now with -DBOOST_NO_LIMITS >| that should do the trick, but obviously this should be somehow >| fixed. > > You already tried to fix this with the "LString.h" in > boost/config.hpp... and this is included with gcc 2.96. > Also we now check for in configure, and BOOST_NO_LIMITS > should be set if HAVE_LIMITS is not defined. So where is the error... >From config.h: /* Define if you have the header file. */ /* #undef HAVE_LIMITS */ /* Define if you have the header file. */ #define HAVE_LIMITS_H 1 IMO (well actually I'm quite sure about this!) that it is not as you tell it above. I don't have HAVE_LIMITS defined and BOOST_NO_LIMITS is not defined so something seems to be wrong with the configure script, don't you think so? One more thing != !!! Including later gives compile errors! Jürgen P.S.: It's really easy for you to try this out you're working on RedHat 7.1 as I am aren't you? (I know its easier to get bug reports ;) -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Your business will assume vast proportions.
Re: LyX 1.1.6fix3 and namespaces
Juergen Vigna <[EMAIL PROTECTED]> writes: | On 08-Jun-2001 Lars Gullik Bjønnes wrote: | > Juergen Vigna <[EMAIL PROTECTED]> writes: | > | >| On 08-Jun-2001 Lars Gullik Bjønnes wrote: | >| | >| > If your --with-included-string does not work you have to tell the | >| > errors. | >| | >| Well the errors are easy. LString does not define __BASTRING__ and so the | >| BOOST_NO_LIMITS is not defined. As I don't have a on my RedHat 7.1 | >| system the #include then fails! I'll make for now with -DBOOST_NO_LIMITS | >| that should do the trick, but obviously this should be somehow | >| fixed. | > | > You already tried to fix this with the "LString.h" in | > boost/config.hpp... and this is included with gcc 2.96. | > Also we now check for in configure, and BOOST_NO_LIMITS | > should be set if HAVE_LIMITS is not defined. So where is the error... | | >From config.h: | | /* Define if you have the header file. */ | /* #undef HAVE_LIMITS */ no this is correct | /* Define if you have the header file. */ | #define HAVE_LIMITS_H 1 | | IMO (well actually I'm quite sure about this!) that it is not as you tell | it above. I don't have HAVE_LIMITS defined and BOOST_NO_LIMITS is not defined | so something seems to be wrong with the configure script, don't you think so? And the end of the configure script there should be a #ifndef HAVE_LIMITS #define BOOST_NO_LIMITS #endif are you missing that? | One more thing != !!! Including later gives | compile errors! == == | P.S.: It's really easy for you to try this out you're working on RedHat 7.1 as | I am aren't you? (I know its easier to get bug reports ;) I let you try it out... since you are one that want the lyxstring to work -- Lgb
Re: LyX 1.1.6fix3 and namespaces
On 08-Jun-2001 Lars Gullik Bjønnes wrote: > And the end of the configure script there should be a > >#ifndef HAVE_LIMITS >#define BOOST_NO_LIMITS >#endif > > are you missing that? Yes I'm missing this one! Shouldn't that be too in config.h.in? It's missing there to! >| One more thing != !!! Including later gives >| compile errors! > > == > == Thanks for the explanations! > I let you try it out... > since you are one that want the lyxstring to work Sure no problem at all! I just upgraded my system to latest rawhide 'gcc-*-85' glibc-2.2.3 and XFree-4.1.0 ;) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Treat your friend as if he might become an enemy. -- Publilius Syrus
Re: LyX 1.1.6fix3 and namespaces
Juergen Vigna <[EMAIL PROTECTED]> writes: | On 08-Jun-2001 Lars Gullik Bjønnes wrote: | | > And the end of the configure script there should be a | > | >#ifndef HAVE_LIMITS | >#define BOOST_NO_LIMITS | >#endif | > | > are you missing that? | | Yes I'm missing this one! Shouldn't that be too in config.h.in? It's missing | there to! No, config.h.in is autogenerated. acconfig.h is the file you are looking for. hmm... autogen.sh should take care of this... -- Lgb
Re: LyX 1.1.6fix3 and namespaces
On 08-Jun-2001 Lars Gullik Bjønnes wrote: > hmm... autogen.sh should take care of this... Well I more or less never run ./autogen.sh, I'll try if that helps! Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Q: How can you tell when a Burroughs salesman is lying? A: When his lips move.
Re: LyX 1.1.6fix3 and namespaces
> "Yves" == Yves Bastide <[EMAIL PROTECTED]> writes: Yves> Here's a patch; I finally didn't try to go and test the kde and Yves> gnome frontends, since the versions of the libraries I have are Yves> themselves to-be-cleaned. I do not like much the lstring.h solution... How come the main branch does not have this problem? Same goes for the separation of statements in paragraph.C... JMarc
Re: LyX 1.1.6fix3 and namespaces
On Fri, Jun 08, 2001 at 04:36:10PM +0200, Jean-Marc Lasgouttes wrote: > > "Yves" == Yves Bastide <[EMAIL PROTECTED]> writes: > > Yves> Here's a patch; I finally didn't try to go and test the kde and > Yves> gnome frontends, since the versions of the libraries I have are > Yves> themselves to-be-cleaned. > > I do not like much the lstring.h solution... How come the main branch > does not have this problem? Same goes for the separation of statements > in paragraph.C... Hmm... Yes, I should have looked better. About lstring: lstring.h doesn't include in the main branch, and use the #ifndef CXX_GLOBAL_CSTD trick (just as Lars told me %) paragraph.C: s/os.tellp()/int(os.tellp())/ > > JMarc -- Yves
LyX 1.1.6fix3 and namespaces, take two
Here is a second patch for building 1.1.6fix with gcc 3.0. This one should be less bad :) -- Yves std-try2.patch.gz
LyX 1.1.6fix3 and namespaces
It seems that another number of std:: or using std:: are needed to compile
LyX 1.1.6 with GCC 3.0 or other modern compilers.
I guess that, in .C files, the preferred way is to use
#ifndef CXX_GLOBAL_CSTD
using std::strlen;
...
#endif
But what about header files? Is The Right Thing, such as
--- src/font.h 2000/09/27 18:13:29 1.6
+++ src/font.h 2001/06/07 10:10:11
@@ -61,7 +61,7 @@ struct lyxfont {
///
static
int width(char const * s, LyXFont const f) {
- return width(s, strlen(s), f);
+ return width(s, std::strlen(s), f);
}
///
static
acceptable for older compilers?
Thanks,
Yves
Re: LyX 1.1.6fix3 and namespaces
[EMAIL PROTECTED] (Yves Bastide) writes:
| It seems that another number of std:: or using std:: are needed to compile
| LyX 1.1.6 with GCC 3.0 or other modern compilers.
|
| I guess that, in .C files, the preferred way is to use
|
| #ifndef CXX_GLOBAL_CSTD
| using std::strlen;
| ...
| #endif
|
| But what about header files? Is The Right Thing, such as
|
| --- src/font.h 2000/09/27 18:13:29 1.6
| +++ src/font.h 2001/06/07 10:10:11
| @@ -61,7 +61,7 @@ struct lyxfont {
| ///
| static
| int width(char const * s, LyXFont const f) {
| - return width(s, strlen(s), f);
| + return width(s, std::strlen(s), f);
| }
| ///
| static
|
| acceptable for older compilers?
No, unfourtunately not.
We have to use the CXX_GLOBAL_CSTD there too.
--
Lgb
Re: LyX 1.1.6fix3 and namespaces
Yves == Yves Bastide [EMAIL PROTECTED] writes:
Yves It seems that another number of std:: or using std:: are needed
Yves to compile LyX 1.1.6 with GCC 3.0 or other modern compilers.
Yes, a patch to do that would be welcome.
Yves I guess that, in .C files, the preferred way is to use
Yves #ifndef CXX_GLOBAL_CSTD using std::strlen; ... #endif
Yes.
Yves But what about header files? Is The Right Thing, such as
Yves --- src/font.h 2000/09/27 18:13:29 1.6 +++ src/font.h 2001/06/07
Yves 10:10:11 @@ -61,7 +61,7 @@ struct lyxfont { /// static int
Yves width(char const * s, LyXFont const f) { - return width(s,
Yves strlen(s), f); + return width(s, std::strlen(s), f); } ///
Yves static
Yves acceptable for older compilers?
It will work for older gcc versions, but not for compaq cxx 6.2, which
understands namespaces but does not export C functions into std::
namespace. For this particular case, you can probably suppress width()
altogether. For other cases, just have a look at what has been done in
the main branch.
JMarc
Re: LyX 1.1.6fix3 and namespaces
On Thu, Jun 07, 2001 at 02:36:17PM +0200, Jean-Marc Lasgouttes wrote: Yves == Yves Bastide [EMAIL PROTECTED] writes: Yves It seems that another number of std:: or using std:: are needed Yves to compile LyX 1.1.6 with GCC 3.0 or other modern compilers. Yes, a patch to do that would be welcome. OK, I just did one; now checking if there are no errors with 2.95 (since I don't have other supported compilers). The diff is ~1000 lines, trivial. The only problem I found is with C headers including string.h. This header injects strlen et al. in the global namespace, and doing using std::strlen after is an error for GCC 3.0 (didn't check what the standard says). So I put #include support/lstrings.h before #include FORMS_H_LOCATION in a number of files. This is a hack: lstring.h includes cstring, and string.h is ignored. (In other cases, I directly included cstring...) Hm, not attaching the patch right now: I didn't fix other frontends than xforms [snip] JMarc -- Yves
Re: LyX 1.1.6fix3 and namespaces
[EMAIL PROTECTED] (Yves Bastide) writes: | On Thu, Jun 07, 2001 at 02:36:17PM +0200, Jean-Marc Lasgouttes wrote: | Yves == Yves Bastide [EMAIL PROTECTED] writes: | | Yves It seems that another number of std:: or using std:: are needed | Yves to compile LyX 1.1.6 with GCC 3.0 or other modern compilers. | | Yes, a patch to do that would be welcome. | | | OK, I just did one; now checking if there are no errors with 2.95 (since I | don't have other supported compilers). The diff is ~1000 lines, trivial. | | The only problem I found is with C headers including string.h. This | header injects strlen et al. in the global namespace, and doing | using std::strlen after is an error for GCC 3.0 (didn't check what the | standard says). So I put | #include support/lstrings.h | before | #include FORMS_H_LOCATION | in a number of files. This is a hack: lstring.h includes cstring, and | string.h is ignored. | (In other cases, I directly included cstring...) | | Hm, not attaching the patch right now: I didn't fix other frontends than | xforms I wonder why you have to change anything at all... I am compilig with gcc 3.0 all the and have commited all the changes I needed to compile... -- Lgb
Re: LyX 1.1.6fix3 and namespaces
On Thu, Jun 07, 2001 at 07:23:08PM +0200, Lars Gullik Bjønnes wrote: [EMAIL PROTECTED] (Yves Bastide) writes: [about patches for gcc 3.0] I wonder why you have to change anything at all... I am compilig with gcc 3.0 all the and have commited all the changes I needed to compile... Are you talking about -devel or the 1_1_6 branch? -- Lgb -- Yves
Re: LyX 1.1.6fix3 and namespaces
On Thu, Jun 07, 2001 at 08:01:38PM +0200, Lars Gullik Bjønnes wrote: [EMAIL PROTECTED] (Yves Bastide) writes: | On Thu, Jun 07, 2001 at 07:23:08PM +0200, Lars Gullik Bjønnes wrote: | [EMAIL PROTECTED] (Yves Bastide) writes: | [about patches for gcc 3.0] | | I wonder why you have to change anything at all... I am compilig with | gcc 3.0 all the and have commited all the changes I needed to | compile... | | Are you talking about -devel or the 1_1_6 branch? devel... and I figure you are taling bout the 1.1.6 branch... ok yup Here's a patch; I finally didn't try to go and test the kde and gnome frontends, since the versions of the libraries I have are themselves to-be-cleaned. -- Lgb -- Yves std-1.1.6.diff.gz
Re: LyX 1.1.6fix3 and namespaces
[EMAIL PROTECTED] (Yves Bastide) writes: | On Thu, Jun 07, 2001 at 07:23:08PM +0200, Lars Gullik Bjønnes wrote: | [EMAIL PROTECTED] (Yves Bastide) writes: | [about patches for gcc 3.0] | | I wonder why you have to change anything at all... I am compilig with | gcc 3.0 all the and have commited all the changes I needed to | compile... | | Are you talking about -devel or the 1_1_6 branch? devel... and I figure you are taling bout the 1.1.6 branch... ok -- Lgb
Re: LyX 1.1.6fix3 and namespaces
Lars Gullik Bjønnes wrote: devel... and I figure you are taling bout the 1.1.6 branch... ok -- Lgb Today I get numerous errors in .../boost/detail Here's a sample: ../../boost/boost/detail/limits.hpp:369: redefinition of `class std::numeric_limitsfloat' /usr/local/lib/gcc-lib/i586-pc-linux-gnu/3.0/include/g++/i586-pc-linux-gnu/bits/ std_limits.h:734: previous definition of `class std::numeric_limitsfloat' ../../boost/boost/detail/limits.hpp:397: redefinition of `class std::numeric_limitsdouble' /usr/local/lib/gcc-lib/i586-pc-linux-gnu/3.0/include/g++/i586-pc-linux-gnu/bits/ std_limits.h:782: previous definition of `class std::numeric_limitsdouble' ../../boost/boost/detail/limits.hpp:425: redefinition of `class std::numeric_limitslong double' /usr/local/lib/gcc-lib/i586-pc-linux-gnu/3.0/include/g++/i586-pc-linux-gnu/bits/ std_limits.h:830: previous definition of `class std::numeric_limitslong double' Garst
Re: LyX 1.1.6fix3 and namespaces
Garst R. Reese [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: | | devel... | | and I figure you are taling bout the 1.1.6 branch... ok | | -- | Lgb | Today I get numerous errors in .../boost/detail I just fixed that... Jürgen added something to a file that he shouldn't have... I'll commit in a little bit. -- Lgb
LyX 1.1.6fix3 and namespaces
It seems that another number of std:: or using std:: are needed to compile
LyX 1.1.6 with GCC 3.0 or other modern compilers.
I guess that, in .C files, the preferred way is to use
#ifndef CXX_GLOBAL_CSTD
using std::strlen;
...
#endif
But what about header files? Is The Right Thing, such as
--- src/font.h 2000/09/27 18:13:29 1.6
+++ src/font.h 2001/06/07 10:10:11
@@ -61,7 +61,7 @@ struct lyxfont {
///
static
int width(char const * s, LyXFont const & f) {
- return width(s, strlen(s), f);
+ return width(s, std::strlen(s), f);
}
///
static
acceptable for older compilers?
Thanks,
Yves
Re: LyX 1.1.6fix3 and namespaces
[EMAIL PROTECTED] (Yves Bastide) writes:
| It seems that another number of std:: or using std:: are needed to compile
| LyX 1.1.6 with GCC 3.0 or other modern compilers.
|
| I guess that, in .C files, the preferred way is to use
|
| #ifndef CXX_GLOBAL_CSTD
| using std::strlen;
| ...
| #endif
|
| But what about header files? Is The Right Thing, such as
|
| --- src/font.h 2000/09/27 18:13:29 1.6
| +++ src/font.h 2001/06/07 10:10:11
| @@ -61,7 +61,7 @@ struct lyxfont {
| ///
| static
| int width(char const * s, LyXFont const & f) {
| - return width(s, strlen(s), f);
| + return width(s, std::strlen(s), f);
| }
| ///
| static
|
| acceptable for older compilers?
No, unfourtunately not.
We have to use the CXX_GLOBAL_CSTD there too.
--
Lgb
Re: LyX 1.1.6fix3 and namespaces
>>>>> "Yves" == Yves Bastide <[EMAIL PROTECTED]> writes:
Yves> It seems that another number of std:: or using std:: are needed
Yves> to compile LyX 1.1.6 with GCC 3.0 or other modern compilers.
Yes, a patch to do that would be welcome.
Yves> I guess that, in .C files, the preferred way is to use
Yves> #ifndef CXX_GLOBAL_CSTD using std::strlen; ... #endif
Yes.
Yves> But what about header files? Is The Right Thing, such as
Yves> --- src/font.h 2000/09/27 18:13:29 1.6 +++ src/font.h 2001/06/07
Yves> 10:10:11 @@ -61,7 +61,7 @@ struct lyxfont { /// static int
Yves> width(char const * s, LyXFont const & f) { - return width(s,
Yves> strlen(s), f); + return width(s, std::strlen(s), f); } ///
Yves> static
Yves> acceptable for older compilers?
It will work for older gcc versions, but not for compaq cxx 6.2, which
understands namespaces but does not export C functions into std::
namespace. For this particular case, you can probably suppress width()
altogether. For other cases, just have a look at what has been done in
the main branch.
JMarc
Re: LyX 1.1.6fix3 and namespaces
On Thu, Jun 07, 2001 at 02:36:17PM +0200, Jean-Marc Lasgouttes wrote: > > "Yves" == Yves Bastide <[EMAIL PROTECTED]> writes: > > Yves> It seems that another number of std:: or using std:: are needed > Yves> to compile LyX 1.1.6 with GCC 3.0 or other modern compilers. > > Yes, a patch to do that would be welcome. > OK, I just did one; now checking if there are no errors with 2.95 (since I don't have other supported compilers). The diff is ~1000 lines, trivial. The only problem I found is with C headers including . This header injects strlen et al. in the global namespace, and doing using std::strlen after is an error for GCC 3.0 (didn't check what the standard says). So I put #include "support/lstrings.h" before #include FORMS_H_LOCATION in a number of files. This is a hack: lstring.h includes , and is ignored. (In other cases, I directly included ...) Hm, not attaching the patch right now: I didn't fix other frontends than xforms [snip] > > JMarc -- Yves
Re: LyX 1.1.6fix3 and namespaces
[EMAIL PROTECTED] (Yves Bastide) writes: | On Thu, Jun 07, 2001 at 02:36:17PM +0200, Jean-Marc Lasgouttes wrote: | > > "Yves" == Yves Bastide <[EMAIL PROTECTED]> writes: | > | > Yves> It seems that another number of std:: or using std:: are needed | > Yves> to compile LyX 1.1.6 with GCC 3.0 or other modern compilers. | > | > Yes, a patch to do that would be welcome. | > | | OK, I just did one; now checking if there are no errors with 2.95 (since I | don't have other supported compilers). The diff is ~1000 lines, trivial. | | The only problem I found is with C headers including . This | header injects strlen et al. in the global namespace, and doing | using std::strlen after is an error for GCC 3.0 (didn't check what the | standard says). So I put | #include "support/lstrings.h" | before | #include FORMS_H_LOCATION | in a number of files. This is a hack: lstring.h includes , and | is ignored. | (In other cases, I directly included ...) | | Hm, not attaching the patch right now: I didn't fix other frontends than | xforms I wonder why you have to change anything at all... I am compilig with gcc 3.0 all the and have commited all the changes I needed to compile... -- Lgb
Re: LyX 1.1.6fix3 and namespaces
On Thu, Jun 07, 2001 at 07:23:08PM +0200, Lars Gullik Bjønnes wrote: > [EMAIL PROTECTED] (Yves Bastide) writes: [about patches for gcc 3.0] > > I wonder why you have to change anything at all... I am compilig with > gcc 3.0 all the and have commited all the changes I needed to > compile... Are you talking about -devel or the 1_1_6 branch? > > -- > Lgb -- Yves
Re: LyX 1.1.6fix3 and namespaces
On Thu, Jun 07, 2001 at 08:01:38PM +0200, Lars Gullik Bjønnes wrote: > [EMAIL PROTECTED] (Yves Bastide) writes: > > | On Thu, Jun 07, 2001 at 07:23:08PM +0200, Lars Gullik Bjønnes wrote: > | > [EMAIL PROTECTED] (Yves Bastide) writes: > | [about patches for gcc 3.0] > | > > | > I wonder why you have to change anything at all... I am compilig with > | > gcc 3.0 all the and have commited all the changes I needed to > | > compile... > | > | Are you talking about -devel or the 1_1_6 branch? > > devel... > > and I figure you are taling bout the 1.1.6 branch... ok yup Here's a patch; I finally didn't try to go and test the kde and gnome frontends, since the versions of the libraries I have are themselves to-be-cleaned. > > -- > Lgb -- Yves std-1.1.6.diff.gz
Re: LyX 1.1.6fix3 and namespaces
[EMAIL PROTECTED] (Yves Bastide) writes: | On Thu, Jun 07, 2001 at 07:23:08PM +0200, Lars Gullik Bjønnes wrote: | > [EMAIL PROTECTED] (Yves Bastide) writes: | [about patches for gcc 3.0] | > | > I wonder why you have to change anything at all... I am compilig with | > gcc 3.0 all the and have commited all the changes I needed to | > compile... | | Are you talking about -devel or the 1_1_6 branch? devel... and I figure you are taling bout the 1.1.6 branch... ok -- Lgb
Re: LyX 1.1.6fix3 and namespaces
Lars Gullik Bjønnes wrote: > devel... > > and I figure you are taling bout the 1.1.6 branch... ok > > -- > Lgb Today I get numerous errors in .../boost/detail Here's a sample: ../../boost/boost/detail/limits.hpp:369: redefinition of `class std::numeric_limits' /usr/local/lib/gcc-lib/i586-pc-linux-gnu/3.0/include/g++/i586-pc-linux-gnu/bits/ std_limits.h:734: previous definition of `class std::numeric_limits' ../../boost/boost/detail/limits.hpp:397: redefinition of `class std::numeric_limits' /usr/local/lib/gcc-lib/i586-pc-linux-gnu/3.0/include/g++/i586-pc-linux-gnu/bits/ std_limits.h:782: previous definition of `class std::numeric_limits' ../../boost/boost/detail/limits.hpp:425: redefinition of `class std::numeric_limits' /usr/local/lib/gcc-lib/i586-pc-linux-gnu/3.0/include/g++/i586-pc-linux-gnu/bits/ std_limits.h:830: previous definition of `class std::numeric_limits' Garst
Re: LyX 1.1.6fix3 and namespaces
"Garst R. Reese" <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: | | > devel... | > | > and I figure you are taling bout the 1.1.6 branch... ok | > | > -- | > Lgb | Today I get numerous errors in .../boost/detail I just fixed that... Jürgen added something to a file that he shouldn't have... I'll commit in a little bit. -- Lgb
Re: namespaces
On Thu, Mar 15, 2001 at 07:20:52PM +0100, Lars Gullik Bjnnes wrote:
What I now need is a poll to see if anonymous namespaces are supported
on the different platforms.
So people please test:
namespace {
int foo() { return 1; }
}
int main() {
int i = foo();
}
Compiles just fine with:
$ CC -V
CC: WorkShop Compilers 5.0 98/12/15 C++ 5.0
$ CC -V
CC: Sun WorkShop 6 update 1 C++ 5.2 2000/09/11
$ CC -version [with and without -LANG:std]
MIPSpro Compilers: Version 7.3.1m
$ CC -version [with and without -LANG:std]
MIPSpro Compilers: Version 7.3.1.2m
$ aCC -V [with and without -AA]
aCC: HP ANSI C++ B3910B A.03.30
--
albert chin ([EMAIL PROTECTED])
Re: namespaces
On Thu, Mar 15, 2001 at 07:20:52PM +0100, Lars Gullik Bjønnes wrote:
> What I now need is a poll to see if anonymous namespaces are supported
> on the different platforms.
>
>
> So people please test:
>
>
> namespace {
>
> int foo() { return 1; }
>
> }
>
> int main() {
> int i = foo();
> }
Compiles just fine with:
$ CC -V
CC: WorkShop Compilers 5.0 98/12/15 C++ 5.0
$ CC -V
CC: Sun WorkShop 6 update 1 C++ 5.2 2000/09/11
$ CC -version [with and without -LANG:std]
MIPSpro Compilers: Version 7.3.1m
$ CC -version [with and without -LANG:std]
MIPSpro Compilers: Version 7.3.1.2m
$ aCC -V [with and without -AA]
aCC: HP ANSI C++ B3910B A.03.30
--
albert chin ([EMAIL PROTECTED])
RE: namespaces
On 15-Mar-2001 Lars Gullik Bjnnes wrote: So people please test: It compiles with RedHat7.0 (but you probably already knew:) Jrgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jrgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ You like to form new friendships and make new acquaintances.
Re: namespaces
In math_cursor.C:48 (using std::cerr) I got cerr undefined with gcc-3.0 How std is std? Garst
Re: namespaces
"Garst R. Reese" [EMAIL PROTECTED] writes: | In math_cursor.C:48 (using std::cerr) I got cerr undefined with gcc-3.0 | How std is std? very. but we should not use cerr in code, that is taken care of by lyxerr. Lgb
Re: namespaces
"Garst R. Reese" [EMAIL PROTECTED] writes: | In math_cursor.C:48 (using std::cerr) I got cerr undefined with | gcc-3.0 Probably because iostream is not included. but I changed this to lyxerr. Lgb
RE: namespaces
On 15-Mar-2001 Lars Gullik Bjønnes wrote: > So people please test: It compiles with RedHat7.0 (but you probably already knew:) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ You like to form new friendships and make new acquaintances.
Re: namespaces
In math_cursor.C:48 (using std::cerr) I got cerr undefined with gcc-3.0 How std is std? Garst
Re: namespaces
"Garst R. Reese" <[EMAIL PROTECTED]> writes: | In math_cursor.C:48 (using std::cerr) I got cerr undefined with gcc-3.0 | How std is std? very. but we should not use cerr in code, that is taken care of by lyxerr. Lgb
Re: namespaces
"Garst R. Reese" <[EMAIL PROTECTED]> writes: | In math_cursor.C:48 (using std::cerr) I got cerr undefined with | gcc-3.0 Probably because iostream is not included. but I changed this to lyxerr. Lgb
namespaces
I am now removing all CXX...NAMESPACES stuff (of course I should have
let someone with an older compiler do this...), will commit that in a
few minutes.
What I now need is a poll to see if anonymous namespaces are supported
on the different platforms.
So people please test:
namespace {
int foo() { return 1; }
}
int main() {
int i = foo();
}
And if you wonder why I want to know: The keyword "static" is
deprecated when used at file scope. And the prefered way to do it is
with anonymous namespaces.
Lgb
Re: namespaces
What I now need is a poll to see if anonymous namespaces are supported on the different platforms. Supported in 2.95.2. Andre' -- Andr Pnitz [EMAIL PROTECTED]
Re: namespaces
On Thu, Mar 15, 2001 at 07:20:52PM +0100, Lars Gullik Bjnnes wrote:
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Post: mailto:[EMAIL PROTECTED]
List-Help: mailto:[EMAIL PROTECTED]
List-Unsubscribe: mailto:[EMAIL PROTECTED]
Delivered-To: mailing list [EMAIL PROTECTED]
X-Authentication-Warning: trylle.birdstep.com: larsbj set sender to lyx using -f
To: [EMAIL PROTECTED]
Subject: namespaces
From: [EMAIL PROTECTED] (Lars Gullik Bjnnes)
Organization: LyX Developer http://www.lyx.org/
Date: 15 Mar 2001 19:20:52 +0100
User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7
I am now removing all CXX...NAMESPACES stuff (of course I should have
let someone with an older compiler do this...), will commit that in a
few minutes.
What I now need is a poll to see if anonymous namespaces are supported
on the different platforms.
So people please test:
namespace {
int foo() { return 1; }
}
int main() {
int i = foo();
}
And if you wonder why I want to know: The keyword "static" is
deprecated when used at file scope. And the prefered way to do it is
with anonymous namespaces.
Lgb
Compiles clean, a.out runs clean, no messages printed whatsoever.
(Does that mean 'yes'?)
egcs-1.1.2-30, egcs-c++-1.1.2-30, libstdc++-2.9.0-30. Red Hat 6.2.
--
Martin Vermeer [EMAIL PROTECTED]
Helsinki University of Technology
Department of Surveying
P.O. Box 1200, FIN-02015 HUT, Finland
:wq
namespaces
I am now removing all CXX...NAMESPACES stuff (of course I should have
let someone with an older compiler do this...), will commit that in a
few minutes.
What I now need is a poll to see if anonymous namespaces are supported
on the different platforms.
So people please test:
namespace {
int foo() { return 1; }
}
int main() {
int i = foo();
}
And if you wonder why I want to know: The keyword "static" is
deprecated when used at file scope. And the prefered way to do it is
with anonymous namespaces.
Lgb
Re: namespaces
> What I now need is a poll to see if anonymous namespaces are supported > on the different platforms. Supported in 2.95.2. Andre' -- André Pönitz [EMAIL PROTECTED]
Re: namespaces
On Thu, Mar 15, 2001 at 07:20:52PM +0100, Lars Gullik Bjønnes wrote:
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Precedence: bulk
> X-No-Archive: yes
> List-Post: <mailto:[EMAIL PROTECTED]>
> List-Help: <mailto:[EMAIL PROTECTED]>
> List-Unsubscribe: <mailto:[EMAIL PROTECTED]>
> Delivered-To: mailing list [EMAIL PROTECTED]
> X-Authentication-Warning: trylle.birdstep.com: larsbj set sender to lyx using -f
> To: [EMAIL PROTECTED]
> Subject: namespaces
> From: [EMAIL PROTECTED] (Lars Gullik Bjønnes)
> Organization: LyX Developer http://www.lyx.org/
> Date: 15 Mar 2001 19:20:52 +0100
> User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7
>
>
> I am now removing all CXX...NAMESPACES stuff (of course I should have
> let someone with an older compiler do this...), will commit that in a
> few minutes.
>
> What I now need is a poll to see if anonymous namespaces are supported
> on the different platforms.
>
>
> So people please test:
>
>
> namespace {
>
> int foo() { return 1; }
>
> }
>
> int main() {
> int i = foo();
> }
>
>
>
> And if you wonder why I want to know: The keyword "static" is
> deprecated when used at file scope. And the prefered way to do it is
> with anonymous namespaces.
>
> Lgb
Compiles clean, a.out runs clean, no messages printed whatsoever.
(Does that mean 'yes'?)
egcs-1.1.2-30, egcs-c++-1.1.2-30, libstdc++-2.9.0-30. Red Hat 6.2.
--
Martin Vermeer [EMAIL PROTECTED]
Helsinki University of Technology
Department of Surveying
P.O. Box 1200, FIN-02015 HUT, Finland
:wq
Re: Namespaces
"Angus" == Angus Leeming [EMAIL PROTECTED] writes: Angus As Lars says that namespaces are "GO, GO", I'd like to go Angus through the header files (not the .C files) and remove code Angus like: Angus #ifdef SIGC_CXX_NAMESPACES using SigC::Object; #endif If you are going to do that, then remove _all_ the namespace testing, please. JMarc
Re: Namespaces
On 14 Mar 2001, Jean-Marc Lasgouttes wrote:
"Angus" == Angus Leeming [EMAIL PROTECTED] writes:
Angus As Lars says that namespaces are "GO, GO", I'd like to go
Angus through the header files (not the .C files) and remove code
Angus like:
Angus #ifdef SIGC_CXX_NAMESPACES using SigC::Object; #endif
If you are going to do that, then remove _all_ the namespace testing,
please.
JMarc
and we should add a configure test and fail to complete if namespaces aren't supported.
will this fail reliably :
"
namespace Test {
class Best;
};
using Test::Best;
"
or will something else ? I'd do this but I don't have a broken-enough compiler around
thanks
john
--
"Never use a big word when a diminutive one would suffice.
Be more or less specific. Use words correctly, irregardless of how others use
them. Proofread carefully to see if you any words out.
Eschew ampersands abbreviations, etc. No sentence fragments."
- Basic rules of journalism
Re: Namespaces
John Levon [EMAIL PROTECTED] writes:
| On 14 Mar 2001, Jean-Marc Lasgouttes wrote:
|
| "Angus" == Angus Leeming [EMAIL PROTECTED] writes:
|
| Angus As Lars says that namespaces are "GO, GO", I'd like to go
| Angus through the header files (not the .C files) and remove code
| Angus like:
|
| Angus #ifdef SIGC_CXX_NAMESPACES using SigC::Object; #endif
|
| If you are going to do that, then remove _all_ the namespace testing,
| please.
|
| JMarc
|
| and we should add a configure test and fail to complete if namespaces aren't
|supported.
| will this fail reliably :
|
| "
| namespace Test {
| class Best;
| };
|
| using Test::Best;
| "
|
| or will something else ? I'd do this but I don't have a broken-enough compiler around
Look at the tests already used in configure.
Lgb
Re: Namespaces
On Wednesday 14 March 2001 11:02, Jean-Marc Lasgouttes wrote: "Angus" == Angus Leeming [EMAIL PROTECTED] writes: Angus As Lars says that namespaces are "GO, GO", I'd like to go Angus through the header files (not the .C files) and remove code Angus like: Angus #ifdef SIGC_CXX_NAMESPACES using SigC::Object; #endif If you are going to do that, then remove _all_ the namespace testing, please. I'm in the process of doing this in BRANCH_MVC. I currently have all code in frontends and daughter dirs in "namespace frontends" in my local tree and lyx still works, which was a pleasant surprise! I'll also remove the SIGC_CXX_NAMESPACES and USING_CXX_NAMESPACES stuff from config.h and hence from the configure scripts. I won't put in a new configure test for namespace support (required). Angus
Re: Namespaces
On 14 Mar 2001, Lars Gullik Bjønnes wrote: Look at the tests already used in configure. Lgb *doh* another moron day for me I think :) john (where did I think CXX_WORKING_NAMESPACES came from ? :P ) -- "Never use a big word when a diminutive one would suffice. Be more or less specific. Use words correctly, irregardless of how others use them. Proofread carefully to see if you any words out. Eschew ampersands abbreviations, etc. No sentence fragments." - Basic rules of journalism
Re: Namespaces
Angus Leeming [EMAIL PROTECTED] writes: | On Wednesday 14 March 2001 11:02, Jean-Marc Lasgouttes wrote: | "Angus" == Angus Leeming [EMAIL PROTECTED] writes: | | Angus As Lars says that namespaces are "GO, GO", I'd like to go | Angus through the header files (not the .C files) and remove code | Angus like: | | Angus #ifdef SIGC_CXX_NAMESPACES using SigC::Object; #endif | | If you are going to do that, then remove _all_ the namespace testing, | please. | | I'm in the process of doing this in BRANCH_MVC. I currently have all code in | frontends and daughter dirs in "namespace frontends" in my local tree and lyx | still works, which was a pleasant surprise! | | I'll also remove the SIGC_CXX_NAMESPACES and USING_CXX_NAMESPACES | stuff from config.h and hence from the configure scripts. | | I won't put in a new configure test for namespace support | (required). This will only make it harder to do the merge... Lgb
Re: Namespaces
This will only make it harder to do the merge... Lars Gullik Bjønnes! You mean it's going to happen? W! Are you happy with things as they stand? Shall I make a patch of BRANCH_MVC's current contents against HEAD and submit it to you? I can easily undiff the changes I've made in my local tree but keep the patch for later inclusion in HEAD. Angus
Re: Namespaces
Angus Leeming [EMAIL PROTECTED] writes: | This will only make it harder to do the merge... | | Lars Gullik Bjnnes! You mean it's going to happen? W! Just give me some hours. I want to have the compability code for minipages work first. (at least I now know why it does not work) I want to checkout the MVC branch, compile it, look at it. Create a diff agains head to see what is really changing. _Then_ do the actual merge. Fix conflicts. Actually you should do this last bit, then post a patch against latest head, and I'll apply that. And I really only want MVC changes in that patch... Lgb
Re: Namespaces
On Wednesday 14 March 2001 12:25, Lars Gullik Bjnnes wrote: Angus Leeming [EMAIL PROTECTED] writes: | This will only make it harder to do the merge... | | Lars Gullik Bjnnes! You mean it's going to happen? W! Just give me some hours. I want to have the compability code for minipages work first. (at least I now know why it does not work) I want to checkout the MVC branch, compile it, look at it. Create a diff agains head to see what is really changing. _Then_ do the actual merge. Fix conflicts. Actually you should do this last bit, then post a patch against latest head, and I'll apply that. And I really only want MVC changes in that patch... Sure. BRANCH_MVC contains only MVC changes. Whenever you're ready, just give me a shout. A
Re: Namespaces
>>>>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> As Lars says that namespaces are "GO, GO", I'd like to go Angus> through the header files (not the .C files) and remove code Angus> like: Angus> #ifdef SIGC_CXX_NAMESPACES using SigC::Object; #endif If you are going to do that, then remove _all_ the namespace testing, please. JMarc
Re: Namespaces
On 14 Mar 2001, Jean-Marc Lasgouttes wrote:
> >>>>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> As Lars says that namespaces are "GO, GO", I'd like to go
> Angus> through the header files (not the .C files) and remove code
> Angus> like:
>
> Angus> #ifdef SIGC_CXX_NAMESPACES using SigC::Object; #endif
>
> If you are going to do that, then remove _all_ the namespace testing,
> please.
>
> JMarc
and we should add a configure test and fail to complete if namespaces aren't supported.
will this fail reliably :
"
namespace Test {
class Best;
};
using Test::Best;
"
or will something else ? I'd do this but I don't have a broken-enough compiler around
thanks
john
--
"Never use a big word when a diminutive one would suffice.
Be more or less specific. Use words correctly, irregardless of how others use
them. Proofread carefully to see if you any words out.
Eschew ampersands & abbreviations, etc. No sentence fragments."
- Basic rules of journalism
Re: Namespaces
John Levon <[EMAIL PROTECTED]> writes:
| On 14 Mar 2001, Jean-Marc Lasgouttes wrote:
|
| > >>>>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
| >
| > Angus> As Lars says that namespaces are "GO, GO", I'd like to go
| > Angus> through the header files (not the .C files) and remove code
| > Angus> like:
| >
| > Angus> #ifdef SIGC_CXX_NAMESPACES using SigC::Object; #endif
| >
| > If you are going to do that, then remove _all_ the namespace testing,
| > please.
| >
| > JMarc
|
| and we should add a configure test and fail to complete if namespaces aren't
|supported.
| will this fail reliably :
|
| "
| namespace Test {
| class Best;
| };
|
| using Test::Best;
| "
|
| or will something else ? I'd do this but I don't have a broken-enough compiler around
Look at the tests already used in configure.
Lgb
Re: Namespaces
On Wednesday 14 March 2001 11:02, Jean-Marc Lasgouttes wrote: > >>>>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> As Lars says that namespaces are "GO, GO", I'd like to go > Angus> through the header files (not the .C files) and remove code > Angus> like: > > Angus> #ifdef SIGC_CXX_NAMESPACES using SigC::Object; #endif > > If you are going to do that, then remove _all_ the namespace testing, > please. I'm in the process of doing this in BRANCH_MVC. I currently have all code in frontends and daughter dirs in "namespace frontends" in my local tree and lyx still works, which was a pleasant surprise! I'll also remove the SIGC_CXX_NAMESPACES and USING_CXX_NAMESPACES stuff from config.h and hence from the configure scripts. I won't put in a new configure test for namespace support (required). Angus
Re: Namespaces
On 14 Mar 2001, Lars Gullik Bjønnes wrote: > Look at the tests already used in configure. > > Lgb *doh* another moron day for me I think :) john (where did I think CXX_WORKING_NAMESPACES came from ? :P ) -- "Never use a big word when a diminutive one would suffice. Be more or less specific. Use words correctly, irregardless of how others use them. Proofread carefully to see if you any words out. Eschew ampersands & abbreviations, etc. No sentence fragments." - Basic rules of journalism
Re: Namespaces
Angus Leeming <[EMAIL PROTECTED]> writes: | On Wednesday 14 March 2001 11:02, Jean-Marc Lasgouttes wrote: | > >>>>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: | > | > Angus> As Lars says that namespaces are "GO, GO", I'd like to go | > Angus> through the header files (not the .C files) and remove code | > Angus> like: | > | > Angus> #ifdef SIGC_CXX_NAMESPACES using SigC::Object; #endif | > | > If you are going to do that, then remove _all_ the namespace testing, | > please. | | I'm in the process of doing this in BRANCH_MVC. I currently have all code in | frontends and daughter dirs in "namespace frontends" in my local tree and lyx | still works, which was a pleasant surprise! | | I'll also remove the SIGC_CXX_NAMESPACES and USING_CXX_NAMESPACES | stuff from config.h and hence from the configure scripts. | | I won't put in a new configure test for namespace support | (required). This will only make it harder to do the merge... Lgb
Re: Namespaces
> This will only make it harder to do the merge... Lars Gullik Bjønnes! You mean it's going to happen? W! Are you happy with things as they stand? Shall I make a patch of BRANCH_MVC's current contents against HEAD and submit it to you? I can easily undiff the changes I've made in my local tree but keep the patch for later inclusion in HEAD. Angus
Re: Namespaces
Angus Leeming <[EMAIL PROTECTED]> writes: | > This will only make it harder to do the merge... | | Lars Gullik Bjønnes! You mean it's going to happen? W! Just give me some hours. I want to have the compability code for minipages work first. (at least I now know why it does not work) I want to checkout the MVC branch, compile it, look at it. Create a diff agains head to see what is really changing. _Then_ do the actual merge. Fix conflicts. Actually you should do this last bit, then post a patch against latest head, and I'll apply that. And I really only want MVC changes in that patch... Lgb
Re: Namespaces
On Wednesday 14 March 2001 12:25, Lars Gullik Bjønnes wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > > | > This will only make it harder to do the merge... > | > | Lars Gullik Bjønnes! You mean it's going to happen? W! > > Just give me some hours. > > I want to have the compability code for minipages work first. (at > least I now know why it does not work) > > I want to checkout the MVC branch, compile it, look at it. > > Create a diff agains head to see what is really changing. > > _Then_ do the actual merge. Fix conflicts. Actually you should > do this last bit, then post a patch against latest head, and I'll > apply that. > > And I really only want MVC changes in that patch... Sure. BRANCH_MVC contains only MVC changes. Whenever you're ready, just give me a shout. A
Namespaces
As Lars says that namespaces are "GO, GO", I'd like to go through the header files (not the .C files) and remove code like: #ifdef SIGC_CXX_NAMESPACES using SigC::Object; #endif Please object now! Angus
Namespaces
As Lars says that namespaces are "GO, GO", I'd like to go through the header files (not the .C files) and remove code like: #ifdef SIGC_CXX_NAMESPACES using SigC::Object; #endif Please object now! Angus
Re: namespaces
On Wednesday 07 March 2001 18:08, Allan Rae wrote:
On Wed, 7 Mar 2001, Angus Leeming wrote:
Does the fact that "boost::scoped_ptrs" etc are now appearing everywhere
mean
that we are now using namespaces officially and that I can write (for
example):
namespace frontends {
namespace citation {
...
}
}
You could but why would you need namespace citation?
Just to bundle the view and controller sections?
Seems a bit of overkill.
Just the frontend namespace should be enough.
Although, I think (instant thought -- just add water) that maybe a
namespace frontend ... I don't know I've lost the thought now...
maybe I just thought better of it. Maybe I'm tired. Maybe I'm turning
into a Morlock. (I think I spelled that right -- and no I didn't mispell
Worlock)
Don't go eating the idle and the beautiful. That's just not nice.
Actually, I think I'll hold on here (see André's comment). But my namespace
citation would contain (see below) together with the GUI-specific View.
Definitely enough to justify its own namespace, I think.
namespace citation {
class ControlCitation : public ControlCommand
{
public:
ControlCitation(LyXView , Dialogs );
/// A vector of bibliography keys
std::vectorstring const getBibkeys();
/** Returns the BibTeX data associated with a given key.
Empty if no info exists. */
string const getBibkeyInfo(string const );
};
/** This class instantiates and makes available the GUI-specific
ButtonController and View.
*/
template class GUIview, class GUIbc
class GUICitation : public ControlCitation {
public:
GUICitation(LyXView , Dialogs );
virtual ButtonControllerBase bc() { return bc_; }
virtual ViewBase view() { return view_; }
};
/** Helper functions, of possible use to all frontends */
/** Multiple citation keys are stored in InsetCommandParams::contents as a
comma-separated string. These two functions convert to/from a vector. */
string const getStringFromVector(std::vectorstring const );
std::vectorstring const getVectorFromString(string const );
/** Search a BibTeX info field for the given key and return the
associated field. */
string const parseBibTeX(string data, string const findkey);
}
Re: namespaces
On Thursday 08 March 2001 09:37, Andre Poenitz wrote:
namespace citation {
class ControlCitation : public ControlCommand
Isn't one of the ideas of namespaces that instead of
citation::ControlCitation
citation::GUICitation
one could use shorter names like
citation::Control
citation::Gui
And if we're still in that interim
#ifdef CXX_HAS_NAMESPACES
namespace citation
#endif
...
#ifdef CXX_HAS_NAMESPACES
}
#endif
?
Re: namespaces
And if we're still in that interim #ifdef CXX_HAS_NAMESPACES namespace citation #endif Ok... if people use compilers without namespace support we'll certainly get into trouble if we rely on them... Question is: What compilers do people use and what features do these compilers support? In the Linux world, I'd say 2.95 and later is usable on machines that are able to run LyX, but I don't know much about the darker corners of the world ;-} Andre' -- Andr Pnitz [EMAIL PROTECTED]
Re: namespaces
"Andre" == Andre Poenitz [EMAIL PROTECTED] writes: And if we're still in that interim #ifdef CXX_HAS_NAMESPACES namespace citation #endif Andre Ok... if people use compilers without namespace support we'll Andre certainly get into trouble if we rely on them... Andre Question is: What compilers do people use and what features do Andre these compilers support? Basically gcc 2.8.x and egcs 1.0.x do not support namespaces. Dekel and I used to compile with them, but we have upgraded now. So the problem is just to know whether we want to support those compilers for other people. If we decide to do so, I can compile with gcc 2.8.1 from time to time to check that it still works. Andre In the Linux world, I'd say 2.95 and later is usable on Andre machines that are able to run LyX, but I don't know much about Andre the darker corners of the world ;-} I don't know either. We could maybe poll lyx-users. JMarc
Re: namespaces
If we decide to do so, I can compile with gcc 2.8.1 from time to time to check that it still works. Having namespaces can be really nice... it took me a while to arrive at this conclusion but I am a convinced "namespacer" by now... Andre In the Linux world, I'd say 2.95 and later is usable on Andre machines that are able to run LyX, but I don't know much about Andre the darker corners of the world ;-} I don't know either. We could maybe poll lyx-users. Good idea... Would you do that? Andre' PS: Anybody betting how Lars would vote? ;-) -- Andr Pnitz [EMAIL PROTECTED]
Re: namespaces
"Andre" == Andre Poenitz [EMAIL PROTECTED] writes: Andre Good idea... Would you do that? Andre PS: Anybody betting how Lars would vote? ;-) I guess the two questions are related. Let's see how Lars' ukase on the question looks like. JMarc
