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
| 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" == 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
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
Jrgen
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jrgen VignaE-Mail: [EMAIL PROTECTED]
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!", excep
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.
Andre Poenitz [EMAIL PROTECTED] writes:
| Would you mind if somebody asked on the users' list what compilers people
| are using?
Certainly not.
Lgb
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
> > exa
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
>
> 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
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
> 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,
> "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
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
> | 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" == 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
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
o
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!&quo
> 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 stuf
Andre Poenitz <[EMAIL PROTECTED]> writes:
| Would you mind if somebody asked on the users' list what compilers people
| are using?
Certainly not.
Lgb
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
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
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
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
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 {
> .
> > 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 na
y 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 compile
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 w
"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
ts 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
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)
> "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
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
lready 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 definin
"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 ostreams we need 15 lines
Lars of | error prone preprocessor stuff, the fun factor will tend to
Lars go low. At | first I thought
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: |
Lars Lars ostream operator(ostream , foo); | | OK, so I
Lars included "debug.h" in places which define these operators. It |
Lars would seem more reasonable to me to define a
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
"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
> "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
> "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
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
> "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
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
) 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
"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
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]
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| For the streams in ostreams, 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
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
.
| 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 cor
> "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::
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
> "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;
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
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
"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 an
> 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
>>>>> "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.
"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
>>>>> "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 proba
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
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 an
101 - 161 of 161 matches
Mail list logo
