> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
Allan> My main concern was identifying whether a test failed because
Allan> the compiler doesn't support "using" or some other thing or if
Allan> it failed because it doesn't have any STL headers. But I know
Allan> of no examples.
OK, so we
On Fri, 19 Mar 1999, Jean-Marc Lasgouttes wrote:
> > "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
>
> Allan> What about testing if even exists? Or testing if
> Allan> exists if doesn't? or if Asger's tests
> Allan> fail testing if we can use instead?
>
> Do you have examples of co
>> Jean-Marc Lasgouttes writes:
>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
#else #include #include #endif
AAN> Yes, this should work.
Lars> No it would not work. and are totally
Lars> different, one is a C++ standard header the other is a C (or
Lars>
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>>> #else #include #include #endif
AAN> Yes, this should work.
Lars> No it would not work. and are totally
Lars> different, one is a C++ standard header the other is a C (or
Lars> POSIX) standard header.
Yes, I came to this co
>> Asger Alstrup Nielsen writes:
>> Can't we simply add a test for working namespaces and then in the
>> code use:
>>
>> #ifdef LYX_WORKING_NAMESPACES #include using
>> std::string; using std::wstring; #include // or whatever
>> other STL headers you want using map;
AAN> Of co
> "Asger" == Asger Alstrup Nielsen <[EMAIL PROTECTED]> writes:
>> It is not too difficult to add a check for this, I guess. It would
>> be nice if you could give me an example of a minimal program that
>> requires 'using' for std::. I could test on strings, but I'd rather
>> have a more ortho
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
Allan> What about testing if even exists? Or testing if
Allan> exists if doesn't? or if Asger's tests
Allan> fail testing if we can use instead?
Do you have examples of compilers where these headers do not exist? Do
you think we'll be
> Can't we simply add a test for working namespaces and then in the code
> use:
>
> #ifdef LYX_WORKING_NAMESPACES
> #include
> using std::string;
> using std::wstring;
> #include // or whatever other STL headers you want
> using map;
Of course, you mean "using std::map;"
I should have checked if there were more emails in the thread before
sending my first response...
On Thu, 18 Mar 1999, Asger Alstrup Nielsen wrote:
> > It is not too difficult to add a check for this, I guess. It would be
> > nice if you could give me an example of a minimal program that
> > re
On Thu, 18 Mar 1999, Asger Alstrup Nielsen wrote:
> > Do we really need these 'using' statements now, except that they are
> > the ANSI way of doing things? Are there compilers that will fail to
> > find string and wstring if std:: is not explicitely given?
>
> Yes, there are compilers that fail
> It is not too difficult to add a check for this, I guess. It would be
> nice if you could give me an example of a minimal program that
> requires 'using' for std::. I could test on strings, but I'd rather
> have a more orthogonal test.
To see if the compiler supports namespace-qualification, tr
> "Asger" == Asger Alstrup Nielsen <[EMAIL PROTECTED]> writes:
>> Do we really need these 'using' statements now, except that they
>> are the ANSI way of doing things? Are there compilers that will
>> fail to find string and wstring if std:: is not explicitely given?
Asger> Yes, there are co
> Do we really need these 'using' statements now, except that they are
> the ANSI way of doing things? Are there compilers that will fail to
> find string and wstring if std:: is not explicitely given?
Yes, there are compilers that fail without it. The case in point is the Visual
C++ compilers v
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
>> Andre'> Nope... but my compiler does not like the 'std::' stuff in
>> Andre'> src/encoding anyway... *sniff*
Asger> Ok, here's a recipe for avoiding "std::" compilation errors.
Asger> I'm not sure we want to follow this, b
> Andre'> Nope... but my compiler does not like the 'std::' stuff in
> Andre'> src/encoding anyway... *sniff*
Ok, here's a recipe for avoiding "std::" compilation errors.
I'm not sure we want to follow this, but in case we decide to
have gcc 2.7.2 support, this is how we could do it:
1. Add "u
> "Andre'" == Andre' Poenitz <[EMAIL PROTECTED]> writes:
>> What is your compiler? What does it say? We are currently trying to
>> fix this area, so any information may be useful. Currently, it
>> works for my with gcc 2.8.1. I do not know for others.
Andre'> gcc 2.7.2.3 - but I am just real
> What is your compiler? What does it say? We are currently trying to
> fix this area, so any information may be useful. Currently, it works
> for my with gcc 2.8.1. I do not know for others.
gcc 2.7.2.3 - but I am just realizing that I have a egcs-2.91.60
on my own machine... so I'll try that la
> "Andre'" == Andre' Poenitz <[EMAIL PROTECTED]> writes:
>> I did a cvs update in lyx/ and it patched various things, but
>> didn't download the whole new src/encoding directory. Anyone know
>> why?
>>
>> -Amir
>>
Andre'> Nope... but my compiler does not like the 'std::' stuff in
Andre'>
>
> I did a cvs update in lyx/ and it patched various things, but didn't
> download the whole new src/encoding directory. Anyone know why?
>
> -Amir
>
Nope... but my compiler does not like the 'std::' stuff
in src/encoding anyway... *sniff*
This probably means I have to get a new compiler?
> "Amir" == Amir Karger <[EMAIL PROTECTED]> writes:
Amir> I did a cvs update in lyx/ and it patched various things, but
Amir> didn't download the whole new src/encoding directory. Anyone
Amir> know why?
My .cvsrc file reads:
diff -u
rdiff -u
update -dP
This means in particular that update
20 matches
Mail list logo
