> | Is there a practical difference between const int var and int const var ?
> | Consider me dumb :(
>
> Yes :-) Consistency.
>
> extern int const blah; // in the header file
>
> int const blah = 123; // in the source file
OK, gotcha. Thanks.
Kuba
Kuba Ober <[EMAIL PROTECTED]> writes:
>> | What's the general karma of having something like
>> |
>> | const int blah = 123;
>> |
>> | in a header file, inside a namespace (or not)? As far as I take it,
>> | it's a
>>
>> Do we have those in header files?
>> that is not good.
>> and if we had them
> | What's the general karma of having something like
> |
> | const int blah = 123;
> |
> | in a header file, inside a namespace (or not)? As far as I take it,
> | it's a
>
> Do we have those in header files?
> that is not good.
> and if we had them it should be
> int const blah = 123;
> and it wou
Kuba Ober <[EMAIL PROTECTED]> writes:
| Hi,
>
| I was thinking of doing some general const cleanup in the (probably very few)
| places that may need it (if any at all). I'm thinking of it w/o looking at
| the code yet (just downloaded from CVS) so please forgive if it doesn't
| directly apply.
Hi,
I was thinking of doing some general const cleanup in the (probably very few)
places that may need it (if any at all). I'm thinking of it w/o looking at
the code yet (just downloaded from CVS) so please forgive if it doesn't
directly apply.
What's the general karma of having something like
> "Yves" == Yves Bastide <[EMAIL PROTECTED]> writes:
Yves> Here is a second patch for building 1.1.6fix with gcc 3.0. This
Yves> one should be less bad :)
I applied it. Thanks.
JMarc
> "Yves" == Yves Bastide <[EMAIL PROTECTED]> writes:
Yves> Here is a second patch for building 1.1.6fix with gcc 3.0. This
Yves> one should be less bad :)
This looks very good to me. So, unless Lars objects, I'll apply it.
JMarc
Here is a second patch for building 1.1.6fix with gcc 3.0. This one
should be less bad :)
--
Yves
std-try2.patch.gz
On Fri, Jun 08, 2001 at 04:36:10PM +0200, Jean-Marc Lasgouttes wrote:
> > "Yves" == Yves Bastide <[EMAIL PROTECTED]> writes:
>
> Yves> Here's a patch; I finally didn't try to go and test the kde and
> Yves> gnome frontends, since the versions of the libraries I have are
> Yves> themselves to-
> "Yves" == Yves Bastide <[EMAIL PROTECTED]> writes:
Yves> Here's a patch; I finally didn't try to go and test the kde and
Yves> gnome frontends, since the versions of the libraries I have are
Yves> themselves to-be-cleaned.
I do not like much the lstring.h solution... How come the main bran
On 08-Jun-2001 Lars Gullik Bjønnes wrote:
> hmm... autogen.sh should take care of this...
Well I more or less never run ./autogen.sh, I'll try if that helps!
Jürgen
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED
Juergen Vigna <[EMAIL PROTECTED]> writes:
| On 08-Jun-2001 Lars Gullik Bjønnes wrote:
|
| > And the end of the configure script there should be a
| >
| >#ifndef HAVE_LIMITS
| >#define BOOST_NO_LIMITS
| >#endif
| >
| > are you missing that?
|
| Yes I'm missing this one! Shouldn't that be too
On 08-Jun-2001 Lars Gullik Bjønnes wrote:
> And the end of the configure script there should be a
>
>#ifndef HAVE_LIMITS
>#define BOOST_NO_LIMITS
>#endif
>
> are you missing that?
Yes I'm missing this one! Shouldn't that be too in config.h.in? It's missing
there to!
>| One more thing != !!
Juergen Vigna <[EMAIL PROTECTED]> writes:
| On 08-Jun-2001 Lars Gullik Bjønnes wrote:
| > Juergen Vigna <[EMAIL PROTECTED]> writes:
| >
| >| On 08-Jun-2001 Lars Gullik Bjønnes wrote:
| >|
| >| > If your --with-included-string does not work you have to tell the
| >| > errors.
| >|
| >| Well the
On 08-Jun-2001 Lars Gullik Bjønnes wrote:
> Juergen Vigna <[EMAIL PROTECTED]> writes:
>
>| On 08-Jun-2001 Lars Gullik Bjønnes wrote:
>|
>| > If your --with-included-string does not work you have to tell the
>| > errors.
>|
>| Well the errors are easy. LString does not define __BASTRING__ and s
Juergen Vigna <[EMAIL PROTECTED]> writes:
| On 08-Jun-2001 Lars Gullik Bjønnes wrote:
|
| > If your --with-included-string does not work you have to tell the
| > errors.
|
| Well the errors are easy. LString does not define __BASTRING__ and so the
| BOOST_NO_LIMITS is not defined. As I don't ha
On 08-Jun-2001 Lars Gullik Bjønnes wrote:
> If your --with-included-string does not work you have to tell the
> errors.
Well the errors are easy. LString does not define __BASTRING__ and so the
BOOST_NO_LIMITS is not defined. As I don't have a on my RedHat 7.1
system the #include then fails!
Juergen Vigna <[EMAIL PROTECTED]> writes:
| On 07-Jun-2001 Lars Gullik Bjønnes wrote:
|
| > I just fixed that... Jürgen added something to a file that he
| > shouldn't have...
| >
| > I'll commit in a little bit.
|
| Sorry you're right! Hopefully you can fix it for all of us.
If your --with-i
On 07-Jun-2001 Lars Gullik Bjønnes wrote:
> I just fixed that... Jürgen added something to a file that he
> shouldn't have...
>
> I'll commit in a little bit.
Sorry you're right! Hopefully you can fix it for all of us.
Jürgen
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-.
"Garst R. Reese" <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
|
| > devel...
| >
| > and I figure you are taling bout the 1.1.6 branch... ok
| >
| > --
| > Lgb
| Today I get numerous errors in .../boost/detail
I just fixed that... Jürgen added something to a file that he
s
Lars Gullik Bjønnes wrote:
> devel...
>
> and I figure you are taling bout the 1.1.6 branch... ok
>
> --
> Lgb
Today I get numerous errors in .../boost/detail
Here's a sample:
../../boost/boost/detail/limits.hpp:369: redefinition of `class
std::numeric_limits'
/usr/local/lib/gcc-lib
[EMAIL PROTECTED] (Yves Bastide) writes:
| On Thu, Jun 07, 2001 at 07:23:08PM +0200, Lars Gullik Bjønnes wrote:
| > [EMAIL PROTECTED] (Yves Bastide) writes:
| [about patches for gcc 3.0]
| >
| > I wonder why you have to change anything at all... I am compilig with
| > gcc 3.0 all the and have co
On Thu, Jun 07, 2001 at 08:01:38PM +0200, Lars Gullik Bjønnes wrote:
> [EMAIL PROTECTED] (Yves Bastide) writes:
>
> | On Thu, Jun 07, 2001 at 07:23:08PM +0200, Lars Gullik Bjønnes wrote:
> | > [EMAIL PROTECTED] (Yves Bastide) writes:
> | [about patches for gcc 3.0]
> | >
> | > I wonder why you h
On Thu, Jun 07, 2001 at 07:23:08PM +0200, Lars Gullik Bjønnes wrote:
> [EMAIL PROTECTED] (Yves Bastide) writes:
[about patches for gcc 3.0]
>
> I wonder why you have to change anything at all... I am compilig with
> gcc 3.0 all the and have commited all the changes I needed to
> compile...
Are y
[EMAIL PROTECTED] (Yves Bastide) writes:
| On Thu, Jun 07, 2001 at 02:36:17PM +0200, Jean-Marc Lasgouttes wrote:
| > > "Yves" == Yves Bastide <[EMAIL PROTECTED]> writes:
| >
| > Yves> It seems that another number of std:: or using std:: are needed
| > Yves> to compile LyX 1.1.6 with GCC 3.0
On Thu, Jun 07, 2001 at 02:36:17PM +0200, Jean-Marc Lasgouttes wrote:
> > "Yves" == Yves Bastide <[EMAIL PROTECTED]> writes:
>
> Yves> It seems that another number of std:: or using std:: are needed
> Yves> to compile LyX 1.1.6 with GCC 3.0 or other modern compilers.
>
> Yes, a patch to do t
lyxfont { /// static int
Yves> width(char const * s, LyXFont const & f) { - return width(s,
Yves> strlen(s), f); + return width(s, std::strlen(s), f); } ///
Yves> static
Yves> acceptable for older compilers?
It will work for older gcc versions, but not for compaq cxx 6.2, w
[EMAIL PROTECTED] (Yves Bastide) writes:
| It seems that another number of std:: or using std:: are needed to compile
| LyX 1.1.6 with GCC 3.0 or other modern compilers.
|
| I guess that, in .C files, the preferred way is to use
|
| #ifndef CXX_GLOBAL_CSTD
| using std::strlen;
| ...
| #endif
|
It seems that another number of std:: or using std:: are needed to compile
LyX 1.1.6 with GCC 3.0 or other modern compilers.
I guess that, in .C files, the preferred way is to use
#ifndef CXX_GLOBAL_CSTD
using std::strlen;
...
#endif
But what about header files? Is The Right Thing, such as
--
On Thu, Mar 15, 2001 at 07:20:52PM +0100, Lars Gullik Bjønnes wrote:
> What I now need is a poll to see if anonymous namespaces are supported
> on the different platforms.
>
>
> So people please test:
>
>
> namespace {
>
> int foo() { return 1; }
>
>
>>>>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> I am now removing all CXX...NAMESPACES stuff (of course I should
Lars> have let someone with an older compiler do this...), will commit
Lars> that in a few minutes.
Lars> Wh
"Garst R. Reese" <[EMAIL PROTECTED]> writes:
| In math_cursor.C:48 (using std::cerr) I got cerr undefined with
| gcc-3.0
Probably because iostream is not included.
but I changed this to lyxerr.
Lgb
"Garst R. Reese" <[EMAIL PROTECTED]> writes:
| In math_cursor.C:48 (using std::cerr) I got cerr undefined with gcc-3.0
| How std is std?
very.
but we should not use cerr in code, that is taken care of by lyxerr.
Lgb
In math_cursor.C:48 (using std::cerr) I got cerr undefined with gcc-3.0
How std is std?
Garst
On 15-Mar-2001 Lars Gullik Bjønnes wrote:
> So people please test:
It compiles with RedHat7.0 (but you probably already knew:)
Jürgen
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel/F
ribe: <mailto:[EMAIL PROTECTED]>
> Delivered-To: mailing list [EMAIL PROTECTED]
> X-Authentication-Warning: trylle.birdstep.com: larsbj set sender to lyx using -f
> To: [EMAIL PROTECTED]
> Subject: namespaces
> From: [EMAIL PROTECTED] (Lars Gullik Bjønnes)
> Organization: LyX Deve
> What I now need is a poll to see if anonymous namespaces are supported
> on the different platforms.
Supported in 2.95.2.
Andre'
--
André Pönitz [EMAIL PROTECTED]
I am now removing all CXX...NAMESPACES stuff (of course I should have
let someone with an older compiler do this...), will commit that in a
few minutes.
What I now need is a poll to see if anonymous namespaces are supported
on the different platforms.
So people please test:
namespace {
int
On Wednesday 14 March 2001 12:25, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | > This will only make it harder to do the merge...
> |
> | Lars Gullik Bjønnes! You mean it's going to happen? W!
>
> Just give me some hours.
>
> I want to have the compabili
Angus Leeming <[EMAIL PROTECTED]> writes:
| > This will only make it harder to do the merge...
|
| Lars Gullik Bjønnes! You mean it's going to happen? W!
Just give me some hours.
I want to have the compability code for minipages work first. (at
least I now know why it does not work)
I
> This will only make it harder to do the merge...
Lars Gullik Bjønnes! You mean it's going to happen? W!
Are you happy with things as they stand? Shall I make a patch of BRANCH_MVC's
current contents against HEAD and submit it to you?
I can easily undiff the changes I've made in my lo
Angus Leeming <[EMAIL PROTECTED]> writes:
| On Wednesday 14 March 2001 11:02, Jean-Marc Lasgouttes wrote:
| > >>>>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
| >
| > Angus> As Lars says that namespaces are "GO, GO", I'd
On 14 Mar 2001, Lars Gullik Bjønnes wrote:
> Look at the tests already used in configure.
>
> Lgb
*doh*
another moron day for me I think :)
john
(where did I think CXX_WORKING_NAMESPACES came from ? :P )
--
"Never use a big word when a diminutive one would suffice.
Be more or less
On Wednesday 14 March 2001 11:02, Jean-Marc Lasgouttes wrote:
> >>>>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> As Lars says that namespaces are "GO, GO", I'd like to go
> Angus> through the header files (not
John Levon <[EMAIL PROTECTED]> writes:
| On 14 Mar 2001, Jean-Marc Lasgouttes wrote:
|
| > >>>>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
| >
| > Angus> As Lars says that namespaces are "GO, GO", I'd like to go
| >
On 14 Mar 2001, Jean-Marc Lasgouttes wrote:
> >>>>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> As Lars says that namespaces are "GO, GO", I'd like to go
> Angus> through the header files (not
>>>>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> As Lars says that namespaces are "GO, GO", I'd like to go
Angus> through the header files (not the .C files) and remove code
Angus> like:
Angus> #ifdef SIGC_CXX_NAMESPAC
As Lars says that namespaces are "GO, GO", I'd like to go through the header
files (not the .C files) and remove code like:
#ifdef SIGC_CXX_NAMESPACES
using SigC::Object;
#endif
Please object now!
Angus
Andre Poenitz <[EMAIL PROTECTED]> writes:
| Would you mind if somebody asked on the users' list what compilers people
| are using?
Certainly not.
Lgb
> 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::
to
compile the linux kernel ok (or at least the RH gcc 2.96 is). So after
that we should _at least_ be able to use C++ fetures present in gcc
2.95.2/3.
Other vendor's compilers are cathing up (C++ wise) very fast, and we
should just stop supporting older compilers.
For me namespaces is "G
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 PROTECTE
> "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 E
> | 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' ;-)
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
> "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
> If we decide to do so, I can compile with gcc 2.8.1 from
> time to time to check that it still works.
Having namespaces can be really nice... it took me a while to arrive at
this conclusion but I am a convinced "namespacer" by now...
> Andre> In the Linux world, I&#
Andre> certainly get into trouble if we rely on them...
Andre> Question is: What compilers do people use and what features do
Andre> these compilers support?
Basically gcc 2.8.x and egcs 1.0.x do not support namespaces. Dekel
and I used to compile with them, but we have upgraded now. So the
probl
> And if we're still in that interim
>
> #ifdef CXX_HAS_NAMESPACES
> namespace citation
> #endif
Ok... if people use compilers without namespace support we'll certainly get
into trouble if we rely on them...
Question is: What compilers do people use and what features do these
compilers support?
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
> namespace citation {
>
> class ControlCitation : public ControlCommand
Isn't one of the ideas of namespaces that instead of
citation::ControlCitation
citation::GUICitation
one could use shorter names like
citation::Control
citation::Gui
?
Andre'
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
> > 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 t
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 and that I can write (for
example):
namespace frontends {
namespace citation {
...
}
}
?
Angus
> "John" == John Weiss <[EMAIL PROTECTED]> writes:
John> Maybe we should have a subdir with several small sourcelets and
John> a Makefile desiged to test whether or not the compiler supports
John> certain ANSI C++ features yet. We could ask folks to mail in
John> what they find. Then we'll ha
the compilers that the 1.1.x
> | Lars> series currently compiles on?
It would be nice, but somehow I doubt it,
> The pity, is that now we use structs to hack around not using
> namespaces...
Not unusual; we do this where I work.
Hmmm...
Maybe we should have a subdir with several
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 de
d it for now :)
Lars> The pity, is that now we use structs to hack around not using
Lars> namespaces...
Yes, but in the case of sqrt, naming a pixmap like that is stupid,
anyway... I do not really see the advantage of defining LyX::sqrt
instead of LyX_sqrt (or better sqrt_xpm).
JMarc
he pity, is that now we use structs to hack around not using
namespaces...
Lgb
> "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 i
Does namespace support work on all the compilers that the 1.1.x series
currently compiles on?
i.e. does this code compile and run:
namespace LyX {
int small_lyx_function();
}
int LyX::small_lyx_function() {
int i = 0;
i += 3;
return i;
}
int main() {
Ly
> "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
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> 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 defi
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| Lars> ostream & operator<<(ostream &, );
|
| OK, so I included "debug.h" in places which define these operators. It
| would seem more reasonable to me to define a LOStreams.h header (like
| LString.h) which sets up ostreams correctly for our own
> "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 thoug
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
> "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:
| 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
> "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:: dep
eclaration.
| 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 unde
Hello,
I am still in the process of compiling LyX with DEC cxx compiler. It
seems that adding the cfoo headers from GNU libstdc++ gives good
results, but I have problems with namespaces.
The problem: stuff like ostream is used sometimes with std::,
sometimes without. While it might be OK with
>>>>> "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
> 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
On Thu, 8 Apr 1999, Jean-Marc Lasgouttes wrote:
> >>>>> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
>
> Allan> # We still need portability to other platforms of course but we
> Allan> can draw a line and say "it must support namespaces&
>>>>> "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
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
88 matches
Mail list logo
