> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
Peter> Using boost but complaining about a simple template class, I
Peter> still can't understand this. What was soo complicated with
Peter> my solution? Has LyX become a Visual Basic project? It's a
Peter> rhetoric question, no answer
Lars Gullik Bjønnes wrote:
> Peter Kümmel <[EMAIL PROTECTED]> writes:
>
> | Reflecting:
> |
> | So much trouble because of ICONV_CONST.
> |
> | We should have used my initial solution:
> |
> | template
> | struct optional_p2p_const_cast
> | {
> | optional_p2p_const_cast(T const ** p2p) : t_
Peter Kümmel <[EMAIL PROTECTED]> writes:
| Reflecting:
|
| So much trouble because of ICONV_CONST.
|
| We should have used my initial solution:
|
| template
| struct optional_p2p_const_cast
| {
| optional_p2p_const_cast(T const ** p2p) : t_p2p(p2p) {}
| operator T const **() { return t_
Peter Kümmel wrote:
>
> Using boost but complaining about a simple template class,
> I still can't understand this.
> What was soo complicated with my solution? Has LyX
> become a Visual Basic project? It's a rhetoric question,
> no answer is required.
>
> I'm nearly offline (analog modem) fo
Jean-Marc Lasgouttes wrote:
>> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
>
> Peter> Why have we chosen the long way? Changing three build systems
> Peter> producing more than 40 mails, wasting the time several
> Peter> developers.
>
> But at the end the code will be easier to unders
> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
Peter> Why have we chosen the long way? Changing three build systems
Peter> producing more than 40 mails, wasting the time several
Peter> developers.
But at the end the code will be easier to understand. The is the most
important.
JMarc
Reflecting:
So much trouble because of ICONV_CONST.
We should have used my initial solution:
template
struct optional_p2p_const_cast
{
optional_p2p_const_cast(T const ** p2p) : t_p2p(p2p) {}
operator T const **() { return t_p2p; }
operator T **() { return const_cast(t_p2p); }
Lars Gullik Bjønnes wrote:
> Peter Kümmel <[EMAIL PROTECTED]> writes:
>
> | > autoconf/automake already create this macros/define, so it should be
> | > put in the config.h created by scons.
> | >
> |
> | When autoconf already provides this macro then we should use it and
> | test for it with th
Peter Kümmel <[EMAIL PROTECTED]> writes:
| > autoconf/automake already create this macros/define, so it should be
| > put in the config.h created by scons.
| >
|
| When autoconf already provides this macro then we should use it and
| test for it with the other build systems.
Hmm... the buildsys
Lars Gullik Bjønnes wrote:
> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
> | I would personally simply
> | go for an #ifdef in uicode.C for now:
> |
> | /* Define as const if the declaration of iconv() needs const. */
> | #ifdef WIN32
> | #define ICONV_CONST const
> | #else
> | #define IC
>> Good, then I'll try to do the change for scons.
> It seems to be there already:
> (conf.CheckIconvConst(),
> 'ICONV_CONST',
> 'Define as const if the declaration of iconv() needs
> const.',
> '#define ICONV_CONST',
>
Lars Gullik Bjønnes wrote:
/* Define as const if the declaration of iconv() needs const. */
#define ICONV_CONST
char ICONV_CONST * inbuf = const_cast(&buf[0]);
ICONV_CONST will be defined as 'const' when the prototype of iconv
requires const in its first parameter.
I'd prefere this solutio
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| I would personally simply
| go for an #ifdef in uicode.C for now:
| | /* Define as const if the declaration of iconv() needs const. */
| #ifdef WIN32
| #define ICONV_C
Abdelrazak Younes wrote:
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| I would personally simply
| go for an #ifdef in uicode.C for now:
| | /* Define as const if the declaration of iconv() needs const. */
| #ifdef WIN32
| #define ICONV_CONST const
| #else
| #de
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| I would personally simply
| go for an #ifdef in uicode.C for now:
|
| /* Define as const if the declaration of iconv() needs const. */
| #ifdef WIN32
| #define ICONV_CONST const
| #else
| #define ICONV_CONST
| #endi
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| I would personally simply
| go for an #ifdef in uicode.C for now:
|
| /* Define as const if the declaration of iconv() needs const. */
| #ifdef WIN32
| #define ICONV_CONST const
| #else
| #define ICONV_CONST
| #endif
|
| Then, that could be cha
Peter Kümmel <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Peter Kümmel <[EMAIL PROTECTED]> writes:
| >
| > | Peter Kümmel wrote:
| > | > Seems we have to use a ifdef.
| > |
| > | Or we solve it with help of overloading the casting operator:
| >
| > Hmm... I think I'll put that i
Peter Kümmel wrote:
Lars Gullik Bjønnes wrote:
Peter Kümmel <[EMAIL PROTECTED]> writes:
| Peter Kümmel wrote:
| > Seems we have to use a ifdef.
|
| Or we solve it with help of overloading the casting operator:
Hmm... I think I'll put that in the 'quite ugly' category.
Do you really prefer
Lars Gullik Bjønnes wrote:
> Peter Kümmel <[EMAIL PROTECTED]> writes:
>
> | Peter Kümmel wrote:
> | > Seems we have to use a ifdef.
> |
> | Or we solve it with help of overloading the casting operator:
>
> Hmm... I think I'll put that in the 'quite ugly' category.
>
Do you really prefer the co
Peter Kümmel <[EMAIL PROTECTED]> writes:
| Peter Kümmel wrote:
| > Seems we have to use a ifdef.
|
| Or we solve it with help of overloading the casting operator:
Hmm... I think I'll put that in the 'quite ugly' category.
--
Lgb
> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
Peter> Does this mean that we now must always enable nls?
Peter> unicode.C uses iconv.h which until now only was used with nls
Peter> enabled.
No, it is just that now there are to users of iconv: unicode and nls.
So it just means that w
Peter Kümmel wrote:
> Seems we have to use a ifdef.
Or we solve it with help of overloading the casting operator:
Index: src/support/unicode.C
===
--- src/support/unicode.C (revision 14663)
+++ src/support/unicode.C (work
Peter Kümmel <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Peter Kümmel <[EMAIL PROTECTED]> writes:
| >
| > | Index: src/support/unicode.C
| > | ===
| > | --- src/support/unicode.C (revision 14663)
| > | +++ src/
Lars Gullik Bjønnes wrote:
> Peter Kümmel <[EMAIL PROTECTED]> writes:
>
> | Index: src/support/unicode.C
> | ===
> | --- src/support/unicode.C (revision 14663)
> | +++ src/support/unicode.C (working copy)
> | @@ -14,6 +14,
Peter Kümmel <[EMAIL PROTECTED]> writes:
| Index: src/support/unicode.C
| ===
| --- src/support/unicode.C (revision 14663)
| +++ src/support/unicode.C (working copy)
| @@ -14,6 +14,8 @@
|
| #include "unicode.h"
|
| +#in
Lars Gullik Bjønnes wrote:
> | No, I think uint32_t is also defined in the global namespace and
> | that's what gcc uses here. So I guess you'd better explicitly specify
> | boost::.
>
> Hmm... that should only be used if stdint/inttypes has been included
> (and c++ used in C99 compaiblity mode)
Lars Gullik Bjønnes wrote:
> | MSVC tells me that it cannot convert inbuf from "char *" to "const char *"
>
> But that is just bullocks.
>
> Converting non-const to const is always possible, it is the opposite
> that is not ok. You are sure there are not a '**' somewhere in the
> error message?
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | Index: support/unicode.C
| > | ===
| > | --- support/unicode.C (revision 14662)
| > | +++ support/unicode.C (working copy)
| > | @@ -16,6 +16,10 @@
| > | | #include "debug.
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| [EMAIL PROTECTED] wrote:
| > Author: larsbj
| > Date: Mon Aug 14 00:54:59 2006
| > New Revision: 14661
| > URL: http://www.lyx.org/trac/changeset/14661
| > Log:
| > Merge the unicode branch into trunk.
|
| Congratulation
Peter Kümmel wrote:
> [EMAIL PROTECTED] wrote:
>> Author: larsbj
>> Date: Mon Aug 14 00:54:59 2006
>> New Revision: 14661
>>
>> URL: http://www.lyx.org/trac/changeset/14661
>> Log:
>> Merge the unicode branch into trunk.
>>
>> - src/support/unicode.[Ch]: new files with functions for converting
>>
Peter Kümmel <[EMAIL PROTECTED]> writes:
| [EMAIL PROTECTED] wrote:
| > Author: larsbj
| > Date: Mon Aug 14 00:54:59 2006
| > New Revision: 14661
| >
| > URL: http://www.lyx.org/trac/changeset/14661
| > Log:
| > Merge the unicode branch into trunk.
| >
| > - src/support/unicode.[Ch]: new files w
[EMAIL PROTECTED] wrote:
> Author: larsbj
> Date: Mon Aug 14 00:54:59 2006
> New Revision: 14661
>
> URL: http://www.lyx.org/trac/changeset/14661
> Log:
> Merge the unicode branch into trunk.
>
> - src/support/unicode.[Ch]: new files with functions for converting
> to and fro ucs4, ucs2 and utf
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| [EMAIL PROTECTED] wrote:
| > Author: larsbj
| > Date: Mon Aug 14 00:54:59 2006
| > New Revision: 14661
| > URL: http://www.lyx.org/trac/changeset/14661
| > Log:
| > Merge the unicode branch into trunk.
|
| Congratulation Lars.
|
| I need the attach
[EMAIL PROTECTED] wrote:
Author: larsbj
Date: Mon Aug 14 00:54:59 2006
New Revision: 14661
URL: http://www.lyx.org/trac/changeset/14661
Log:
Merge the unicode branch into trunk.
Congratulation Lars.
I need the attached patch to compile with MSVC. I am comitting now if
you don't mind.
Could
34 matches
Mail list logo
