How do you define a UniChar constant?

"Alexander Dymerets" <sashad.RemoveThis@productengine.com> wrote in message
news:di0kea$ouu$1@toster.te.net.ua...
> Denis @ TheOffice wrote:
>
> > I wonder...
> > If I know how to combine them to make it a McString, why do the compiler have a problem with
that ?
> If compilers knew all that programmers know, programmers would be needless.

Well, it's kind of my point don't you think?
If programmers know better, why do the compiler enforce such a rule?
Don't you think it is a flaw? Even if it is a Standard consortium one.

I mean How does that help anybody ?

in article 1128521638.734805.TakeThisOut@www.vif.com, Denis @ TheOffice at
denisco.TakeThisOut@ica.net wrote on 10/5/05 8:17 AM:

> I mean How does that help anybody ?

It kept *you* from overloading operator + on pointers. If you can't see how
that was a good thing, then you need to think about it a bit more.

Please, can you help me in this thinking?
I am willing to understand.

Why is it a good thing?
or
Why is it such a bad thing?

Either way I can't figure out right now.

Thanks in advance.
Denis

"Scott Ribe" <scott_ribe.DeleteThis@killerbytes.com> wrote in message
news:BF6957C7.3359C%scott_ribe@killerbytes.com...
> in article 1128521638.734805.DeleteThis@www.vif.com, Denis @ TheOffice at
> denisco.DeleteThis@ica.net wrote on 10/5/05 8:17 AM:
>
> > I mean How does that help anybody ?
>
> It kept *you* from overloading operator + on pointers. If you can't see how
> that was a good thing, then you need to think about it a bit more.
>

Denis @ TheOffice wrote:

>Please, can you help me in this thinking?
>I am willing to understand.
>
>Why is it a good thing?
>or
>Why is it such a bad thing?
>
>Either way I can't figure out right now.
>
>Thanks in advance.
>Denis
>
>"Scott Ribe" <scott_ribe.DeleteThis@killerbytes.com> wrote in message
>news:BF6957C7.3359C%scott_ribe@killerbytes.com...
>> in article 1128521638.734805.DeleteThis@www.vif.com, Denis @ TheOffice at
>> denisco.DeleteThis@ica.net wrote on 10/5/05 8:17 AM:
>>
>> > I mean How does that help anybody ?
>>
>> It kept *you* from overloading operator + on pointers. If you can't see how
>> that was a good thing, then you need to think about it a bit more.
>>
>
>

Effective C++ : 55 Specific Ways to Improve Your Programs and Designs
(3rd Edition) -- by Scott Meyers
ISBN: 0321334876

Effective STL: 50 Specific Ways to Improve Your Use of the Standard
Template Library -- by Scott Meyers
ISBN: 0201749629

The C++ Programming Language (Special 3rd Edition) -- by Bjarne
Stroustrup
ISBN: 0201700735

Thanks, I'll have a look...

Although, in the book I have just states it, without given a reasonable reason.

I did find an alternative though, with a macro that upgrade the insignificant CFStringRef to a class
type...

Kind regards,
Denis


"C.R. Osterwald" <rio.RemoveThis@dev.null> wrote in message news:061020050726335157%rio@dev.null...
> Denis @ TheOffice wrote:
>
> >Please, can you help me in this thinking?
> >I am willing to understand.
> >
> >Why is it a good thing?
> >or
> >Why is it such a bad thing?
> >
> >Either way I can't figure out right now.
> >
> >Thanks in advance.
> >Denis
> >
> >"Scott Ribe" <scott_ribe.RemoveThis@killerbytes.com> wrote in message
> >news:BF6957C7.3359C%scott_ribe@killerbytes.com...
> >> in article 1128521638.734805.RemoveThis@www.vif.com, Denis @ TheOffice at
> >> denisco.RemoveThis@ica.net wrote on 10/5/05 8:17 AM:
> >>
> >> > I mean How does that help anybody ?
> >>
> >> It kept *you* from overloading operator + on pointers. If you can't see how
> >> that was a good thing, then you need to think about it a bit more.
> >>
> >
> >
>
> Effective C++ : 55 Specific Ways to Improve Your Programs and Designs
> (3rd Edition) -- by Scott Meyers
> ISBN: 0321334876
>
> Effective STL: 50 Specific Ways to Improve Your Use of the Standard
> Template Library -- by Scott Meyers
> ISBN: 0201749629
>
> The C++ Programming Language (Special 3rd Edition) -- by Bjarne
> Stroustrup
> ISBN: 0201700735

Denis @ TheOffice wrote:

>Thanks, I'll have a look...
>
>Although, in the book I have just states it, without given a reasonable reason.
>
>I did find an alternative though, with a macro that upgrade the insignificant
>CFStringRef to a class
>type...
>
>Kind regards,
>Denis

These books are absolutely indispensable for anyone writing C++.
>
>
>"C.R. Osterwald" <rio.RemoveThis@dev.null> wrote in message
>news:061020050726335157%rio@dev.null...
>> Denis @ TheOffice wrote:
>>
>> >Please, can you help me in this thinking?
>> >I am willing to understand.
>> >
>> >Why is it a good thing?
>> >or
>> >Why is it such a bad thing?
>> >
>> >Either way I can't figure out right now.
>> >
>> >Thanks in advance.
>> >Denis
>> >
>> >"Scott Ribe" <scott_ribe.RemoveThis@killerbytes.com> wrote in message
>> >news:BF6957C7.3359C%scott_ribe@killerbytes.com...
>> >> in article 1128521638.734805.RemoveThis@www.vif.com, Denis @ TheOffice at
>> >> denisco.RemoveThis@ica.net wrote on 10/5/05 8:17 AM:
>> >>
>> >> > I mean How does that help anybody ?
>> >>
>> >> It kept *you* from overloading operator + on pointers. If you can't see
>> >> how
>> >> that was a good thing, then you need to think about it a bit more.
>> >>
>> >
>> >
>>
>> Effective C++ : 55 Specific Ways to Improve Your Programs and Designs
>> (3rd Edition) -- by Scott Meyers
>> ISBN: 0321334876
>>
>> Effective STL: 50 Specific Ways to Improve Your Use of the Standard
>> Template Library -- by Scott Meyers
>> ISBN: 0201749629
>>
>> The C++ Programming Language (Special 3rd Edition) -- by Bjarne
>> Stroustrup
>> ISBN: 0201700735
>
>

> I did find an alternative though, with a macro that upgrade the
> insignificant CFStringRef

Insignificant?

> to a class type...

Ugh. Sounds like a hack, and one you're using to fix a problem you
don't understand. That's not good programming in any book.

A much better solution IMO would be to use your McString class
throughout and define a + operator for that.

Larry

> Does that mean that UniChar in CFDictionairies and
> CFPreferences... won't work.

> Is that what you mean?

No, not at all. I don't even know why you'd ask that, in part because
your question doesn't actually make sense. CFDictionairies don't store
UniChars.

Larry

<larry.TakeThisOut@skytag.com> wrote in message news:1128653963.319097.85340@g44g2000cwa.googlegroups.com...
> > I did find an alternative though, with a macro that upgrade the
> > insignificant CFStringRef
>
> Insignificant?

I meant meaningless.

> > to a class type...
>
> Ugh. Sounds like a hack, and one you're using to fix a problem you
> don't understand. That's not good programming in any book.
>
IMHO, it is as good programming as CFSTR(...)


> A much better solution IMO would be to use your McString class
> throughout and define a + operator for that.

I whish I could understand what you've just said.
Perhaps if you could put some code that illustrates it.

Regards,
Denis

In article <1129261706.215356.TakeThisOut@www.vif.com>, < @> wrote:

> That, I have done (since day 1), but we still cannot use the form:
>
> {
> ...
> TString MyString;
>
> MyString = CFSTR("str1") + CFSTR("str2");
> }

Isn't this just as well:

TString MyString(CFSTR("str1"), CFSTR("str2"));

or if you're opposed to extra convenience ctors:

TString MyString(CFSTR("str1"));
MyString += CFSTR("str2");

>
> OR
>
> If you have a CFStringRef comming from somewhere
> void InAFunction(CFStringRef CFStrFromSomewhere)

Change the signature of InAFunction to accept a TString instead of
CFStringRef. You can still pass it a CFStringRef as long as TString
provides a CFStringRef ctor.

The larger idea is you write a single foundational/framework wrapper
for each OS construct/api-set. Your client /application code (e.g.
InAFunction above) then has no knowledge of these lower level beasts or
how they are implemented.

And you shouldn't be worrying so much about supporting CFSTR - when do
you concatonate 2 const, ascii-only strings in your app? Looking at
some of my code I'm only seeing CFSTR used for:

xml keys
nibs/resources names in my bundle
CFCopyLocalizedStringFromTable calls

Chris Baum wrote:
> In article <1129261706.215356 DeleteThis @www.vif.com>, < @> wrote:
>
> > That, I have done (since day 1), but we still cannot use the form:
> >
> > {
> > ...
> > TString MyString;
> >
> > MyString = CFSTR("str1") + CFSTR("str2");
> > }
>
> Isn't this just as well:
>
> TString MyString(CFSTR("str1"), CFSTR("str2"));
>
> or if you're opposed to extra convenience ctors:
>
> TString MyString(CFSTR("str1"));
> MyString += CFSTR("str2");

This is what I do, except I'd have:

TString myString("str1");

myString += "str2";

since my CFString class has constructors and operators to work with
C-strings.
>
> >
> > OR
> >
> > If you have a CFStringRef comming from somewhere
> > void InAFunction(CFStringRef CFStrFromSomewhere)
>
> Change the signature of InAFunction to accept a TString instead of
> CFStringRef. You can still pass it a CFStringRef as long as TString
> provides a CFStringRef ctor.

This I don't do unless I need functions or operators in TString.
Otherwise I write functions to accept a CFStringRef. That way I can
pass TStrings, CFStrings, and CFMutableStrings, all without invoking
contructors and destructors.
>
> The larger idea is you write a single foundational/framework wrapper
> for each OS construct/api-set. Your client /application code (e.g.
> InAFunction above) then has no knowledge of these lower level beasts or
> how they are implemented.
>
> And you shouldn't be worrying so much about supporting CFSTR - when do
> you concatonate 2 const, ascii-only strings in your app?

Hard-code strings, never. I do build some CFPreferences keys by
concantenating a hard-coded ASCII string and an ASCII string created at
runtime.

> Looking at
> some of my code I'm only seeing CFSTR used for:
>
> xml keys
> nibs/resources names in my bundle

I don't even use them for this. All of my code that does this kind of
stuff is tucked away in utility functions that take C-strings and
create TStrings from them because I didn't want to be hassled with
typing CFSTR("x") all the time when I could just use "x" instead.

> CFCopyLocalizedStringFromTable calls

Or for this. Same reason.

I do have some CFSTRs in my application, but I avoid them if I can
because I hate the extra typing.

Larry