Re: Some compilation problems with latest cvs
On Thu, Oct 14, 1999 at 02:58:53PM +0200, Lars Gullik Bjønnes wrote: John Weiss [EMAIL PROTECTED] writes: | I'm sure there are other features that haven't made it into every | compiler yet. There are things which you can safely assume are now in | every C++ compiler currently in use. There are other things, features | only recently agreed upon by the ANSI committee, that haven't made | their way in. Ah you mean "recently" as in "at least two years ago". :-) Unfortunately, yes. We moan about this all the time at work... -- John Weiss
Re: Some compilation problems with latest cvs
On Thu, Oct 14, 1999 at 02:58:53PM +0200, Lars Gullik Bjønnes wrote: > John Weiss <[EMAIL PROTECTED]> writes: > > | I'm sure there are other features that haven't made it into every > | compiler yet. There are things which you can safely assume are now in > | every C++ compiler currently in use. There are other things, features > | only recently agreed upon by the ANSI committee, that haven't made > | their way in. > > Ah you mean "recently" as in "at least two years ago". :-) Unfortunately, yes. We moan about this all the time at work... -- John Weiss
Re: Some compilation problems with latest cvs
If you'd ask me (And I'm pretty sure, you won't ;-| ): Make a single stable release and start over from scratch. The *last* step would be to add compatibility to the existent LyX. I always thought that's what was intented with the old 1.1 branch? We tried that, but it didn't work. We do not have the resources to pull such a stunt through. So, now we do it in a different way that is better suited to the resources we have. Please join us in this work. Just start with a random header file, and read it. Then read the implementation, and document the header file. Maybe rename a few functions to better names, and maybe move stuff into other files that are more logical. That is easy to do, and does not require a deep understanding of LyX. And if you do this, the source will slowly be much easier to deal with. So please stop complaining and do some work. Lgb is saying that he wants to use real C++, but if you look at the source, it's not poluted with partial specialization, dynamic_cast and other stuff at all. Jean-Marc is struggling hard to get LyX to compile with DEC cxx. And when we discover a problem, we will work around it. Regarding the requirement for autoconf, automake, and gettext: We require those tools in order to allow things to be simpler. Greets, Asger
Re: Some compilation problems with latest cvs
> If you'd ask me (And I'm pretty sure, you won't ;-| ): Make a single > stable release and start over from scratch. The *last* step would be to > add compatibility to the existent LyX. I always thought that's what was > intented with the old 1.1 branch? We tried that, but it didn't work. We do not have the resources to pull such a stunt through. So, now we do it in a different way that is better suited to the resources we have. Please join us in this work. Just start with a random header file, and read it. Then read the implementation, and document the header file. Maybe rename a few functions to better names, and maybe move stuff into other files that are more logical. That is easy to do, and does not require a deep understanding of LyX. And if you do this, the source will slowly be much easier to deal with. So please stop complaining and do some work. Lgb is saying that he wants to use real C++, but if you look at the source, it's not poluted with partial specialization, dynamic_cast and other stuff at all. Jean-Marc is struggling hard to get LyX to compile with DEC cxx. And when we discover a problem, we will work around it. Regarding the requirement for autoconf, automake, and gettext: We require those tools in order to allow things to be simpler. Greets, Asger
Re: Some compilation problems with latest cvs
"Andre' Poenitz" [EMAIL PROTECTED] writes: | Lars And gcc 2.8.1 shows again that it is not suited for serious C++ | Lars development... | | Somehow I knew you would say that :) | | aol on | Me too. | aol off = AOL | flame on | Using bleeding edge features is *not* "serious C++ development". What bleeding edege? What you call bleeding edge in C++ was put into the draft standard for the most part over 3 years ago, and a lot of the things years before that. The standard was finished 1.5 years ago, and ratified by ANSI 1 year ago. | Serious C++ development is about modularization, lean interfaces, | design of re-usable code and stuff like that. And? What about: adhereing to a standard, portable, ease to maintain, planning for future expansion. We can't just we can't just write for GCD for ever. | Hell, you can do | "serious C++ development" in any programming language. No you can't... You can to your analyse and other pre coding development on a piece of paper, but that still don't make it C++. | But what is | currently done is far from that. My perception of the "development | process" is that five percent of the developers sprinkle bleeding edge | stuff all over the code, twenty percent try to work | around them because they have to use non-conforming compilers and the | rest struggles to keep up. This is far, far from efficient. Actaully we don't have much problems with compilers... it is some, but most of this is easy or neccessary to workaround anyway. | There are quite a few thing I'd like to improve on lyx, I'd like to have | full xfig support, "native" inclusion of .gif and .tiff, a decent file | format and things like that. Feel free to begin something like this at any time. | I have downloaded the latest CVS tree about | two dozen times now, even started a bit of coding now and then - of | course after a round of installing new stuff (be it a new autoconfig or | a new compiler) most of the time. This must have been a 10 min effort every time...Lyx has not changed in that respect in the last 1.5 years. Until very recently. [...noise...] | If you'd ask me (And I'm pretty sure, you won't ;-| ): Make a single | stable release and start over from scratch. The *last* step would be to | add compatibility to the existent LyX. I always thought that's what was | intented with the old 1.1 branch? Ever wondered why the old 1.1.x branch never took off? It existed for more than a year you know... Do you want to begin a ~70k lines project from scratch? | And no, I won't stop using LyX, because it does a pretty good job for | the things I need to do: write texts with math. But I won't stop | complaining either since I don't like to see valuable resources | (the developer's - i.e. YOUR! - work) wasted. Non-developers complaining about development style/ progression / coding style are just noise to me. Lgb
Re: Some compilation problems with latest cvs
"Andre' Poenitz" <[EMAIL PROTECTED]> writes: | > Lars> And gcc 2.8.1 shows again that it is not suited for serious C++ | > Lars> development... | > | > Somehow I knew you would say that :) | | | Me too. | = AOL | | Using bleeding edge features is *not* "serious C++ development". What bleeding edege? What you call bleeding edge in C++ was put into the draft standard for the most part over 3 years ago, and a lot of the things years before that. The standard was finished 1.5 years ago, and ratified by ANSI 1 year ago. | Serious C++ development is about modularization, lean interfaces, | design of re-usable code and stuff like that. And? What about: adhereing to a standard, portable, ease to maintain, planning for future expansion. We can't just we can't just write for GCD for ever. | Hell, you can do | "serious C++ development" in any programming language. No you can't... You can to your analyse and other pre coding development on a piece of paper, but that still don't make it C++. | But what is | currently done is far from that. My perception of the "development | process" is that five percent of the developers sprinkle bleeding edge | stuff all over the code, twenty percent try to work | around them because they have to use non-conforming compilers and the | rest struggles to keep up. This is far, far from efficient. Actaully we don't have much problems with compilers... it is some, but most of this is easy or neccessary to workaround anyway. | There are quite a few thing I'd like to improve on lyx, I'd like to have | full xfig support, "native" inclusion of .gif and .tiff, a decent file | format and things like that. Feel free to begin something like this at any time. | I have downloaded the latest CVS tree about | two dozen times now, even started a bit of coding now and then - of | course after a round of installing new stuff (be it a new autoconfig or | a new compiler) most of the time. This must have been a 10 min effort every time...Lyx has not changed in that respect in the last 1.5 years. Until very recently. [...noise...] | If you'd ask me (And I'm pretty sure, you won't ;-| ): Make a single | stable release and start over from scratch. The *last* step would be to | add compatibility to the existent LyX. I always thought that's what was | intented with the old 1.1 branch? Ever wondered why the old 1.1.x branch never took off? It existed for more than a year you know... Do you want to begin a ~70k lines project from scratch? | And no, I won't stop using LyX, because it does a pretty good job for | the things I need to do: write texts with math. But I won't stop | complaining either since I don't like to see valuable resources | (the developer's - i.e. YOUR! - work) wasted. Non-developers complaining about development style/ progression / coding style are just noise to me. Lgb
Re: Some compilation problems with latest cvs
Lars And gcc 2.8.1 shows again that it is not suited for serious C++ Lars development... Somehow I knew you would say that :) aol on Me too. aol off flame on Using bleeding edge features is *not* "serious C++ development". Serious C++ development is about modularization, lean interfaces, design of re-usable code and stuff like that. Hell, you can do "serious C++ development" in any programming language. But what is currently done is far from that. My perception of the "development process" is that five percent of the developers sprinkle bleeding edge stuff all over the code, twenty percent try to work around them because they have to use non-conforming compilers and the rest struggles to keep up. This is far, far from efficient. There are quite a few thing I'd like to improve on lyx, I'd like to have full xfig support, "native" inclusion of .gif and .tiff, a decent file format and things like that. I have downloaded the latest CVS tree about two dozen times now, even started a bit of coding now and then - of course after a round of installing new stuff (be it a new autoconfig or a new compiler) most of the time. But I usually get fed up after a couple of hours since the sources are in a really pitiful state. Implementation of a single function is usually spread over half a dozen files, each written in a complete different coding style, internal interfaces and the GUI is a mess,... (etc ad nauseam). If you'd ask me (And I'm pretty sure, you won't ;-| ): Make a single stable release and start over from scratch. The *last* step would be to add compatibility to the existent LyX. I always thought that's what was intented with the old 1.1 branch? flame off And no, I won't stop using LyX, because it does a pretty good job for the things I need to do: write texts with math. But I won't stop complaining either since I don't like to see valuable resources (the developer's - i.e. YOUR! - work) wasted. Andre' PS: It's Friday, you know ;-) -- Andre' Poenitz, TU Chemnitz, Fakultaet fuer Mathematik [EMAIL PROTECTED] ... +49 3727 58 1381
Re: Some compilation problems with latest cvs
> Lars> And gcc 2.8.1 shows again that it is not suited for serious C++ > Lars> development... > > Somehow I knew you would say that :) Me too. Using bleeding edge features is *not* "serious C++ development". Serious C++ development is about modularization, lean interfaces, design of re-usable code and stuff like that. Hell, you can do "serious C++ development" in any programming language. But what is currently done is far from that. My perception of the "development process" is that five percent of the developers sprinkle bleeding edge stuff all over the code, twenty percent try to work around them because they have to use non-conforming compilers and the rest struggles to keep up. This is far, far from efficient. There are quite a few thing I'd like to improve on lyx, I'd like to have full xfig support, "native" inclusion of .gif and .tiff, a decent file format and things like that. I have downloaded the latest CVS tree about two dozen times now, even started a bit of coding now and then - of course after a round of installing new stuff (be it a new autoconfig or a new compiler) most of the time. But I usually get fed up after a couple of hours since the sources are in a really pitiful state. Implementation of a single function is usually spread over half a dozen files, each written in a complete different coding style, internal interfaces and the GUI is a mess,... (etc ad nauseam). If you'd ask me (And I'm pretty sure, you won't ;-| ): Make a single stable release and start over from scratch. The *last* step would be to add compatibility to the existent LyX. I always thought that's what was intented with the old 1.1 branch? And no, I won't stop using LyX, because it does a pretty good job for the things I need to do: write texts with math. But I won't stop complaining either since I don't like to see valuable resources (the developer's - i.e. YOUR! - work) wasted. Andre' PS: It's Friday, you know ;-) -- Andre' Poenitz, TU Chemnitz, Fakultaet fuer Mathematik [EMAIL PROTECTED] ... +49 3727 58 1381
Re: Some compilation problems with latest cvs
John Weiss [EMAIL PROTECTED] writes:
| I'm sure there are other features that haven't made it into every
| compiler yet. There are things which you can safely assume are now in
| every C++ compiler currently in use. There are other things, features
| only recently agreed upon by the ANSI committee, that haven't made
| their way in.
Ah you mean "recently" as in "at least two years ago". :-)
| The best bet: ask folks on the list to take a code stub and see if it
| compiles on their platform. That should give us all a pretty good
| idea whether a Really Kewl New C++ feature is widely supported or not.
The problem we will get more and more are compilers that begin to put
all of the standard library into the correct namespaces. Then some
compilers will require the std:: prefix and other will accept it, and
yet others that will not compile with it.
Program that I'd like to have tested:
(checks for anon namespaces in global/file scope)
foo.C:
namespace {
int foo(int i) {
return i+i*i;
}
}
int main(int, char**) {
int a = foo(5);
}
It this works on most/all compilers we can get rid of some depreciated
features that we use (e.g. static functions)
I know this works with egcs and gcc 2.95 so no need to test those.
Lgb
Re: Some compilation problems with latest cvs
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Program that I'd like to have tested: (checks for anon Lars namespaces in global/file scope) Digital cxx 6.1: works (in all modes) Sun CC 4.2 (oldish, from 1996): does not work gcc 2.8.1: does not work; error message is "sorry, not implemented: namespace" :) JMarc
Re: Some compilation problems with latest cvs
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: | | Lars Program that I'd like to have tested: (checks for anon | Lars namespaces in global/file scope) | | Digital cxx 6.1: works (in all modes) Ok...so cxx is not too bad... | Sun CC 4.2 (oldish, from 1996): does not work Has Sun come with a newer C++ compiler since then? | gcc 2.8.1: does not work; error message is "sorry, not implemented: |namespace" :) And gcc 2.8.1 shows again that it is not suited for serious C++ development... Lgb
Re: Some compilation problems with latest cvs
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | Lars "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: | | Lars Lars Program that I'd like to have tested: (checks for anon | Lars Lars namespaces in global/file scope) | | Digital cxx 6.1: Lars works (in all modes) Lars Ok...so cxx is not too bad... Isn't it? Lars | Sun CC 4.2 (oldish, from 1996): does not work Lars Has Sun come with a newer C++ compiler since then? Yes, there is a version 5.0, but I do not have access to it. Lars | gcc 2.8.1: does not work; error message is "sorry, not Lars implemented: | namespace" :) Lars And gcc 2.8.1 shows again that it is not suited for serious C++ Lars development... Somehow I knew you would say that :) JMarc
Re: Some compilation problems with latest cvs
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: | | Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | | Lars "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: | | | Lars Lars Program that I'd like to have tested: (checks for anon | | Lars Lars namespaces in global/file scope) | | Digital cxx 6.1: | Lars works (in all modes) | | Lars Ok...so cxx is not too bad... | | Isn't it? Let's run some more tests on it. What does LyX' configure say about template support on cxx? What about mutable? Ad. the include issue...many compiler have problems with this and gcc's solution is just a hack until they begin requiring the std:: namespace. | Lars | gcc 2.8.1: does not work; error message is "sorry, not | Lars implemented: | namespace" :) | | Lars And gcc 2.8.1 shows again that it is not suited for serious C++ | Lars development... | | Somehow I knew you would say that :) My standard answer when it comes to 2.8.1 :-) Lgb
Re: Some compilation problems with latest cvs
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars What does LyX' configure say about template support on cxx? What Lars about mutable? checking if C++ compiler supports mutable... yes checking if C++ compiler supports partial specialization... yes checking whether the C++ compiler understands explicit... yes checking for broken STL stack template... yes checking for std/bastring.h... no checking for correct namespaces support... yes checking for C headers wrappers... no checking whether the C++ compiler supports RTTI... yes Note that the stack test is bogus, since it uses stack instead of std::stack. The C header wrappers thing is something I intend to commit when I have access to cvs. JMarc
Re: Some compilation problems with latest cvs
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: | | Lars What does LyX' configure say about template support on cxx? What | Lars about mutable? | | checking if C++ compiler supports mutable... yes | checking if C++ compiler supports partial specialization... yes | checking whether the C++ compiler understands explicit... yes | checking for broken STL stack template... yes | checking for std/bastring.h... no | checking for correct namespaces support... yes | checking for C headers wrappers... no | checking whether the C++ compiler supports RTTI... yes This seems quite good actually. We need to fix the check for std::string it is not good. I am not sure what we should have it do instead. Of course if we had a unit test for our lyxstring we could use that to test if the std::string has the needed methods and behaviour :-) | Note that the stack test is bogus, since it uses stack instead of | std::stack. Test if std:: is allowed first? and then depending use stack or std::stack | The C header wrappers thing is something I intend to commit when | I have access to cvs. You have access to cvs. Lgb
Re: Some compilation problems with latest cvs
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars We need to fix the check for std::string it is not good. I am Lars not sure what we should have it do instead. I do not know either... Lars Test if std:: is allowed first? and then depending use stack or Lars std::stack Another idea is to test whether using works first. I suspect that some compilers which do not support namespaces have using as a no-op. Lars | The C header wrappers thing is something I intend to commit Lars when | I have access to cvs. Lars You have access to cvs. No, because I (still) rely on rsh. JMarc
Re: Some compilation problems with latest cvs
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: | | Lars We need to fix the check for std::string it is not good. I am | Lars not sure what we should have it do instead. | | I do not know either... | | Lars Test if std:: is allowed first? and then depending use stack or | Lars std::stack | | Another idea is to test whether using works first. I suspect that | some compilers which do not support namespaces have using as a no-op. That is what I mean by the test for std:: was just a bit vague. And some compilers that supports namespaces have std:: as a no op, they allow it but does not act on it...so you can mix std::stack and stack freely. (egcs, gcc 2.95) | Lars | The C header wrappers thing is something I intend to commit | Lars when | I have access to cvs. | | Lars You have access to cvs. | | No, because I (still) rely on rsh. And? The cvs repository on aussie is the same as on baywatch...ok you have a problem with the repository named in CVS/ ok lets have reboot of baywatch and see if that fixes the problem. Lgb
Re: Some compilation problems with latest cvs
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars And? The cvs repository on aussie is the same as on Lars baywatch...ok you have a problem with the repository named in Lars CVS/ ok lets have reboot of baywatch and see if that fixes the Lars problem. OK, I did not know that aussie was a cvs server too. BTW, if I were to install ssh (just client, I guess), what version should I use? I am a bit lost. JMarc
Re: Some compilation problems with latest cvs
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: | | Lars And? The cvs repository on aussie is the same as on | Lars baywatch...ok you have a problem with the repository named in | Lars CVS/ ok lets have reboot of baywatch and see if that fixes the | Lars problem. | | OK, I did not know that aussie was a cvs server too. | | BTW, if I were to install ssh (just client, I guess), what version | should I use? I am a bit lost. Use the newst 2.x Anyway aussie and baywatch should be able to handle both 1.x and 2.x versions of ssh. Lgb
Re: Some compilation problems with latest cvs
John Weiss <[EMAIL PROTECTED]> writes:
| I'm sure there are other features that haven't made it into every
| compiler yet. There are things which you can safely assume are now in
| every C++ compiler currently in use. There are other things, features
| only recently agreed upon by the ANSI committee, that haven't made
| their way in.
Ah you mean "recently" as in "at least two years ago". :-)
| The best bet: ask folks on the list to take a code stub and see if it
| compiles on their platform. That should give us all a pretty good
| idea whether a Really Kewl New C++ feature is widely supported or not.
The problem we will get more and more are compilers that begin to put
all of the standard library into the correct namespaces. Then some
compilers will require the std:: prefix and other will accept it, and
yet others that will not compile with it.
Program that I'd like to have tested:
(checks for anon namespaces in global/file scope)
foo.C:
namespace {
int foo(int i) {
return i+i*i;
}
}
int main(int, char**) {
int a = foo(5);
}
It this works on most/all compilers we can get rid of some depreciated
features that we use (e.g. static functions)
I know this works with egcs and gcc 2.95 so no need to test those.
Lgb
Re: Some compilation problems with latest cvs
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Program that I'd like to have tested: (checks for anon Lars> namespaces in global/file scope) Digital cxx 6.1: works (in all modes) Sun CC 4.2 (oldish, from 1996): does not work gcc 2.8.1: does not work; error message is "sorry, not implemented: namespace" :) JMarc
Re: Some compilation problems with latest cvs
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> Program that I'd like to have tested: (checks for anon | Lars> namespaces in global/file scope) | | Digital cxx 6.1: works (in all modes) Ok...so cxx is not too bad... | Sun CC 4.2 (oldish, from 1996): does not work Has Sun come with a newer C++ compiler since then? | gcc 2.8.1: does not work; error message is "sorry, not implemented: |namespace" :) And gcc 2.8.1 shows again that it is not suited for serious C++ development... Lgb
Re: Some compilation problems with latest cvs
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | Lars> > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> Lars> Program that I'd like to have tested: (checks for anon | Lars> Lars> namespaces in global/file scope) | | Digital cxx 6.1: Lars> works (in all modes) Lars> Ok...so cxx is not too bad... Isn't it? Lars> | Sun CC 4.2 (oldish, from 1996): does not work Lars> Has Sun come with a newer C++ compiler since then? Yes, there is a version 5.0, but I do not have access to it. Lars> | gcc 2.8.1: does not work; error message is "sorry, not Lars> implemented: | namespace" :) Lars> And gcc 2.8.1 shows again that it is not suited for serious C++ Lars> development... Somehow I knew you would say that :) JMarc
Re: Some compilation problems with latest cvs
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | | Lars> > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | | Lars> Lars> Program that I'd like to have tested: (checks for anon | | Lars> Lars> namespaces in global/file scope) | | Digital cxx 6.1: | Lars> works (in all modes) | | Lars> Ok...so cxx is not too bad... | | Isn't it? Let's run some more tests on it. What does LyX' configure say about template support on cxx? What about mutable? Ad. the include issue...many compiler have problems with this and gcc's solution is just a hack until they begin requiring the std:: namespace. | Lars> | gcc 2.8.1: does not work; error message is "sorry, not | Lars> implemented: | namespace" :) | | Lars> And gcc 2.8.1 shows again that it is not suited for serious C++ | Lars> development... | | Somehow I knew you would say that :) My standard answer when it comes to 2.8.1 :-) Lgb
Re: Some compilation problems with latest cvs
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> What does LyX' configure say about template support on cxx? What Lars> about mutable? checking if C++ compiler supports mutable... yes checking if C++ compiler supports partial specialization... yes checking whether the C++ compiler understands explicit... yes checking for broken STL stack template... yes checking for std/bastring.h... no checking for correct namespaces support... yes checking for C headers wrappers... no checking whether the C++ compiler supports RTTI... yes Note that the stack test is bogus, since it uses stack instead of std::stack. The C header wrappers thing is something I intend to commit when I have access to cvs. JMarc
Re: Some compilation problems with latest cvs
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> What does LyX' configure say about template support on cxx? What | Lars> about mutable? | | checking if C++ compiler supports mutable... yes | checking if C++ compiler supports partial specialization... yes | checking whether the C++ compiler understands explicit... yes | checking for broken STL stack template... yes | checking for std/bastring.h... no | checking for correct namespaces support... yes | checking for C headers wrappers... no | checking whether the C++ compiler supports RTTI... yes This seems quite good actually. We need to fix the check for std::string it is not good. I am not sure what we should have it do instead. Of course if we had a unit test for our lyxstring we could use that to test if the std::string has the needed methods and behaviour :-) | Note that the stack test is bogus, since it uses stack instead of | std::stack. Test if std:: is allowed first? and then depending use stack or std::stack | The C header wrappers thing is something I intend to commit when | I have access to cvs. You have access to cvs. Lgb
Re: Some compilation problems with latest cvs
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> We need to fix the check for std::string it is not good. I am Lars> not sure what we should have it do instead. I do not know either... Lars> Test if std:: is allowed first? and then depending use stack or Lars> std::stack Another idea is to test whether using works first. I suspect that some compilers which do not support namespaces have using as a no-op. Lars> | The C header wrappers thing is something I intend to commit Lars> when | I have access to cvs. Lars> You have access to cvs. No, because I (still) rely on rsh. JMarc
Re: Some compilation problems with latest cvs
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> We need to fix the check for std::string it is not good. I am | Lars> not sure what we should have it do instead. | | I do not know either... | | Lars> Test if std:: is allowed first? and then depending use stack or | Lars> std::stack | | Another idea is to test whether using works first. I suspect that | some compilers which do not support namespaces have using as a no-op. That is what I mean by the test for std:: was just a bit vague. And some compilers that supports namespaces have std:: as a no op, they allow it but does not act on it...so you can mix std::stack and stack freely. (egcs, gcc 2.95) | Lars> | The C header wrappers thing is something I intend to commit | Lars> when | I have access to cvs. | | Lars> You have access to cvs. | | No, because I (still) rely on rsh. And? The cvs repository on aussie is the same as on baywatch...ok you have a problem with the repository named in CVS/ ok lets have reboot of baywatch and see if that fixes the problem. Lgb
Re: Some compilation problems with latest cvs
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> And? The cvs repository on aussie is the same as on Lars> baywatch...ok you have a problem with the repository named in Lars> CVS/ ok lets have reboot of baywatch and see if that fixes the Lars> problem. OK, I did not know that aussie was a cvs server too. BTW, if I were to install ssh (just client, I guess), what version should I use? I am a bit lost. JMarc
Re: Some compilation problems with latest cvs
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> And? The cvs repository on aussie is the same as on | Lars> baywatch...ok you have a problem with the repository named in | Lars> CVS/ ok lets have reboot of baywatch and see if that fixes the | Lars> problem. | | OK, I did not know that aussie was a cvs server too. | | BTW, if I were to install ssh (just client, I guess), what version | should I use? I am a bit lost. Use the newst 2.x Anyway aussie and baywatch should be able to handle both 1.x and 2.x versions of ssh. Lgb
Re: Some compilation problems with latest cvs
John Weiss [EMAIL PROTECTED] writes: | In any case, the almost all of the compilers will be ANSI in another | two years (so I'm told). So, in the meantime, we'll need to add | workarounds for not-so-widely supported C++ features. They'll go away | by 1.4 anyhow. This I have already acknowledged, but we should already now begin to ditch compilers that are not moving in the right direction. No point in supporting gcc 2.7.2.x f.ex. Workarounds fro compiler lacking in support for member templates or partial spesialiation os ok, workarounds for compilers that does not understand templates at all is not. Lgb
Re: Some compilation problems with latest cvs
On Wed, Oct 13, 1999 at 02:04:22PM +0200, Lars Gullik Bjønnes wrote: Workarounds fro compiler lacking in support for member templates or partial spesialiation os ok, workarounds for compilers that does not understand templates at all is not. Agreed. All I wanted to do, Lars, is let you know what I'm seeing in the field, based on my experience with 3 Unix OS' that aren't Linux. What we run into at work w.r.t. C++ compilers: Templates --- present Exception (hand-made) --- present Exceptions (built-in) --- present, but inconsistent from platform to platform. The New Casting Mechanism --- *mostly* present. Namespaces --- not on all platforms. RTTI --- don't know/haven't asked. I'm sure there are other features that haven't made it into every compiler yet. There are things which you can safely assume are now in every C++ compiler currently in use. There are other things, features only recently agreed upon by the ANSI committee, that haven't made their way in. The best bet: ask folks on the list to take a code stub and see if it compiles on their platform. That should give us all a pretty good idea whether a Really Kewl New C++ feature is widely supported or not. -- John Weiss
Re: Some compilation problems with latest cvs
John Weiss <[EMAIL PROTECTED]> writes: | In any case, the almost all of the compilers will be ANSI in another | two years (so I'm told). So, in the meantime, we'll need to add | workarounds for not-so-widely supported C++ features. They'll go away | by 1.4 anyhow. This I have already acknowledged, but we should already now begin to ditch compilers that are not moving in the right direction. No point in supporting gcc 2.7.2.x f.ex. Workarounds fro compiler lacking in support for member templates or partial spesialiation os ok, workarounds for compilers that does not understand templates at all is not. Lgb
Re: Some compilation problems with latest cvs
On Wed, Oct 13, 1999 at 02:04:22PM +0200, Lars Gullik Bjønnes wrote: > > Workarounds fro compiler lacking in support for member templates or > partial spesialiation os ok, workarounds for compilers that does not > understand templates at all is not. Agreed. All I wanted to do, Lars, is let you know what I'm seeing in the field, based on my experience with 3 Unix OS' that aren't Linux. What we run into at work w.r.t. C++ compilers: Templates ---> present Exception (hand-made) ---> present Exceptions (built-in) ---> present, but inconsistent from platform to platform. The New Casting Mechanism ---> *mostly* present. Namespaces ---> not on all platforms. RTTI ---> don't know/haven't asked. I'm sure there are other features that haven't made it into every compiler yet. There are things which you can safely assume are now in every C++ compiler currently in use. There are other things, features only recently agreed upon by the ANSI committee, that haven't made their way in. The best bet: ask folks on the list to take a code stub and see if it compiles on their platform. That should give us all a pretty good idea whether a Really Kewl New C++ feature is widely supported or not. -- John Weiss
Re: Some compilation problems with latest cvs
On 10-Oct-99 Lars Gullik Bjønnes wrote: [Stuff about the joys of using clean ANSI C++ constructs omitted...] I understand what you're saying, Lars, and at one level I agree. But on the other hand, if all of your spare-time work doesn't get used by more than a handful of people, won't the fun kind of go out of it at some point? So how long did yo uwait until you began to write ANSI C? If admins to not update their C++ compilers to more uptodate ones they obviously does not want C++ programs to be developed or compiled on their systems. Should we only support platforms/users/developers that uses old non ANSI C++ compilers? Where is the C++ community going? Why is movement to ANSI C++ this slow? (read the above qouted answer for the answer to the last question) Remember that the Fortran 90 standard (which is superior in every way that I can think of to the F77 standard) has been out for nearly ten years, and it still isn't particularly easy to find systems that have added an F90 compiler in addition to an F77 compiler. If the move to ANSI C++ is as slow (and remember the -standard- took close to ten years to develop), then writing in ANSI C++ now is not a good thing in terms of portability. I hope that most vendors will be prompt, but I'm not betting on it to the extent of updating my 45000+ lines of publicly-distributed unstrucured mesh generation code to require ANSI C++ compilers. This whole discussion has the flavor of a religious war, and I hope I haven't just poured gasoline on the flames Carl Carl Ollivier-Gooch Voice: +1-604-822-1854 Assistant Professor Fax: +1-604-822-2403 Department of Mechanical Engineering email: [EMAIL PROTECTED] University of British Columbia http://www.mech.ubc.ca/~cfog Vancouver, BC V6T 1Z4 http://tetra.mech.ubc.ca/ANSLab
Re: Some compilation problems with latest cvs
Carl Ollivier-Gooch [EMAIL PROTECTED] writes: | On 10-Oct-99 Lars Gullik Bjønnes wrote: | | [Stuff about the joys of using clean ANSI C++ constructs omitted...] | | I understand what you're saying, Lars, and at one level I agree. But on | the other hand, if all of your spare-time work doesn't get used by more | than a handful of people, won't the fun kind of go out of it at some point? Yes this is true...but I really do not believe this to be the case. Close to conformant compilers exists for all major opertating systems, and AFAIK there are much work going on to make support even better. As to our LyX' main "users os": Linux, the compiler is getting there fairly quick. Gcc 2.95 supports close to everything in the standard (except "export"), but has still some problems with the Standard Library, but that is beeing worked hard on. Tell an OS vendor that "your C++ compiler is bad/old/antiquated" enough times and I bet that the vendor will provide a new one fairly soon. And who can push the compiler/os vendors to produce compilers that conform to the ANSI C++ standard except developers? Lgb
Re: Some compilation problems with latest cvs
On Tue, Oct 12, 1999 at 05:27:10PM +0200, Lars Gullik Bjønnes wrote: Okay --- first, most of my antecdote comes from my frustration with one app in particular. I'd love to use it and offer debugging help to the authors... but I can never manage to get the bloody thing to compile. And, yes, I, too, understand that one codes Open Source for the sheer pleasure of it. I am, however, trying to get you to realize something, Lars... Yes this is true...but I really do not believe this to be the case. Close to conformant compilers exists for all major opertating systems, and AFAIK there are much work going on to make support even better. But it's not there *yet*. Yes, it will be, but it's not. At work we support 3 unix platforms, none of which have a fully-compliant ANSI-C++ compiler. I often chat about this with the guy in charge of platform-level aspects of our software. The picture ain't as rosy as you paint it. Tell an OS vendor that "your C++ compiler is bad/old/antiquated" enough times and I bet that the vendor will provide a new one fairly soon. Nope. They'll tell you that they're working on it, that you need to be patient. We've actually found bugs in the C++ compilers at work. Again, Lars, the picture is not nearly as rosy as you paint it. As far as gcc/egcs is concerned, I agree that they are approaching full ANSI compliance very quickly. When they reach it, I will certainly upgrade the compilers on my Linux box. In other environments, however, upgrading the local version of gcc may not be that high priority. This is where the problem hits. Back when I was the only devvie making Solaris 2.5 binaries for LyX, I was compiling on the machines I used for my graduate research. I doubt many of us have Solaris/SGI/HPUX/AIX machines sitting in our basements. How many of the LyX Team who build non-Linux binaries also have root access on the machine they're using to compile LyX? If the answer is, "Not Many," then there are a lot of people who'll need to build install the latest-and-greatest-gcc locally just so that they can compile LyX. Unfortunately, I can't be one of them, and I'd hate to lose the use of LyX at work... In any case, the almost all of the compilers will be ANSI in another two years (so I'm told). So, in the meantime, we'll need to add workarounds for not-so-widely supported C++ features. They'll go away by 1.4 anyhow. -- John Weiss
Re: Some compilation problems with latest cvs
On 10-Oct-99 Lars Gullik Bjønnes wrote: [Stuff about the joys of using clean ANSI C++ constructs omitted...] I understand what you're saying, Lars, and at one level I agree. But on the other hand, if all of your spare-time work doesn't get used by more than a handful of people, won't the fun kind of go out of it at some point? > So how long did yo uwait until you began to write ANSI C? > If admins to not update their C++ compilers to more uptodate ones they > obviously does not want C++ programs to be developed or compiled on > their systems. > > Should we only support platforms/users/developers that uses old non > ANSI C++ compilers? Where is the C++ community going? > Why is movement to ANSI C++ this slow? (read the above qouted answer > for the answer to the last question) Remember that the Fortran 90 standard (which is superior in every way that I can think of to the F77 standard) has been out for nearly ten years, and it still isn't particularly easy to find systems that have added an F90 compiler in addition to an F77 compiler. If the move to ANSI C++ is as slow (and remember the -standard- took close to ten years to develop), then writing in ANSI C++ now is not a good thing in terms of portability. I hope that most vendors will be prompt, but I'm not betting on it to the extent of updating my 45000+ lines of publicly-distributed unstrucured mesh generation code to require ANSI C++ compilers. This whole discussion has the flavor of a religious war, and I hope I haven't just poured gasoline on the flames Carl Carl Ollivier-Gooch Voice: +1-604-822-1854 Assistant Professor Fax: +1-604-822-2403 Department of Mechanical Engineering email: [EMAIL PROTECTED] University of British Columbia http://www.mech.ubc.ca/~cfog Vancouver, BC V6T 1Z4 http://tetra.mech.ubc.ca/ANSLab
Re: Some compilation problems with latest cvs
Carl Ollivier-Gooch <[EMAIL PROTECTED]> writes: | On 10-Oct-99 Lars Gullik Bjønnes wrote: | | [Stuff about the joys of using clean ANSI C++ constructs omitted...] | | I understand what you're saying, Lars, and at one level I agree. But on | the other hand, if all of your spare-time work doesn't get used by more | than a handful of people, won't the fun kind of go out of it at some point? Yes this is true...but I really do not believe this to be the case. Close to conformant compilers exists for all major opertating systems, and AFAIK there are much work going on to make support even better. As to our LyX' main "users os": Linux, the compiler is getting there fairly quick. Gcc 2.95 supports close to everything in the standard (except "export"), but has still some problems with the Standard Library, but that is beeing worked hard on. Tell an OS vendor that "your C++ compiler is bad/old/antiquated" enough times and I bet that the vendor will provide a new one fairly soon. And who can push the compiler/os vendors to produce compilers that conform to the ANSI C++ standard except developers? Lgb
Re: Some compilation problems with latest cvs
On Tue, Oct 12, 1999 at 05:27:10PM +0200, Lars Gullik Bjønnes wrote: Okay --- first, most of my antecdote comes from my frustration with one app in particular. I'd love to use it and offer debugging help to the authors... but I can never manage to get the bloody thing to compile. And, yes, I, too, understand that one codes Open Source for the sheer pleasure of it. I am, however, trying to get you to realize something, Lars... > Yes this is true...but I really do not believe this to be the case. > Close to conformant compilers exists for all major opertating systems, > and AFAIK there are much work going on to make support even better. But it's not there *yet*. Yes, it will be, but it's not. At work we support 3 unix platforms, none of which have a fully-compliant ANSI-C++ compiler. I often chat about this with the guy in charge of platform-level aspects of our software. The picture ain't as rosy as you paint it. > Tell an OS vendor that "your C++ compiler is bad/old/antiquated" > enough times and I bet that the vendor will provide a new one fairly > soon. Nope. They'll tell you that they're working on it, that you need to be patient. We've actually found bugs in the C++ compilers at work. Again, Lars, the picture is not nearly as rosy as you paint it. As far as gcc/egcs is concerned, I agree that they are approaching full ANSI compliance very quickly. When they reach it, I will certainly upgrade the compilers on my Linux box. In other environments, however, upgrading the local version of gcc may not be that high priority. This is where the problem hits. Back when I was the only devvie making Solaris 2.5 binaries for LyX, I was compiling on the machines I used for my graduate research. I doubt many of us have Solaris/SGI/HPUX/AIX machines sitting in our basements. How many of the LyX Team who build non-Linux binaries also have root access on the machine they're using to compile LyX? If the answer is, "Not Many," then there are a lot of people who'll need to build & install the latest-and-greatest-gcc locally just so that they can compile LyX. Unfortunately, I can't be one of them, and I'd hate to lose the use of LyX at work... In any case, the almost all of the compilers will be ANSI in another two years (so I'm told). So, in the meantime, we'll need to add workarounds for not-so-widely supported C++ features. They'll go away by 1.4 anyhow. -- John Weiss
Re: Some compilation problems with latest cvs
John Weiss [EMAIL PROTECTED] writes: When I work on LyX I can at least say this: I am not doing this for the benefit of LyX users, I do it because it is fun. _And_ it is not fun writing inferiour C++ knowing that there is a better alternative. It is absolutely possible to do something to support compilers in the progress of moving to ANSI C++, but supporting compilers that don't even try is just plain stupid. | I am very much of the same opinion as Jean-Marc. One of the reasons | I'm even partially involved with LyX is that I only needed to download | two tar files: the source code itself and XForms. Once I had XForms, | all I needed were the source updates. | | When I download source to try out a new program, there are N things | that put me off: We are not speaking of any program, we are speaking of a program developed for fun on the sparetime of the developers. | - I need to download/install multiple libraries that I've never heard | of before and seem to have no use to me otherwise. Bogus point in this discussion. Besides if you want to use the program in question you are expected to have the correct libs. | - It uses the newest, trendiest version of one or more standard | libraries, without regard to how stable those libs are. I do not | appreciate being forced to put the stability of my existing apps at | risk for a new program. Bogus point in this discussion. | - It requires a cutting/bleeding edge compiler. If it's not yet in | widespread use, I see no point in upgrading something. | Furthermore, I may not have root access on certain platforms, thus | preventing me from even being able to upgrade the compiler. So how long did yo uwait until you began to write ANSI C? If admins to not update their C++ compilers to more uptodate ones they obviously does not want C++ programs to be developed or compiled on their systems. Should we only support platforms/users/developers that uses old non ANSI C++ compilers? Where is the C++ community going? Why is movement to ANSI C++ this slow? (read the above qouted answer for the answer to the last question) | I doubt I am the only one who feels this way. I do think that this feeling is misguided. Lgb PS. I am sorry but this discussion really puts me in a lousy mood, but I want it to be fun writing C++ and to me that means ANSI C++. We have a standard help push it.
Re: Some compilation problems with latest cvs
"Lars Gullik Bjønnes" wrote: PS. I am sorry but this discussion really puts me in a lousy mood, but I want it to be fun writing C++ and to me that means ANSI C++. We have a standard help push it. Bravo! My experience is that if it is not fun it either does not get done or gets done poorly. AFAIK LyX-.10 did most of what I needed to do. I upgraded regularly because without testing new and better versions can't make any real progress. I'm just greatful that I don't have to pay $ for the upgrades and, yes, it is fun watching things improve and trying to contribute. Garst
Re: Some compilation problems with latest cvs
John Weiss <[EMAIL PROTECTED]> writes: When I work on LyX I can at least say this: I am not doing this for the benefit of LyX users, I do it because it is fun. _And_ it is not fun writing inferiour C++ knowing that there is a better alternative. It is absolutely possible to do something to support compilers in the progress of moving to ANSI C++, but supporting compilers that don't even try is just plain stupid. | I am very much of the same opinion as Jean-Marc. One of the reasons | I'm even partially involved with LyX is that I only needed to download | two tar files: the source code itself and XForms. Once I had XForms, | all I needed were the source updates. | | When I download source to try out a new program, there are N things | that put me off: We are not speaking of any program, we are speaking of a program developed for fun on the sparetime of the developers. | - I need to download/install multiple libraries that I've never heard | of before and seem to have no use to me otherwise. Bogus point in this discussion. Besides if you want to use the program in question you are expected to have the correct libs. | - It uses the newest, trendiest version of one or more standard | libraries, without regard to how stable those libs are. I do not | appreciate being forced to put the stability of my existing apps at | risk for a new program. Bogus point in this discussion. | - It requires a cutting/bleeding edge compiler. If it's not yet in | widespread use, I see no point in upgrading something. | Furthermore, I may not have root access on certain platforms, thus | preventing me from even being able to upgrade the compiler. So how long did yo uwait until you began to write ANSI C? If admins to not update their C++ compilers to more uptodate ones they obviously does not want C++ programs to be developed or compiled on their systems. Should we only support platforms/users/developers that uses old non ANSI C++ compilers? Where is the C++ community going? Why is movement to ANSI C++ this slow? (read the above qouted answer for the answer to the last question) | I doubt I am the only one who feels this way. I do think that this feeling is misguided. Lgb PS. I am sorry but this discussion really puts me in a lousy mood, but I want it to be fun writing C++ and to me that means ANSI C++. We have a standard help push it.
Re: Some compilation problems with latest cvs
"Lars Gullik Bjønnes" wrote: >> > PS. I am sorry but this discussion really puts me in a lousy mood, but > I want it to be fun writing C++ and to me that means ANSI C++. We have > a standard help push it. Bravo! My experience is that if it is not fun it either does not get done or gets done poorly. AFAIK LyX-.10 did most of what I needed to do. I upgraded regularly because without testing new and better versions can't make any real progress. I'm just greatful that I don't have to pay $ for the upgrades and, yes, it is fun watching things improve and trying to contribute. Garst
Re: Some compilation problems with latest cvs
On Thu, Oct 07, 1999 at 10:20:25AM +0200, Jean-Marc Lasgouttes wrote: "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars There is some differences between folks that are just users and Lars developers. And I don't think that the developers should put Lars restraints on themselves to allow users to compile on their Lars antiquated installations. A compiler which is two years old is not antique, IMO. I understand your concern, but all the question is to know what tradeoff we put between our comfort and actually having users. If I download a program and find out that I will have several programs/libraries to install just to get this program to run (and I am not even sure this program will be useful to me) I will not try it. I am very much of the same opinion as Jean-Marc. One of the reasons I'm even partially involved with LyX is that I only needed to download two tar files: the source code itself and XForms. Once I had XForms, all I needed were the source updates. When I download source to try out a new program, there are N things that put me off: - I need to download/install multiple libraries that I've never heard of before and seem to have no use to me otherwise. - It uses the newest, trendiest version of one or more standard libraries, without regard to how stable those libs are. I do not appreciate being forced to put the stability of my existing apps at risk for a new program. - It requires a cutting/bleeding edge compiler. If it's not yet in widespread use, I see no point in upgrading something. Furthermore, I may not have root access on certain platforms, thus preventing me from even being able to upgrade the compiler. I doubt I am the only one who feels this way. -- John Weiss
Re: Some compilation problems with latest cvs
On Thu, Oct 07, 1999 at 10:20:25AM +0200, Jean-Marc Lasgouttes wrote: > > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: > > Lars> There is some differences between folks that are just users and > Lars> developers. And I don't think that the developers should put > Lars> restraints on themselves to allow users to compile on their > Lars> antiquated installations. > > A compiler which is two years old is not antique, IMO. I understand > your concern, but all the question is to know what tradeoff we put > between our comfort and actually having users. If I download a program > and find out that I will have several programs/libraries to install > just to get this program to run (and I am not even sure this program > will be useful to me) I will not try it. I am very much of the same opinion as Jean-Marc. One of the reasons I'm even partially involved with LyX is that I only needed to download two tar files: the source code itself and XForms. Once I had XForms, all I needed were the source updates. When I download source to try out a new program, there are N things that put me off: - I need to download/install multiple libraries that I've never heard of before and seem to have no use to me otherwise. - It uses the newest, trendiest version of one or more standard libraries, without regard to how stable those libs are. I do not appreciate being forced to put the stability of my existing apps at risk for a new program. - It requires a cutting/bleeding edge compiler. If it's not yet in widespread use, I see no point in upgrading something. Furthermore, I may not have root access on certain platforms, thus preventing me from even being able to upgrade the compiler. I doubt I am the only one who feels this way. -- John Weiss
Re: Some compilation problems with latest cvs
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: |
Lars Agreed. However, compilers are not updated every month at our
Lars site. | And I believe this is the case at many places. The
Lars problem is not to | say that this is wrong or right, but that we
Lars have to cope with it, | as far as we can.
Lars There is some differences between folks that are just users and
Lars developers. And I don't think that the developers should put
Lars restraints on themselves to allow users to compile on their
Lars antiquated installations.
A compiler which is two years old is not antique, IMO. I understand
your concern, but all the question is to know what tradeoff we put
between our comfort and actually having users. If I download a program
and find out that I will have several programs/libraries to install
just to get this program to run (and I am not even sure this program
will be useful to me) I will not try it.
Concerning binaries, they are not a complete answer: only linux people
are used to install binaries without question; and these people in
general have new enough distributions with the right tools. The
problem is rather large sites using other unices and those compilers
which does not follow last month's standard [OK, OK, I now it is a bit
more than last month :)]
Lars I am not quite sure what you mean.
** In a_lyx_Cpp.C:
#include ctype
** in src/cheaders/ctype
//Add appropriate ifdefs there
#include ctype.h
** in configure
if compiler-does-not-have-cheaders ; then
INC="-I${top_srcdir}/src/cheaders $INC"
fi
Does this seem convenient enough?
JMarc
Re: Some compilation problems with latest cvs
** In a_lyx_Cpp.C:
#include ctype
** in src/cheaders/ctype
//Add appropriate ifdefs there
#include ctype.h
** in configure
if compiler-does-not-have-cheaders ; then
INC="-I${top_srcdir}/src/cheaders $INC"
fi
Does this seem convenient enough?
It does to me. Also, we need to handle the namespace problem.
Personally, I still think that using
#include Vector
which corresponds to
#include vector
using std::vector;
is a good solution...
Similarly, we could alternatively use
#include Ctype
and then have the capital-letter include files in a
compatibility section.
I agree with Jean-Marc that we can not just require people to
have a C++ standard compliant compiler. First of all, no such
thing exists. g++ 2.95 is fairly close, but it's arrogant to say
that this particular brand of C++ is what we require.
We have to find the right balance, and that involves programming
a bit defensively sometimes to ensure that more than just one
compiler works.
Fixing ourselves on one compiler is similar to fixing ourselves to one
toolkit. It's not nice to do.
We don't really need all of the C++ standard to implement and
clean up LyX. Yes, we need the STL, but the rest of the C++
standard library we can not require. Especially since much
of the C++ standard library is not even available with g++.
So, let's try to stick to what we need and as time progresses,
we can start to use more and more. But it would be a mistake
to just use all of it now simply because g++ supports it.
Greets,
Asger
Re: Some compilation problems with latest cvs
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Could you try changing all the std:: to STD:: or LYXSTD:: and Lars then have a Lars #ifdef NEED_STD #define LYXSTD std #else #define LYXSTD #endif Would a #ifdef NEED_STD #define LYXSTD std:: #else #define LYXSTD #endif Be OK with you? We could also call it _std_ to be less intrusive. However, I agree with Asger that we should use 'using std::foo' when necessary, since we are careful enough to avoid calling variables `iostream' or `vector'... JMarc
Re: Some compilation problems with latest cvs
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| A compiler which is two years old is not antique, IMO.
A compiler that is several generations old is close to be an antique
no? :-)
Then you will never try new C++ projects.
| Lars I am not quite sure what you mean.
|
| ** In a_lyx_Cpp.C:
|
| #include ctype
|
| ** in src/cheaders/ctype
|
| //Add appropriate ifdefs there
| #include ctype.h
|
| ** in configure
|
| if compiler-does-not-have-cheaders ; then
| INC="-I${top_srcdir}/src/cheaders $INC"
| fi
|
|
| Does this seem convenient enough?
No, this is not guarantied to work.
You can never know what the compiler will do to the ctype headers.
But this will still work for a lot of compilers. we could try that.
Lgb
Re: Some compilation problems with latest cvs
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: | | Lars Could you try changing all the std:: to STD:: or LYXSTD:: and | Lars then have a | | Lars #ifdef NEED_STD #define LYXSTD std #else #define LYXSTD #endif | | Would a | #ifdef NEED_STD | #define LYXSTD std:: | #else | #define LYXSTD | #endif | | Be OK with you? We could also call it _std_ to be less intrusive. | | However, I agree with Asger that we should use 'using std::foo' when | necessary, since we are careful enough to avoid calling variables | `iostream' or `vector'... Library header files should not put any "using" declarations into effect. So debugstream should use std:: to get to the correct namespace. Lgb
Re: Some compilation problems with latest cvs
Asger #include Vector Asger which corresponds to Asger #include vector using std::vector; Asger is a good solution... How standard is that? I do not have such header here... Oh, it's absolutely not standard. The intent was that *we* provide the Vector file, and implement it such that it corresponds to "#include vector \n using std::vector;" Greets, Asger
Re: Some compilation problems with latest cvs
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: |
Lars> Agreed. However, compilers are not updated every month at our
Lars> site. | And I believe this is the case at many places. The
Lars> problem is not to | say that this is wrong or right, but that we
Lars> have to cope with it, | as far as we can.
Lars> There is some differences between folks that are just users and
Lars> developers. And I don't think that the developers should put
Lars> restraints on themselves to allow users to compile on their
Lars> antiquated installations.
A compiler which is two years old is not antique, IMO. I understand
your concern, but all the question is to know what tradeoff we put
between our comfort and actually having users. If I download a program
and find out that I will have several programs/libraries to install
just to get this program to run (and I am not even sure this program
will be useful to me) I will not try it.
Concerning binaries, they are not a complete answer: only linux people
are used to install binaries without question; and these people in
general have new enough distributions with the right tools. The
problem is rather large sites using other unices and those compilers
which does not follow last month's standard [OK, OK, I now it is a bit
more than last month :)]
Lars> I am not quite sure what you mean.
** In a_lyx_Cpp.C:
#include
** in src/cheaders/ctype
//Add appropriate ifdefs there
#include
** in configure
if compiler-does-not-have-cheaders ; then
INC="-I${top_srcdir}/src/cheaders $INC"
fi
Does this seem convenient enough?
JMarc
Re: Some compilation problems with latest cvs
> ** In a_lyx_Cpp.C:
>
> #include
>
> ** in src/cheaders/ctype
>
> //Add appropriate ifdefs there
> #include
>
> ** in configure
>
> if compiler-does-not-have-cheaders ; then
> INC="-I${top_srcdir}/src/cheaders $INC"
> fi
>
> Does this seem convenient enough?
It does to me. Also, we need to handle the namespace problem.
Personally, I still think that using
#include
which corresponds to
#include
using std::vector;
is a good solution...
Similarly, we could alternatively use
#include
and then have the capital-letter include files in a
compatibility section.
I agree with Jean-Marc that we can not just require people to
have a C++ standard compliant compiler. First of all, no such
thing exists. g++ 2.95 is fairly close, but it's arrogant to say
that this particular brand of C++ is what we require.
We have to find the right balance, and that involves programming
a bit defensively sometimes to ensure that more than just one
compiler works.
Fixing ourselves on one compiler is similar to fixing ourselves to one
toolkit. It's not nice to do.
We don't really need all of the C++ standard to implement and
clean up LyX. Yes, we need the STL, but the rest of the C++
standard library we can not require. Especially since much
of the C++ standard library is not even available with g++.
So, let's try to stick to what we need and as time progresses,
we can start to use more and more. But it would be a mistake
to just use all of it now simply because g++ supports it.
Greets,
Asger
Re: Some compilation problems with latest cvs
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Could you try changing all the std:: to STD:: or LYXSTD:: and Lars> then have a Lars> #ifdef NEED_STD #define LYXSTD std #else #define LYXSTD #endif Would a #ifdef NEED_STD #define LYXSTD std:: #else #define LYXSTD #endif Be OK with you? We could also call it _std_ to be less intrusive. However, I agree with Asger that we should use 'using std::foo' when necessary, since we are careful enough to avoid calling variables `iostream' or `vector'... JMarc
Re: Some compilation problems with latest cvs
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| A compiler which is two years old is not antique, IMO.
A compiler that is several generations old is close to be an antique
no? :-)
Then you will never try new C++ projects.
| Lars> I am not quite sure what you mean.
|
| ** In a_lyx_Cpp.C:
|
| #include
|
| ** in src/cheaders/ctype
|
| //Add appropriate ifdefs there
| #include
|
| ** in configure
|
| if compiler-does-not-have-cheaders ; then
| INC="-I${top_srcdir}/src/cheaders $INC"
| fi
|
|
| Does this seem convenient enough?
No, this is not guarantied to work.
You can never know what the compiler will do to the headers.
But this will still work for a lot of compilers. we could try that.
Lgb
Re: Some compilation problems with latest cvs
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> Could you try changing all the std:: to STD:: or LYXSTD:: and | Lars> then have a | | Lars> #ifdef NEED_STD #define LYXSTD std #else #define LYXSTD #endif | | Would a | #ifdef NEED_STD | #define LYXSTD std:: | #else | #define LYXSTD | #endif | | Be OK with you? We could also call it _std_ to be less intrusive. | | However, I agree with Asger that we should use 'using std::foo' when | necessary, since we are careful enough to avoid calling variables | `iostream' or `vector'... Library header files should not put any "using" declarations into effect. So debugstream should use std:: to get to the correct namespace. Lgb
Re: Some compilation problems with latest cvs
> Asger> #include > > Asger> which corresponds to > > Asger> #include using std::vector; > > Asger> is a good solution... > > How standard is that? I do not have such header here... Oh, it's absolutely not standard. The intent was that *we* provide the Vector file, and implement it such that it corresponds to "#include \n using std::vector;" Greets, Asger
Re: Some compilation problems with latest cvs
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars but not by far... 2.95 is coming along though.
Agreed. However, compilers are not updated every month at our site.
And I believe this is the case at many places. The problem is not to
say that this is wrong or right, but that we have to cope with it,
as far as we can.
Lars the std:: are not really needed on gcc 2.95 or egcs. but they
Lars won't harm either. The reason why I added them is because of SGI
Lars CC which needs them.
Lars Could you try changing all the std:: to STD:: or LYXSTD:: and
Lars then have a
Lars #ifdef NEED_STD #define LYXSTD std #else #define LYXSTD #endif
I'll try something like that.
Lars Yes of course. :-) if we have those headers I'd really like to
Lars use them. Put things into correct namespaces and provides extra
Lars functions to help typesafety.
Lars Wore compilers (like gcc 2.7.x) does not even have fstream or
Lars iostream... fstream.h and iostream.h are not usually
Lars equivlent with them and often uses old
Lars implementations/definitions of streams.
What about the following idea: add a directory src/cheaders containing
the simple versions of these headers for compiler who do not have
them. Then we would just add -I${top_srcdir}/cheaders when necessary.
JMarc
Re: Some compilation problems with latest cvs
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| Agreed. However, compilers are not updated every month at our site.
| And I believe this is the case at many places. The problem is not to
| say that this is wrong or right, but that we have to cope with it,
| as far as we can.
There is some differences between folks that are just users and
developers. And I don't think that the developers should put
restraints on themselves to allow users to compile on their
antiquated installations.
To provide binary distributions that the users can use on the other
hand...
| Lars Could you try changing all the std:: to STD:: or LYXSTD:: and
| Lars then have a
|
| Lars #ifdef NEED_STD #define LYXSTD std #else #define LYXSTD #endif
|
| I'll try something like that.
|
| Lars Yes of course. :-) if we have those headers I'd really like to
| Lars use them. Put things into correct namespaces and provides extra
| Lars functions to help typesafety.
|
| Lars Wore compilers (like gcc 2.7.x) does not even have fstream or
| Lars iostream... fstream.h and iostream.h are not usually
| Lars equivlent with them and often uses old
| Lars implementations/definitions of streams.
|
| What about the following idea: add a directory src/cheaders containing
| the simple versions of these headers for compiler who do not have
| them. Then we would just add -I${top_srcdir}/cheaders when necessary.
I am not quite sure what you mean.
Do you mean that we should have something like
a_lyx_Cpp.C :
#include "lyx_cctype.h"
and then in cheaders:
lyx_cctype.h:
#if HAVE_CCTYPE
#include cctype
#else
#include ctype.h
#endif
???
I'd be reluctantly willing to not use the C++ version of the C headers
for the time beeing... unless there exists an easy solution...
Lgb
Re: Some compilation problems with latest cvs
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> but not by far... 2.95 is coming along though.
Agreed. However, compilers are not updated every month at our site.
And I believe this is the case at many places. The problem is not to
say that this is wrong or right, but that we have to cope with it,
as far as we can.
Lars> the std:: are not really needed on gcc 2.95 or egcs. but they
Lars> won't harm either. The reason why I added them is because of SGI
Lars> CC which needs them.
Lars> Could you try changing all the std:: to STD:: or LYXSTD:: and
Lars> then have a
Lars> #ifdef NEED_STD #define LYXSTD std #else #define LYXSTD #endif
I'll try something like that.
Lars> Yes of course. :-) if we have those headers I'd really like to
Lars> use them. Put things into correct namespaces and provides extra
Lars> functions to help typesafety.
Lars> Wore compilers (like gcc 2.7.x) does not even have or
Lars> ... and are not usually
Lars> equivlent with them and often uses old
Lars> implementations/definitions of streams.
What about the following idea: add a directory src/cheaders containing
the simple versions of these headers for compiler who do not have
them. Then we would just add -I${top_srcdir}/cheaders when necessary.
JMarc
Re: Some compilation problems with latest cvs
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| Agreed. However, compilers are not updated every month at our site.
| And I believe this is the case at many places. The problem is not to
| say that this is wrong or right, but that we have to cope with it,
| as far as we can.
There is some differences between folks that are just users and
developers. And I don't think that the developers should put
restraints on themselves to allow users to compile on their
antiquated installations.
To provide binary distributions that the users can use on the other
hand...
| Lars> Could you try changing all the std:: to STD:: or LYXSTD:: and
| Lars> then have a
|
| Lars> #ifdef NEED_STD #define LYXSTD std #else #define LYXSTD #endif
|
| I'll try something like that.
|
| Lars> Yes of course. :-) if we have those headers I'd really like to
| Lars> use them. Put things into correct namespaces and provides extra
| Lars> functions to help typesafety.
|
| Lars> Wore compilers (like gcc 2.7.x) does not even have or
| Lars> ... and are not usually
| Lars> equivlent with them and often uses old
| Lars> implementations/definitions of streams.
|
| What about the following idea: add a directory src/cheaders containing
| the simple versions of these headers for compiler who do not have
| them. Then we would just add -I${top_srcdir}/cheaders when necessary.
I am not quite sure what you mean.
Do you mean that we should have something like
a_lyx_Cpp.C :
#include "lyx_cctype.h"
and then in cheaders:
lyx_cctype.h:
#if HAVE_CCTYPE
#include
#else
#include
#endif
???
I'd be reluctantly willing to not use the C++ version of the C headers
for the time beeing... unless there exists an easy solution...
Lgb
Re: Some compilation problems with latest cvs
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| Hello,
|
| I have been trying various compilers with the latest debugstream
| branch in cvs. Nothing succeded yet, but there is still hope. Here are
| the problems I encountered:
|
| - with gcc 2.8.1, I get:
wrt regard to 2.8.1 C++ wise it sucks.
| I know that Lars will tell me that anybody using gcc 2.8.1 deserves
| this, but this will not help me much :( Removing std:: in
| class DebugStream : public std::ostream {
| helps me immensely, but I am not sure Lars will accept this mutilation
| of his code...
If you are using a compiler that is more standard conformant than egcs
or gcc 2.95 then the std::'s is needed.
| - when I use DEC cc as C compiler, it triggers the definition of const
| and inline C macros and breaks the C++ compiles. I had to reshuffle
| the configure tests to get it right.
So DEC is not a compiler that we should support. We _need_ const and
inline. Why should we try to supprt DEC cc as C compiler anyway? Hmm
ok, gettext needs it.
| - when I use DEC cxx as C++ compiler (a very recent one), it chokes on
| the ctype and friends headers. Do we really need them? It does not
| seem to me that they buy us much. If you are interested, they
| describe why they did not implement that at the url below:
| http://www.unix.digital.com/cplus/docs/rnu.htm#draft_diff_sec
Tell DEC to get their act together. IMO they are way behind on C++
support...
| That's all for now. Let's try with solaris CC.
Note that apart from the use of std:: the DebugStream is mainly
developed on gcc 2.7.3...
Lgb
Re: Some compilation problems with latest cvs
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: |
Lars Hello, | | I have been trying various compilers with the latest
Lars debugstream | branch in cvs. Nothing succeded yet, but there is
Lars still hope. Here are | the problems I encountered: | | - with
Lars gcc 2.8.1, I get:
Lars wrt regard to 2.8.1 C++ wise it sucks.
Before I had this particular problem, I have not been able to find a
case were is was worse than 2.7.x. Therefore, it is better :)
Lars | I know that Lars will tell me that anybody using gcc 2.8.1
Lars deserves | this, but this will not help me much :( Removing
Lars std:: in | class DebugStream : public std::ostream { | helps me
Lars immensely, but I am not sure Lars will accept this mutilation |
Lars of his code...
Lars If you are using a compiler that is more standard conformant
Lars than egcs or gcc 2.95 then the std::'s is needed.
It appears that I need to remove all the std:: which are after a : in
DebugStream.[Ch]. I'll see if I can find a better workaround.
Lars | - when I use DEC cc as C compiler, it triggers the definition
Lars of const | and inline C macros and breaks the C++ compiles. I
Lars had to reshuffle | the configure tests to get it right.
Lars So DEC is not a compiler that we should support. We _need_ const
Lars and inline. Why should we try to supprt DEC cc as C compiler
Lars anyway? Hmm ok, gettext needs it.
The problem is a bad interaction with their C compiler. With a careful
ordering of the tests in configure.in, this works. I'll checkin a fix
later.
Lars | - when I use DEC cxx as C++ compiler (a very recent one), it
Lars chokes on | the ctype and friends headers. Do we really need
Lars them? It does not | seem to me that they buy us much. If you are
Lars interested, they | describe why they did not implement that at
Lars the url below: |
Lars http://www.unix.digital.com/cplus/docs/rnu.htm#draft_diff_sec
Lars Tell DEC to get their act together. IMO they are way behind on
Lars C++ support...
Since the latest DEC C++ and the only Sun CC (4.2) I have both miss
these nifty headers, I wonder why we need them. Do they imply a
simplification of the code? Or is it just that we have the
satisfaction of using ISO C++?
JMarc
Re: Some compilation problems with latest cvs
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
|
| Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: |
| Lars Hello, | | I have been trying various compilers with the latest
| Lars debugstream | branch in cvs. Nothing succeded yet, but there is
| Lars still hope. Here are | the problems I encountered: | | - with
| Lars gcc 2.8.1, I get:
|
| Lars wrt regard to 2.8.1 C++ wise it sucks.
|
| Before I had this particular problem, I have not been able to find a
| case were is was worse than 2.7.x. Therefore, it is better :)
but not by far... 2.95 is coming along though.
| Lars | I know that Lars will tell me that anybody using gcc 2.8.1
| Lars deserves | this, but this will not help me much :( Removing
| Lars std:: in | class DebugStream : public std::ostream { | helps me
| Lars immensely, but I am not sure Lars will accept this mutilation |
| Lars of his code...
|
| Lars If you are using a compiler that is more standard conformant
| Lars than egcs or gcc 2.95 then the std::'s is needed.
|
| It appears that I need to remove all the std:: which are after a : in
| DebugStream.[Ch]. I'll see if I can find a better workaround.
the std:: are not really needed on gcc 2.95 or egcs. but they won't
harm either. The reason why I added them is because of SGI CC which
needs them.
Could you try changing all the std:: to STD:: or LYXSTD:: and then
have a
#ifdef NEED_STD
#define LYXSTD std
#else
#define LYXSTD
#endif
| Lars | - when I use DEC cxx as C++ compiler (a very recent one), it
| Lars chokes on | the ctype and friends headers. Do we really need
| Lars them? It does not | seem to me that they buy us much. If you are
| Lars interested, they | describe why they did not implement that at
| Lars the url below: |
| Lars http://www.unix.digital.com/cplus/docs/rnu.htm#draft_diff_sec
|
| Lars Tell DEC to get their act together. IMO they are way behind on
| Lars C++ support...
|
| Since the latest DEC C++ and the only Sun CC (4.2) I have both miss
| these nifty headers, I wonder why we need them. Do they imply a
| simplification of the code? Or is it just that we have the
| satisfaction of using ISO C++?
Yes of course. :-)
if we have those headers I'd really like to use them. Put things into
correct namespaces and provides extra functions to help typesafety.
Wore compilers (like gcc 2.7.x) does not even have fstream or
iostream... fstream.h and iostream.h are not usually equivlent
with them and often uses old implementations/definitions of streams.
Lgb
Re: Some compilation problems with latest cvs
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| Hello,
|
| I have been trying various compilers with the latest debugstream
| branch in cvs. Nothing succeded yet, but there is still hope. Here are
| the problems I encountered:
|
| - with gcc 2.8.1, I get:
wrt regard to 2.8.1 C++ wise it sucks.
| I know that Lars will tell me that anybody using gcc 2.8.1 deserves
| this, but this will not help me much :( Removing std:: in
| class DebugStream : public std::ostream {
| helps me immensely, but I am not sure Lars will accept this mutilation
| of his code...
If you are using a compiler that is more standard conformant than egcs
or gcc 2.95 then the std::'s is needed.
| - when I use DEC cc as C compiler, it triggers the definition of const
| and inline C macros and breaks the C++ compiles. I had to reshuffle
| the configure tests to get it right.
So DEC is not a compiler that we should support. We _need_ const and
inline. Why should we try to supprt DEC cc as C compiler anyway? Hmm
ok, gettext needs it.
| - when I use DEC cxx as C++ compiler (a very recent one), it chokes on
| the and friends headers. Do we really need them? It does not
| seem to me that they buy us much. If you are interested, they
| describe why they did not implement that at the url below:
| http://www.unix.digital.com/cplus/docs/rnu.htm#draft_diff_sec
Tell DEC to get their act together. IMO they are way behind on C++
support...
| That's all for now. Let's try with solaris CC.
Note that apart from the use of std:: the DebugStream is mainly
developed on gcc 2.7.3...
Lgb
Re: Some compilation problems with latest cvs
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: |
Lars> Hello, | | I have been trying various compilers with the latest
Lars> debugstream | branch in cvs. Nothing succeded yet, but there is
Lars> still hope. Here are | the problems I encountered: | | - with
Lars> gcc 2.8.1, I get:
Lars> wrt regard to 2.8.1 C++ wise it sucks.
Before I had this particular problem, I have not been able to find a
case were is was worse than 2.7.x. Therefore, it is better :)
Lars> | I know that Lars will tell me that anybody using gcc 2.8.1
Lars> deserves | this, but this will not help me much :( Removing
Lars> std:: in | class DebugStream : public std::ostream { | helps me
Lars> immensely, but I am not sure Lars will accept this mutilation |
Lars> of his code...
Lars> If you are using a compiler that is more standard conformant
Lars> than egcs or gcc 2.95 then the std::'s is needed.
It appears that I need to remove all the std:: which are after a : in
DebugStream.[Ch]. I'll see if I can find a better workaround.
Lars> | - when I use DEC cc as C compiler, it triggers the definition
Lars> of const | and inline C macros and breaks the C++ compiles. I
Lars> had to reshuffle | the configure tests to get it right.
Lars> So DEC is not a compiler that we should support. We _need_ const
Lars> and inline. Why should we try to supprt DEC cc as C compiler
Lars> anyway? Hmm ok, gettext needs it.
The problem is a bad interaction with their C compiler. With a careful
ordering of the tests in configure.in, this works. I'll checkin a fix
later.
Lars> | - when I use DEC cxx as C++ compiler (a very recent one), it
Lars> chokes on | the and friends headers. Do we really need
Lars> them? It does not | seem to me that they buy us much. If you are
Lars> interested, they | describe why they did not implement that at
Lars> the url below: |
Lars> http://www.unix.digital.com/cplus/docs/rnu.htm#draft_diff_sec
Lars> Tell DEC to get their act together. IMO they are way behind on
Lars> C++ support...
Since the latest DEC C++ and the only Sun CC (4.2) I have both miss
these nifty headers, I wonder why we need them. Do they imply a
simplification of the code? Or is it just that we have the
satisfaction of using ISO C++?
JMarc
Re: Some compilation problems with latest cvs
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: |
| Lars> Hello, | | I have been trying various compilers with the latest
| Lars> debugstream | branch in cvs. Nothing succeded yet, but there is
| Lars> still hope. Here are | the problems I encountered: | | - with
| Lars> gcc 2.8.1, I get:
|
| Lars> wrt regard to 2.8.1 C++ wise it sucks.
|
| Before I had this particular problem, I have not been able to find a
| case were is was worse than 2.7.x. Therefore, it is better :)
but not by far... 2.95 is coming along though.
| Lars> | I know that Lars will tell me that anybody using gcc 2.8.1
| Lars> deserves | this, but this will not help me much :( Removing
| Lars> std:: in | class DebugStream : public std::ostream { | helps me
| Lars> immensely, but I am not sure Lars will accept this mutilation |
| Lars> of his code...
|
| Lars> If you are using a compiler that is more standard conformant
| Lars> than egcs or gcc 2.95 then the std::'s is needed.
|
| It appears that I need to remove all the std:: which are after a : in
| DebugStream.[Ch]. I'll see if I can find a better workaround.
the std:: are not really needed on gcc 2.95 or egcs. but they won't
harm either. The reason why I added them is because of SGI CC which
needs them.
Could you try changing all the std:: to STD:: or LYXSTD:: and then
have a
#ifdef NEED_STD
#define LYXSTD std
#else
#define LYXSTD
#endif
| Lars> | - when I use DEC cxx as C++ compiler (a very recent one), it
| Lars> chokes on | the and friends headers. Do we really need
| Lars> them? It does not | seem to me that they buy us much. If you are
| Lars> interested, they | describe why they did not implement that at
| Lars> the url below: |
| Lars> http://www.unix.digital.com/cplus/docs/rnu.htm#draft_diff_sec
|
| Lars> Tell DEC to get their act together. IMO they are way behind on
| Lars> C++ support...
|
| Since the latest DEC C++ and the only Sun CC (4.2) I have both miss
| these nifty headers, I wonder why we need them. Do they imply a
| simplification of the code? Or is it just that we have the
| satisfaction of using ISO C++?
Yes of course. :-)
if we have those headers I'd really like to use them. Put things into
correct namespaces and provides extra functions to help typesafety.
Wore compilers (like gcc 2.7.x) does not even have or
... and are not usually equivlent
with them and often uses old implementations/definitions of streams.
Lgb
