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

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

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 
> 
>

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
>>
>>
>
>

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
>>>
>>>
>>
>>
>
>

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
> >>>
> >>>
> >>
> >>
> >
> > 
> 
>

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
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>>
>>
>

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
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> > 
> 
>