• =?ISO-8859-1?Q?Cl=e1udio?= (10/10) Jul 10 2012 Hi Matt,
• Matt Wilson (7/23) Jul 16 2012 Cláudio
• =?ISO-8859-1?Q?Cl=e1udio?= (5/41) Jul 25 2012 Hi Matt,
• Matt Wilson (19/65) Jul 30 2012 Thanks Cláudio, but that doesn't really help me. What you've given me is...
• Matt Wilson (3/77) Jul 31 2012 I meant 'sink', not 'inserter', hence fastformat/sinks/CComBSTR.hpp
• =?ISO-8859-1?Q?Cl=e1udio_Albuquerque?= (9/97) Jul 31 2012 Hi Matt,
• Matt Wilson (7/122) Aug 01 2012 Ok, that's more helpful.
• Claudio Albuquerque (6/145) Aug 08 2012 Hi Matt,

=?ISO-8859-1?Q?Cl=e1udio?= <claudio.albuquerque gmail.com> writes:

Hi Matt,

I have an issue with fastformat tried to find this information online with no
sucess.

I have an aplication being compiled with unicode definitions. But on some
network protocol routines ANSI strings are required. So what I have is simple
thing like the following sample:

basic_string<char> str;
fastformat::fmt (str,...);

When compiling it complains for example that c_str_len_w cannot convert
arguments. By browsing the fastformat code I see that because of the UNICODE
definition the shim c_str_len_w in in fact beeing selected.

Do you have any idea how to get past this issue or on the otherhand what I'm
doing wrong.

Thanks
Cláudio Albuquerque
string 

"Matt Wilson" <matthewwilson acm.org> writes:

Cláudio

I understand what you're trying to do, but I can't replicate it with the _w 
shims being selected. Can you post a minimal example showing the problem?

Thanks

Matt

"Cláudio" <claudio.albuquerque gmail.com> wrote in message 
news:jtilh5$1n7o$1 digitalmars.com...
 Hi Matt,

 I have an issue with fastformat tried to find this information online with 
 no sucess.

 I have an aplication being compiled with unicode definitions. But on some 
 network protocol routines ANSI strings are required. So what I have is 
 simple thing like the following sample:

 basic_string<char> str;
 fastformat::fmt (str,...);

 When compiling it complains for example that c_str_len_w cannot convert 
 arguments. By browsing the fastformat code I see that because of the 
 UNICODE definition the shim c_str_len_w in in fact beeing selected.

 Do you have any idea how to get past this issue or on the otherhand what 
 I'm doing wrong.

 Thanks
 Cláudio Albuquerque
 string 

=?ISO-8859-1?Q?Cl=e1udio?= <claudio.albuquerque gmail.com> writes:

Hi Matt,

Please find attached the sample project, hope it helps.

BR,
Cláudio Albuquerque


Matt Wilson Wrote:

 Cláudio
 
 I understand what you're trying to do, but I can't replicate it with the _w 
 shims being selected. Can you post a minimal example showing the problem?
 
 Thanks
 
 Matt
 
 "Cláudio" <claudio.albuquerque gmail.com> wrote in message 
 news:jtilh5$1n7o$1 digitalmars.com...
 Hi Matt,

 I have an issue with fastformat tried to find this information online with 
 no sucess.

 I have an aplication being compiled with unicode definitions. But on some 
 network protocol routines ANSI strings are required. So what I have is 
 simple thing like the following sample:

 basic_string<char> str;
 fastformat::fmt (str,...);

 When compiling it complains for example that c_str_len_w cannot convert 
 arguments. By browsing the fastformat code I see that because of the 
 UNICODE definition the shim c_str_len_w in in fact beeing selected.

 Do you have any idea how to get past this issue or on the otherhand what 
 I'm doing wrong.

 Thanks
 Cláudio Albuquerque
 string 

 
 

"Matt Wilson" <matthewwilson acm.org> writes:

Thanks Cláudio, but that doesn't really help me. What you've given me is a 
project that is written as multibyte and compiled as wide : obviously that's 
not going to work, and my advice in such a case would be compile as 
multibyte.

I understand that you want to mix, but I need more of a clear understanding 
of the relative proportions (of multibyte vs wide) of your project before I 
can advise.

For example, a client project some years ago was multibyte but required 
formatting to COM strings (aka BSTR), which is achieved by having a 
multibyte build, and hence a multibyte FastFormat, and using the CComBSTR 
inserter (fastformat/inserters/CComBSTR.hpp), as illustrated in/around 
Listing 14 in http://accu.org/index.php/journals/1561

IIUC, you have an analogous situation, but in reverse. It may be that the 
simple solution is to craft a suitable inserter. If you can give me more 
details, we'll be able to say one way or the other.

HTH

Matt


"Cláudio" <claudio.albuquerque gmail.com> wrote in message 
news:jup5pj$s8u$1 digitalmars.com...
 Hi Matt,

 Please find attached the sample project, hope it helps.

 BR,
 Cláudio Albuquerque


 Matt Wilson Wrote:

 Cláudio

 I understand what you're trying to do, but I can't replicate it with the 
 _w
 shims being selected. Can you post a minimal example showing the problem?

 Thanks

 Matt

 "Cláudio" <claudio.albuquerque gmail.com> wrote in message
 news:jtilh5$1n7o$1 digitalmars.com...
 Hi Matt,

 I have an issue with fastformat tried to find this information online 
 with
 no sucess.

 I have an aplication being compiled with unicode definitions. But on 
 some
 network protocol routines ANSI strings are required. So what I have is
 simple thing like the following sample:

 basic_string<char> str;
 fastformat::fmt (str,...);

 When compiling it complains for example that c_str_len_w cannot convert
 arguments. By browsing the fastformat code I see that because of the
 UNICODE definition the shim c_str_len_w in in fact beeing selected.

 Do you have any idea how to get past this issue or on the otherhand 
 what
 I'm doing wrong.

 Thanks
 Cláudio Albuquerque
 string


 

"Matt Wilson" <matthewwilson acm.org> writes:

I meant 'sink', not 'inserter', hence fastformat/sinks/CComBSTR.hpp

"Matt Wilson" <matthewwilson acm.org> wrote in message 
news:jv802q$303m$1 digitalmars.com...
 Thanks Cláudio, but that doesn't really help me. What you've given me is a 
 project that is written as multibyte and compiled as wide : obviously 
 that's not going to work, and my advice in such a case would be compile as 
 multibyte.

 I understand that you want to mix, but I need more of a clear 
 understanding of the relative proportions (of multibyte vs wide) of your 
 project before I can advise.

 For example, a client project some years ago was multibyte but required 
 formatting to COM strings (aka BSTR), which is achieved by having a 
 multibyte build, and hence a multibyte FastFormat, and using the CComBSTR 
 inserter (fastformat/inserters/CComBSTR.hpp), as illustrated in/around 
 Listing 14 in http://accu.org/index.php/journals/1561

 IIUC, you have an analogous situation, but in reverse. It may be that the 
 simple solution is to craft a suitable inserter. If you can give me more 
 details, we'll be able to say one way or the other.

 HTH

 Matt


 "Cláudio" <claudio.albuquerque gmail.com> wrote in message 
 news:jup5pj$s8u$1 digitalmars.com...
 Hi Matt,

 Please find attached the sample project, hope it helps.

 BR,
 Cláudio Albuquerque


 Matt Wilson Wrote:

 Cláudio

 I understand what you're trying to do, but I can't replicate it with the 
 _w
 shims being selected. Can you post a minimal example showing the 
 problem?

 Thanks

 Matt

 "Cláudio" <claudio.albuquerque gmail.com> wrote in message
 news:jtilh5$1n7o$1 digitalmars.com...
 Hi Matt,

 I have an issue with fastformat tried to find this information online 
 with
 no sucess.

 I have an aplication being compiled with unicode definitions. But on 
 some
 network protocol routines ANSI strings are required. So what I have is
 simple thing like the following sample:

 basic_string<char> str;
 fastformat::fmt (str,...);

 When compiling it complains for example that c_str_len_w cannot 
 convert
 arguments. By browsing the fastformat code I see that because of the
 UNICODE definition the shim c_str_len_w in in fact beeing selected.

 Do you have any idea how to get past this issue or on the otherhand 
 what
 I'm doing wrong.

 Thanks
 Cláudio Albuquerque
 string



 

=?ISO-8859-1?Q?Cl=e1udio_Albuquerque?= <claudio.albuquerque gmail.com> writes:

Hi Matt,

My sample file was a quick way to present the problem, sorry I was not clearer
on the matter. 
 

The case I'm in is the following: the project is a full unicode project, were
only some parts regarding the network protocol stack must work with ANSI. The
rest of the I would say that 90% of the formatter code is Unicode.

So what I would like to achive is something like overload resolution based on
the sink type. And in fact this is my "dumb" question, couldn't I force
fastformat to pick the c_str_len function through overload resolutionbased on
the type currently being used for the sink?


I will check the link bellow, but any help is apreaticated, but for now I've
bypassed the issue going back to the *printf API.


Thanks
Cláudio Albuquerque
 



 I meant 'sink', not 'inserter', hence fastformat/sinks/CComBSTR.hpp
 
 "Matt Wilson" <matthewwilson acm.org> wrote in message 
 news:jv802q$303m$1 digitalmars.com...
 Thanks Cláudio, but that doesn't really help me. What you've given me is a 
 project that is written as multibyte and compiled as wide : obviously 
 that's not going to work, and my advice in such a case would be compile as 
 multibyte.

 I understand that you want to mix, but I need more of a clear 
 understanding of the relative proportions (of multibyte vs wide) of your 
 project before I can advise.

 For example, a client project some years ago was multibyte but required 
 formatting to COM strings (aka BSTR), which is achieved by having a 
 multibyte build, and hence a multibyte FastFormat, and using the CComBSTR 
 inserter (fastformat/inserters/CComBSTR.hpp), as illustrated in/around 
 Listing 14 in http://accu.org/index.php/journals/1561

 IIUC, you have an analogous situation, but in reverse. It may be that the 
 simple solution is to craft a suitable inserter. If you can give me more 
 details, we'll be able to say one way or the other.

 HTH

 Matt


 "Cláudio" <claudio.albuquerque gmail.com> wrote in message 
 news:jup5pj$s8u$1 digitalmars.com...
 Hi Matt,

 Please find attached the sample project, hope it helps.

 BR,
 Cláudio Albuquerque


 Matt Wilson Wrote:

 Cláudio

 I understand what you're trying to do, but I can't replicate it with the 
 _w
 shims being selected. Can you post a minimal example showing the 
 problem?

 Thanks

 Matt

 "Cláudio" <claudio.albuquerque gmail.com> wrote in message
 news:jtilh5$1n7o$1 digitalmars.com...
 Hi Matt,

 I have an issue with fastformat tried to find this information online 
 with
 no sucess.

 I have an aplication being compiled with unicode definitions. But on 
 some
 network protocol routines ANSI strings are required. So what I have is
 simple thing like the following sample:

 basic_string<char> str;
 fastformat::fmt (str,...);

 When compiling it complains for example that c_str_len_w cannot 
 convert
 arguments. By browsing the fastformat code I see that because of the
 UNICODE definition the shim c_str_len_w in in fact beeing selected.

 Do you have any idea how to get past this issue or on the otherhand 
 what
 I'm doing wrong.

 Thanks
 Cláudio Albuquerque
 string



 

 
 

"Matt Wilson" <matthewwilson acm.org> writes:

Ok, that's more helpful.

Just to be clear, is it the case that all arguments to the conversion 
function are "wide", just that the output needs to be multibyte? If so, it 
would be pretty straightforward to craft a sink that allows this.

Matt

"Cláudio Albuquerque" <claudio.albuquerque gmail.com> wrote in message 
news:jv968q$274b$1 digitalmars.com...
 Hi Matt,

 My sample file was a quick way to present the problem, sorry I was not 
 clearer on the matter.


 The case I'm in is the following: the project is a full unicode project, 
 were only some parts regarding the network protocol stack must work with 
 ANSI. The rest of the I would say that 90% of the formatter code is 
 Unicode.

 So what I would like to achive is something like overload resolution based 
 on the sink type. And in fact this is my "dumb" question, couldn't I force 
 fastformat to pick the c_str_len function through overload resolutionbased 
 on the type currently being used for the sink?


 I will check the link bellow, but any help is apreaticated, but for now 
 I've bypassed the issue going back to the *printf API.


 Thanks
 Cláudio Albuquerque




 I meant 'sink', not 'inserter', hence fastformat/sinks/CComBSTR.hpp

 "Matt Wilson" <matthewwilson acm.org> wrote in message
 news:jv802q$303m$1 digitalmars.com...
 Thanks Cláudio, but that doesn't really help me. What you've given me 
 is a
 project that is written as multibyte and compiled as wide : obviously
 that's not going to work, and my advice in such a case would be compile 
 as
 multibyte.

 I understand that you want to mix, but I need more of a clear
 understanding of the relative proportions (of multibyte vs wide) of 
 your
 project before I can advise.

 For example, a client project some years ago was multibyte but required
 formatting to COM strings (aka BSTR), which is achieved by having a
 multibyte build, and hence a multibyte FastFormat, and using the 
 CComBSTR
 inserter (fastformat/inserters/CComBSTR.hpp), as illustrated in/around
 Listing 14 in http://accu.org/index.php/journals/1561

 IIUC, you have an analogous situation, but in reverse. It may be that 
 the
 simple solution is to craft a suitable inserter. If you can give me 
 more
 details, we'll be able to say one way or the other.

 HTH

 Matt


 "Cláudio" <claudio.albuquerque gmail.com> wrote in message
 news:jup5pj$s8u$1 digitalmars.com...
 Hi Matt,

 Please find attached the sample project, hope it helps.

 BR,
 Cláudio Albuquerque


 Matt Wilson Wrote:

 Cláudio

 I understand what you're trying to do, but I can't replicate it with 
 the
 _w
 shims being selected. Can you post a minimal example showing the
 problem?

 Thanks

 Matt

 "Cláudio" <claudio.albuquerque gmail.com> wrote in message
 news:jtilh5$1n7o$1 digitalmars.com...
 Hi Matt,

 I have an issue with fastformat tried to find this information 
 online
 with
 no sucess.

 I have an aplication being compiled with unicode definitions. But 
 on
 some
 network protocol routines ANSI strings are required. So what I have 
 is
 simple thing like the following sample:

 basic_string<char> str;
 fastformat::fmt (str,...);

 When compiling it complains for example that c_str_len_w cannot
 convert
 arguments. By browsing the fastformat code I see that because of 
 the
 UNICODE definition the shim c_str_len_w in in fact beeing selected.

 Do you have any idea how to get past this issue or on the otherhand
 what
 I'm doing wrong.

 Thanks
 Cláudio Albuquerque
 string





 

Claudio Albuquerque <claudio.albuquerque gmail.com> writes:

Hi Matt,

For now all my arguments are also ANSI.
Although, allowing for a formatting conversition would be also great.

BR,
Cláudio Albuquerque

Matt Wilson Wrote:

 Ok, that's more helpful.
 
 Just to be clear, is it the case that all arguments to the conversion 
 function are "wide", just that the output needs to be multibyte? If so, it 
 would be pretty straightforward to craft a sink that allows this.
 
 Matt
 
 "Cláudio Albuquerque" <claudio.albuquerque gmail.com> wrote in message 
 news:jv968q$274b$1 digitalmars.com...
 Hi Matt,

 My sample file was a quick way to present the problem, sorry I was not 
 clearer on the matter.


 The case I'm in is the following: the project is a full unicode project, 
 were only some parts regarding the network protocol stack must work with 
 ANSI. The rest of the I would say that 90% of the formatter code is 
 Unicode.

 So what I would like to achive is something like overload resolution based 
 on the sink type. And in fact this is my "dumb" question, couldn't I force 
 fastformat to pick the c_str_len function through overload resolutionbased 
 on the type currently being used for the sink?


 I will check the link bellow, but any help is apreaticated, but for now 
 I've bypassed the issue going back to the *printf API.


 Thanks
 Cláudio Albuquerque




 I meant 'sink', not 'inserter', hence fastformat/sinks/CComBSTR.hpp

 "Matt Wilson" <matthewwilson acm.org> wrote in message
 news:jv802q$303m$1 digitalmars.com...
 Thanks Cláudio, but that doesn't really help me. What you've given me 
 is a
 project that is written as multibyte and compiled as wide : obviously
 that's not going to work, and my advice in such a case would be compile 
 as
 multibyte.

 I understand that you want to mix, but I need more of a clear
 understanding of the relative proportions (of multibyte vs wide) of 
 your
 project before I can advise.

 For example, a client project some years ago was multibyte but required
 formatting to COM strings (aka BSTR), which is achieved by having a
 multibyte build, and hence a multibyte FastFormat, and using the 
 CComBSTR
 inserter (fastformat/inserters/CComBSTR.hpp), as illustrated in/around
 Listing 14 in http://accu.org/index.php/journals/1561

 IIUC, you have an analogous situation, but in reverse. It may be that 
 the
 simple solution is to craft a suitable inserter. If you can give me 
 more
 details, we'll be able to say one way or the other.

 HTH

 Matt


 "Cláudio" <claudio.albuquerque gmail.com> wrote in message
 news:jup5pj$s8u$1 digitalmars.com...
 Hi Matt,

 Please find attached the sample project, hope it helps.

 BR,
 Cláudio Albuquerque


 Matt Wilson Wrote:

 Cláudio

 I understand what you're trying to do, but I can't replicate it with 
 the
 _w
 shims being selected. Can you post a minimal example showing the
 problem?

 Thanks

 Matt

 "Cláudio" <claudio.albuquerque gmail.com> wrote in message
 news:jtilh5$1n7o$1 digitalmars.com...
 Hi Matt,

 I have an issue with fastformat tried to find this information 
 online
 with
 no sucess.

 I have an aplication being compiled with unicode definitions. But 
 on
 some
 network protocol routines ANSI strings are required. So what I have 
 is
 simple thing like the following sample:

 basic_string<char> str;
 fastformat::fmt (str,...);

 When compiling it complains for example that c_str_len_w cannot
 convert
 arguments. By browsing the fastformat code I see that because of 
 the
 UNICODE definition the shim c_str_len_w in in fact beeing selected.

 Do you have any idea how to get past this issue or on the otherhand
 what
 I'm doing wrong.

 Thanks
 Cláudio Albuquerque
 string