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: 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
> | 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: | 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
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: 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
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 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
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 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
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: > 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: | > 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: > 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: | | > 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: > 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 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 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
"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: 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
[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
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
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
[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 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
>>>>> "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
[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
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: 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
>>>>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> I am now removing all CXX...NAMESPACES stuff (of course I should Lars> have let someone with an older compiler do this...), will commit Lars> that in a few minutes. Lars> What I now need is a poll to see if anonymous namespaces are Lars> supported on the different platforms. Lars> So people please test: It does not work with gcc 2.8.1 !!! (OK, maybe you knoew that already) More useful information: it does work with cxx 6.2-027, although it kindly points out that you defined variable i but never use it. Bad practice... JMarc
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
"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
In math_cursor.C:48 (using std::cerr) I got cerr undefined with gcc-3.0 How std is std? Garst
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
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
> 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]
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
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
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
> 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: | 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
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
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
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 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
>>>>> "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
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
Andre Poenitz <[EMAIL PROTECTED]> writes: | Would you mind if somebody asked on the users' list what compilers people | are using? Certainly not. Lgb
Re: namespaces
> For me namespaces is "Go! Go!", exceptions must still wait a bit > (exceptions will also mean a lot of changes in lyx code). Ok... although I do not want to sprinkle mathed with 'mathed::' already, I'd like to reserve 'mathed::' (or maybe 'math::') for mathed related stuff. I.e. I would not mind if GUII and Table people used something not beginning with 'math' :-} > Besides this we are using iostream, std::containers etc. all over. So > we are actaully beginning to resemple a pretty modern C++ program. > What is missing now is good std::locale support, and wide > streams/strings. Would you mind if somebody asked on the users' list what compilers people are using? Andre' -- André Pönitz [EMAIL PROTECTED]
Re: namespaces
Juergen Vigna <[EMAIL PROTECTED]> writes: | On 08-Mar-2001 Andre Poenitz wrote: | | > PS: Anybody betting how Lars would vote? ;-) | | Well I bet 1 cent he want's to wait till all have upgraded their | compilers ;P For me is gcc 3.0 the turning point. That compiler is roumored to compile the linux kernel ok (or at least the RH gcc 2.96 is). So after that we should _at least_ be able to use C++ fetures present in gcc 2.95.2/3. Other vendor's compilers are cathing up (C++ wise) very fast, and we should just stop supporting older compilers. For me namespaces is "Go! Go!", exceptions must still wait a bit (exceptions will also mean a lot of changes in lyx code). Besides this we are using iostream, std::containers etc. all over. So we are actaully beginning to resemple a pretty modern C++ program. What is missing now is good std::locale support, and wide streams/strings. Lgb
Re: namespaces
On 08-Mar-2001 Andre Poenitz wrote: > PS: Anybody betting how Lars would vote? ;-) Well I bet 1 cent he want's to wait till all have upgraded their compilers ;P 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ I could dance with you till the cows come home. On second thought, I'd rather dance with the cows till you come home. -- Groucho Marx
Re: namespaces
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: >> | I guess the two questions are related. Let's see how Lars' ukase >> | on the question looks like. >> >> "ukase"?? Andre> Maybe it's not the proper plural... It was not meant to be plural, anyway. Andre> I'd vote for 'ukases' in English and 'ukasi' in Russian. In Andre> German 'Ukase' is certainly an acceptable abbreviation for Andre> 'edicts of the Czar' ;-) In french it would be Oukase... JMarc
Re: namespaces
> | I guess the two questions are related. Let's see how Lars' ukase > | on the question looks like. > > "ukase"?? Maybe it's not the proper plural... I'd vote for 'ukases' in English and 'ukasi' in Russian. In German 'Ukase' is certainly an acceptable abbreviation for 'edicts of the Czar' ;-) Andre' -- André Pönitz [EMAIL PROTECTED]
Re: namespaces
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | I guess the two questions are related. Let's see how Lars' ukase | on the question looks like. "ukase"?? Lgb
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
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é Pönitz [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
> 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é Pönitz [EMAIL PROTECTED]
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
> 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
?
Andre'
--
André Pönitz [EMAIL PROTECTED]
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::vector 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 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::vector const &);
std::vector 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
> > Does the fact that "boost::scoped_ptrs" etc are now appearing > > everywhere mean that we are now using namespaces officially > You could but why would you need namespace citation? Maybe we should have some rules fixed first... like 'no caps' in the names or how much should go in a namespace and so on... Andre' -- André Pönitz [EMAIL PROTECTED]
Re: namespaces
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)
Allan. (ARRae)
namespaces
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 {
...
}
}
?
Angus
Re: namespaces
> "John" == John Weiss <[EMAIL PROTECTED]> writes: John> Maybe we should have a subdir with several small sourcelets and John> a Makefile desiged to test whether or not the compiler supports John> certain ANSI C++ features yet. We could ask folks to mail in John> what they find. Then we'll have some sense of which compilers do John> what. configure.in reads: ### Some checks on what the C++ compiler can(not) do LYX_CXX_MUTABLE LYX_CXX_PARTIAL LYX_CXX_EXPLICIT dnl we do not use stl stack, or at least not on gcc 2.7, which was the dnl cause for this test. dnl LYX_CXX_STL_STACK LYX_CXX_STL_STRING LYX_CXX_NAMESPACES LYX_CXX_CHEADERS LYX_STD_COUNT dnl we disable rtti for now dnl LYX_CXX_RTTI AC_CHECK_HEADERS(ostream istream) LYX_CXX_STL_MODERN_STREAMS In fact, all of these checks are not used currently. Note that the namespace check only checks that STL puts things in std::. JMarc
Re: namespaces
On Tue, Dec 21, 1999 at 11:35:52AM +0100, Lars Gullik Bjønnes wrote: > Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > > | >>>>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: > | > | Lars> Does namespace support work on all the compilers that the 1.1.x > | Lars> series currently compiles on? It would be nice, but somehow I doubt it, > The pity, is that now we use structs to hack around not using > namespaces... Not unusual; we do this where I work. Hmmm... Maybe we should have a subdir with several small sourcelets and a Makefile desiged to test whether or not the compiler supports certain ANSI C++ features yet. We could ask folks to mail in what they find. Then we'll have some sense of which compilers do what. -- John Weiss
Re: namespaces
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | >>>>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> | cxx 6.1: OK. | | Lars> IMO if this works we should begin using | Lars> a LyX namespace right | Lars> away. We have already had the sqrt | Lars> clash. | | I'd rather avoid it for now :) | | Lars> The pity, is that now we use structs to hack around not using | Lars> namespaces... | | Yes, but in the case of sqrt, naming a pixmap like that is stupid, | anyway... I do not really see the advantage of defining LyX::sqrt | instead of LyX_sqrt (or better sqrt_xpm). I agree on this specific case. LyX::TextClassList LyX::Layout LyX::Textclass would be nice... as would Debug:: Lgb
Re: namespaces
>>>>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> | cxx 6.1: OK. | | Lars> IMO if this works we should begin using Lars> a LyX namespace right | Lars> away. We have already had the sqrt Lars> clash. | | I'd rather avoid it for now :) Lars> The pity, is that now we use structs to hack around not using Lars> namespaces... Yes, but in the case of sqrt, naming a pixmap like that is stupid, anyway... I do not really see the advantage of defining LyX::sqrt instead of LyX_sqrt (or better sqrt_xpm). JMarc
Re: namespaces
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | >>>>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> Does namespace support work on all the compilers that the 1.1.x | Lars> series currently compiles on? | | gcc 2.8.1: | | fantomas: g++ -Wall -ansi -pedantic nsp.C | nsp.C:1: sorry, not implemented: namespace I just hate gcc 2.8.x :-) | cxx 6.1: OK. | | Lars> IMO if this works we should begin using a LyX namespace right | Lars> away. We have already had the sqrt clash. | | I'd rather avoid it for now :) The pity, is that now we use structs to hack around not using namespaces... Lgb
Re: namespaces
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Does namespace support work on all the compilers that the 1.1.x Lars> series currently compiles on? gcc 2.8.1: fantomas: g++ -Wall -ansi -pedantic nsp.C nsp.C:1: sorry, not implemented: namespace cxx 6.1: OK. Lars> IMO if this works we should begin using a LyX namespace right Lars> away. We have already had the sqrt clash. I'd rather avoid it for now :) JMarc
namespaces
Does namespace support work on all the compilers that the 1.1.x series
currently compiles on?
i.e. does this code compile and run:
namespace LyX {
int small_lyx_function();
}
int LyX::small_lyx_function() {
int i = 0;
i += 3;
return i;
}
int main() {
LyX::small_lyx_function();
}
IMO if this works we should begin using a LyX namespace right away. We
have already had the sqrt clash.
Lgb
Re: About namespaces
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> I am really beggining to hate cxx... Keep cool :) I understand that cxx default behaviour is suboptomal, and if I can make it work with strict_ansi option, I'll be happy... Lars> How do you set the streambuf on a ostream in cxx? Is it a Lars> different member method? Lars> ANSI C++ has: streambuf * rdbuf(); // get the streambuf Lars> streambuf * rdbuf(streambuf*); // get old and set new streambuf Peering through the headers, this does not seem to be possible with old-style library... But the ansi one works fine. I guess this means I can completely forget about this pre-ansi support, and that I have to find out about those type incompatibilities. JMarc
Re: About namespaces
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | Lars> streamsize should exist in "not-so-new" implementations of the | Lars> iostreams too. | | My not-so-new version of the STL (when not using strict_ansi) uses | 'int' for that. Ok, then for this specific compiler we could have a typedef for that. | And it seems to use different semantics for some | classes, which gives errors like | | cxx: Error: ../../../lyx-devel/src/support/DebugStream.C, line 133: | identifier "filebuf" is undefined | filebuf fbuf; | ^ | cxx: Error: ../../../lyx-devel/src/support/DebugStream.C, line 149: | too many arguments in function call | delete rdbuf(new teebuf(cerr.rdbuf(), [...] | cxx: Error: ../../../lyx-devel/src/support/DebugStream.C, line 171: | too many arguments in function call | delete rdbuf(new teebuf(cerr.rdbuf(), | -^ I am really beggining to hate cxx... How do you set the streambuf on a ostream in cxx? Is it a different member method? ANSI C++ has: streambuf * rdbuf(); // get the streambuf streambuf * rdbuf(streambuf*); // get old and set new streambuf And what is filebuf called in cxx? Lgb
Re: About namespaces
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | Lars> Lars> ostream & operator<<(ostream &, ); | | OK, so I Lars> included "debug.h" in places which define these operators. It | Lars> would seem more reasonable to me to define a LOStreams.h header Lars> (like | LString.h) which sets up ostreams correctly for our own Lars> use. Is that | OK with you? Lars> ok...I can live with that... I'll do it, then. Lars> | | If we used so-called non-modern STL, shouldn't we add a Lars> typedef for | streamsize? Lars> streamsize should exist in "not-so-new" implementations of the Lars> iostreams too. My not-so-new version of the STL (when not using strict_ansi) uses 'int' for that. And it seems to use different semantics for some classes, which gives errors like cxx: Error: ../../../lyx-devel/src/support/DebugStream.C, line 133: identifier "filebuf" is undefined filebuf fbuf; ^ cxx: Error: ../../../lyx-devel/src/support/DebugStream.C, line 149: too many arguments in function call delete rdbuf(new teebuf(cerr.rdbuf(), -^ cxx: Error: ../../../lyx-devel/src/support/DebugStream.C, line 156: too many arguments in function call delete nullstream.rdbuf(0); // Without this we leak ^ cxx: Error: ../../../lyx-devel/src/support/DebugStream.C, line 157: too many arguments in function call delete rdbuf(0);// Without this we leak -^ cxx: Error: ../../../lyx-devel/src/support/DebugStream.C, line 171: too many arguments in function call delete rdbuf(new teebuf(cerr.rdbuf(), -^ Lars> | I'll think more about the debugstream definition later... Lars> ?? I was refereing to the discussion you had on the not-statifying-but-best-you-came-up-with solution for defining the Debug::type enum. You will be glad to learn that I cannot think of something better :) JMarc
Re: About namespaces
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | Lars> ostream & operator<<(ostream &, ); | | OK, so I included "debug.h" in places which define these operators. It | would seem more reasonable to me to define a LOStreams.h header (like | LString.h) which sets up ostreams correctly for our own use. Is that | OK with you? ok...I can live with that... | | If we used so-called non-modern STL, shouldn't we add a typedef for | streamsize? streamsize should exist in "not-so-new" implementations of the iostreams too. | I'll think more about the debugstream definition later... ?? Lgb
Re: About namespaces
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> | Lars> And to whom would the "definitions [be] much cleaner" ? Lars> | | I mean that if everytime we use we need 15 lines Lars> of | error prone preprocessor stuff, the fun factor will tend to Lars> go low. At | first I thought that we would use these << Lars> operators only on a | DebugStream, so just including "debug.h" Lars> would setup everything nicely | for us. If you really plan to Lars> send them to real streams, then I agree | we should think of Lars> something else. Lars> That is the nice thing of useing Lars> ostream & operator<<(ostream &, ); OK, so I included "debug.h" in places which define these operators. It would seem more reasonable to me to define a LOStreams.h header (like LString.h) which sets up ostreams correctly for our own use. Is that OK with you? If we used so-called non-modern STL, shouldn't we add a typedef for streamsize? I'll think more about the debugstream definition later... JMarc
Re: About namespaces
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| For the streams in , we now in DebugStream.h which ones are
| needed. So I guess it is all or nothing.
s/now/know ?
Yes I think you are right.
| Lars> And to whom would the "definitions [be] much cleaner" ?
|
| I mean that if everytime we use we need 15 lines of
| error prone preprocessor stuff, the fun factor will tend to go low. At
| first I thought that we would use these << operators only on a
| DebugStream, so just including "debug.h" would setup everything nicely
| for us. If you really plan to send them to real streams, then I agree
| we should think of something else.
That is the nice thing of useing
ostream & operator<<(ostream &, );
We don't need to know what types of ostreams we are writing to, this
will fit nicely into _any_ ostream. Even if we only use this for
DebugStream now, we might use it for the .lyx file later.
| Now that I think of it, after "debug.h" is included, we are guaranteed
| that ostream can be accessed directly, right?
Yes, in close to all cases. I think you can assume so.
| Lars> | (BTW, why does DebugStream.C include | debug.h and not
| Lars> DebugStream.h?)
|
| Lars> Because of the struct Debug, which is not LyX specific. Every
| Lars> application that uses DebugStream needs to have Debug::types
| Lars> defined.
|
| This is not very clean, IMO. Isn't this a case where we should define
| DebugStream as a template?
No, I don't think so... A template could be used, but then you require
Debug to be a struct and do not allow it to be a namespace.
I am also not very satisfied by the current solution, but I don't see
any other nice solution. The nice thing about the current solution is
that DebugStream does not need to know anything abut Debug::type, it
only need to exist at be a binary(?) enum. What I originally wanted
was something like:
namespace Debug {
enum type {
no_err = 0,
err1 = 1,
err2 = 2,
err3 = 4,
...
}
}
class DebugStream {
DebugStream(Debug::type a);
};
The DebugStream does require a Debug::type to be existant, but does not
need to know anything about it. The Debug::type is application
specific the DebugStream is not. This means to me that DebugStream.h
should not put any demands on where the Debug::type is defined. So
currently this is the layout:
debug.h: contains the Debug::type and includes the DebugStream.h
DebugStream.C: includes debug.h (and this is what I think is dirty
but I don't have a good solution.)
Of course we could have a requirement on applications using
DebugStream that the must have a header "debug.h" that defines the
Debug::type. That would clean up the '#include "debug.h"' in the
DebugStream.C file, but then all files now including "debug.h" must
include "DebugStream.h" instead which also is not very clean...and you
get into a problem on where do declare lyxerr.
| Lars> This is depricated in the C++ standard and has also nothing to
| Lars> do with Cinlcudes. The old header for iostreams was
| Lars> and the new one is They are not equivalent in the
| Lars> same way as and is.
|
| Yes, I understand that... So, your point is that we do not even try to
| support istreams.hxx (which seems to be old-style Dec, I do not see
| whether others used that too), right?
the iostreams in are quite similar to the one in
so in a lot of cases they can be used interchangable. F.ex.
Gcc 2.95 has now a header that just uses the old
implementation, but they are workign hard on making a
real std::iostream.
Lgb
Re: About namespaces
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | Lars> 1) in DebugStream.h, make sure that 'using std::ostream' is used Lars> (and | for other streams types we need too). Lars> Perhaps a Lars> #if NEED_USING_XXX using xxx; #endif Lars> construct? For the streams in , we now in DebugStream.h which ones are needed. So I guess it is all or nothing. Lars> | 2) remove all explicit std:: for all stream types in Lars> DebugStream.[Ch] Lars> | 3) for classes which define a << operator (commandtags...) Lars> define the | operator wrt DebugStream instead of ostream? This Lars> would make | definitions much cleaner Lars> But then you cannot dump commandtags/font/etc to a regular Lars> stream (actually _any_ ostream). So when we write an operator Lars> that writes to an ostream we should use an ostream. We should Lars> not change this. OK. Lars> And to whom would the "definitions [be] much cleaner" ? I mean that if everytime we use we need 15 lines of error prone preprocessor stuff, the fun factor will tend to go low. At first I thought that we would use these << operators only on a DebugStream, so just including "debug.h" would setup everything nicely for us. If you really plan to send them to real streams, then I agree we should think of something else. Now that I think of it, after "debug.h" is included, we are guaranteed that ostream can be accessed directly, right? Lars> | (BTW, why does DebugStream.C include | debug.h and not Lars> DebugStream.h?) Lars> Because of the struct Debug, which is not LyX specific. Every Lars> application that uses DebugStream needs to have Debug::types Lars> defined. This is not very clean, IMO. Isn't this a case where we should define DebugStream as a template? Lars> This is depricated in the C++ standard and has also nothing to Lars> do with Cinlcudes. The old header for iostreams was Lars> and the new one is They are not equivalent in the Lars> same way as and is. Yes, I understand that... So, your point is that we do not even try to support istreams.hxx (which seems to be old-style Dec, I do not see whether others used that too), right? JMarc
Re: About namespaces
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | 1) in DebugStream.h, make sure that 'using std::ostream' is used (and |for other streams types we need too). Perhaps a #if NEED_USING_XXX using xxx; #endif construct? | 2) remove all explicit std:: for all stream types in DebugStream.[Ch] | 3) for classes which define a << operator (commandtags...) define the |operator wrt DebugStream instead of ostream? This would make |definitions much cleaner But then you cannot dump commandtags/font/etc to a regular stream (actually _any_ ostream). So when we write an operator that writes to an ostream we should use an ostream. We should not change this. And to whom would the "definitions [be] much cleaner" ? | (BTW, why does DebugStream.C include |debug.h and not DebugStream.h?) Because of the struct Debug, which is not LyX specific. Every application that uses DebugStream needs to have Debug::types defined. | Lars> plain ostream is not an option (except for very short term), it | Lars> must be: | | Lars> using std::ostream; ostream a; | | Lars> or | | Lars> std::ostream a; | | I thought that if we used the 'old' streams (iostreams?), the classes | were declared at toplevel. At least I think that is what DEC cxx does. This is depricated in the C++ standard and has also nothing to do with Cinlcudes. The old header for iostreams was and the new one is They are not equivalent in the same way as and is. Lgb
Re: About namespaces
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | Lars> 1) add the proper 'using std::ostream' for all the objects like Lars> this | that we use. The particular problem with ostream is that Lars> it is or | is not in std:: depending on the header we use to Lars> declare it... Lars> One other problem with ostream (and string for that matter) is Lars> that a conformant implementations uses templates for these and Lars> thus you are not allowed to use a forward declaration in your Lars> code. (e.g. class ostream; ) Luckily this problem is easy to Lars> solve just add the correct inlcude file instead of using the Lars> forward declaration. Would that be alright with you to do the following: 1) in DebugStream.h, make sure that 'using std::ostream' is used (and for other streams types we need too). 2) remove all explicit std:: for all stream types in DebugStream.[Ch] 3) for classes which define a << operator (commandtags...) define the operator wrt DebugStream instead of ostream? This would make definitions much cleaner (BTW, why does DebugStream.C include debug.h and not DebugStream.h?) I think this should be enough for now. Lars> std::string and std::ostream is not what I am talking about when Lars> saying "fun factor", is it more that using iostream is more fun Lars> than C i/o. Using "using" at appropriate places is of course ok. We agree, then. Lars> My realy problem with "using std::ostream" in this specfic Lars> context (debugstream) is that it pollutes the global Lars> namespace...but perhaps that is of little concern... anyway this Lars> would not have been a problem if we were allowed to put Lars> debugstream inside a namespace. The only problem is that we should not have a variable named ostream, which is not a big deal IMO. Note that all the classes we do not use do not pollute namespace, so we know what we are doing. Lars> plain ostream is not an option (except for very short term), it Lars> must be: Lars> using std::ostream; ostream a; Lars> or Lars> std::ostream a; I thought that if we used the 'old' streams (iostreams?), the classes were declared at toplevel. At least I think that is what DEC cxx does. JMarc
Re: About namespaces
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| 1) add the proper 'using std::ostream' for all the objects like this
|that we use. The particular problem with ostream is that it is or
|is not in std:: depending on the header we use to declare it...
One other problem with ostream (and string for that matter) is that a
conformant implementations uses templates for these and thus you are
not allowed to use a forward declaration in your code. (e.g. class
ostream; ) Luckily this problem is easy to solve just add the correct
inlcude file instead of using the forward declaration.
| 2) define a macro STD (or maybe _std_) which is set to NULL when we do
|not want to have namespaces. A problem with this is constructs
|like
| debugbuf(streambuf * b)
| : std::streambuf(), sb(b) {}
|where the compiler (gcc 2.8.1 here) does not understand correctly
|": ::". This means that we will have to reorder initializations or
|other non-fun (TM) stuff.
|
| Concerning using explicit namespaces and fun factor: I do not think
| that using std::string or std::ostream all over the code is much fun,
| and it seems to me that specifying 'using' in strategic places
| still provides us with namespace protection for other classes defined
| in headers. However, if Lars prefers option 2), that's OK with me.
std::string and std::ostream is not what I am talking about when
saying "fun factor", is it more that using iostream is more fun than C
i/o. Using "using" at appropriate places is of course ok.
My realy problem with "using std::ostream" in this specfic context
(debugstream) is that it pollutes the global namespace...but perhaps
that is of little concern... anyway this would not have been a problem
if we were allowed to put debugstream inside a namespace.
plain ostream is not an option (except for very short term), it must be:
using std::ostream;
ostream a;
or
std::ostream a;
Lgb
About namespaces
Hello,
I am still in the process of compiling LyX with DEC cxx compiler. It
seems that adding the cfoo headers from GNU libstdc++ gives good
results, but I have problems with namespaces.
The problem: stuff like ostream is used sometimes with std::,
sometimes without. While it might be OK with gcc, it is not with cxx
(and it does not make sense anyway).
So I guess we need a solution to this. I see several:
1) add the proper 'using std::ostream' for all the objects like this
that we use. The particular problem with ostream is that it is or
is not in std:: depending on the header we use to declare it...
2) define a macro STD (or maybe _std_) which is set to NULL when we do
not want to have namespaces. A problem with this is constructs
like
debugbuf(streambuf * b)
: std::streambuf(), sb(b) {}
where the compiler (gcc 2.8.1 here) does not understand correctly
": ::". This means that we will have to reorder initializations or
other non-fun (TM) stuff.
Concerning using explicit namespaces and fun factor: I do not think
that using std::string or std::ostream all over the code is much fun,
and it seems to me that specifying 'using' in strategic places
still provides us with namespace protection for other classes defined
in headers. However, if Lars prefers option 2), that's OK with me.
JMarc
Re: Namespaces (was: string vs. LString)
>>>>> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes: Allan> Asger seems to want to make extensive use of namespaces and to Allan> a certain extent I can see that as being a good way to enforce Allan> the notion of ownership to the various modules. So we could Allan> have a gui namespace and an Inset namespace among others. If Allan> we then use namespaces in our code we can use namespaces from Allan> stl (which involves using different headers). Well, I see it as good but not necessarily required if we do not want to lock out a number of compilers... JMarc
Re: Namespaces (was: string vs. LString)
> Asger seems to want to make extensive use of namespaces and to a certain > extent I can see that as being a good way to enforce the notion of > ownership to the various modules. So we could have a gui namespace and an > Inset namespace among others. If we then use namespaces in our code we > can use namespaces from stl (which involves using different headers). Yes, I would like to use namespaces more. My feeling is that the bad things about global functions and variables does not exists anymore when you have namespaces. Suddenly, there is nothing wrong with having global functions and variables, and this change opens up some methods of coding that were previously packed away as bad coding style. With namespaces, I feel it's easier to let the code express what things are. For instance, the encoding facility is a global means of performing encoding conversions, that does not depend on any state or context. So I don't see why this feature should not just be exactly that in the code: an independent global function that does the conversion. Regarding whether we should *require* support for namespaces from the compiler or not: I have no real opinion on this. I'm sure that we can make things work without proper namespace support, and that is a good thing. The important thing is that the developers will be able to exploit the concept of namespaces, and if their compiler is up to it, get the extra safety from the compiler. I find it hard to make a list of things that we want from the compiler in advance. I'm more into the lazy style: Just code, and then take care of the problems when they appear. That's what we have been doing so far, and it seems to work pretty well. Of course, we are demanding more things from the compilers now, and it might turn out that we have to set some minimum requirements, but until we know more about the problems, it's hard to say what those are. Greets, Asger
Re: Namespaces (was: string vs. LString)
On Thu, 8 Apr 1999, Jean-Marc Lasgouttes wrote: > >>>>> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes: > > Allan> # We still need portability to other platforms of course but we > Allan> can draw a line and say "it must support namespaces" or > Allan> whatever else we desire. We can probably get away without > Allan> partial specialization of templates. > > Could you explain why we need those namespaces? I understand what they > are in general, but we could probably live with std:: being the same > as the glabal namespace, if we choose names correctly. Well, I was trying to start a discussion about what we needed from the current standard and what we could live without. Asger seems to want to make extensive use of namespaces and to a certain extent I can see that as being a good way to enforce the notion of ownership to the various modules. So we could have a gui namespace and an Inset namespace among others. If we then use namespaces in our code we can use namespaces from stl (which involves using different headers). > Other than that, I agree that we should draw a line somewhere. But we > should be careful to draw it at the right place. And remember that > many people need to compile on the platform compilers and try to > support at least the latest version of these compilers. Absolutely. Allan. (ARRae)
Re: Namespaces (was: string vs. LString)
>>>>> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes: Allan> # We still need portability to other platforms of course but we Allan> can draw a line and say "it must support namespaces" or Allan> whatever else we desire. We can probably get away without Allan> partial specialization of templates. Could you explain why we need those namespaces? I understand what they are in general, but we could probably live with std:: being the same as the glabal namespace, if we choose names correctly. Other than that, I agree that we should draw a line somewhere. But we should be careful to draw it at the right place. And remember that many people need to compile on the platform compilers and try to support at least the latest version of these compilers. JMarc
Namespaces (was: string vs. LString)
On 29 Mar 1999, Lars Gullik Bjønnes wrote: > We need to introduce namespaces rather soon. > Lgb Perhaps we should make a decision as to what compiler capabilities we require. By the time LyX-1.1 is finished and stable enough to release there will probably be another gcc released and egcs will also be better. So perhaps we should make those the standard now and forget about gcc-2.7.2 and its contemporaries and concentrate on getting better code written instead of compatability#. That would also be a benefit for me since I could avoid having to reinstall gcc-2.7.2 and just stick with the two compilers I have now instead of the old 4 compiler installation I used to have. Points: Anyone using egcs should be using the latest or latest - 1. It is experimental after all and egcs-1.0.3a has a few flaws. Namespaces are handy and extensively used in the STL so it would make sense to exploit them rather than try to work around them. Allan. (ARRae) # We still need portability to other platforms of course but we can draw a line and say "it must support namespaces" or whatever else we desire. We can probably get away without partial specialization of templates.
