"D" <s_nudds@hotmail.com> ha scritto nel messaggio news:a3tvf5$r6f$1@digitaldaemon.com...
> What the hell is a case insensitive string.  Now that is a dum idea.  Case insensitive comparison.  That is a smart idea.

I think they are all good ideas.

> In any case, If there was such a thing as a case insensitive string, then
> make an exception.
> I fail to see the difficulty.

An exception is OK, if it's an exception.
If it becomes a rule (i.e. there are other examples than CIString) then we
must handle it
somehow.

>
> By the way Roberto. if a case insensitive string is printed, is it printed in upper or lower case?
>
> Also Robert, you can create a case insensitive string simply by changing
the
> case to all upper or all lower during the load.  Since the case is insensitive, altering the case during the load is not relevant is it?


I'm thinking of Windows file names: they are case insensitive, but they
preserve case.
So, if an user wants to open "myfile.txt", but the system find "MyFile.txt",
the open should
be successful. On the other hand, when the file is opened, it is shown as
"MyFile.txt" as
it actually is.

Ciao

"D" <s_nudds@hotmail.com> wrote in message news:a3tvf5$r6f$1@digitaldaemon.com...

> What the hell is a case insensitive string.  Now that is a dum idea.

   That'll be in your opinion, sir!

   Man, you've got to learn to control your wording, or else we're going to
have a problem.

> Case insensitive comparison.  That is a smart idea.

   I use case insensitive strings every day. They are not dumb. A case
insensitice string is one that compares with disregard to case. So that, if
"istring" is a case insensitive string,

istring  s1 = "D is better than C";
istring  s2 = "D IS BETTER THAN C";
s1 == s2; // this is true.

   I agree that case-insensitivity is normally related to the comparisons
themselves, not to the strings. But sometimes, it is a property of the
strings. I use them in Win32 especially because I have a special string
class that holds path names (call it pathname). And in Win32, path names are
always case-insensitive. I see that as a property of the path as a whole,
not of the comparisons applied to it. Makes for cleaner code in the end,
because I don't need to remember that paths need different comparison
functions.

> In any case, If there was such a thing as a case insensitive string, then make an exception.
>
> I fail to see the difficulty.

   The difficulty is that, if every time it makes sense to make an exception
you need to modify the language, the language gets bloated. It's best to be
able to define extensions externally.

   In my opinion! ;-)

> By the way Roberto. if a case insensitive string is printed, is it printed in upper or lower case?
>
> Also Robert, you can create a case insensitive string simply by changing
the
> case to all upper or all lower during the load.  Since the case is insensitive, altering the case during the load is not relevant is it?

   :) That's the dark side of case insensitive strings. Personally, I use
the Windows file system way: case is stored as given, but comparisons don't
use it. It's the same as ignoring part of a structure in its comparison
operators. It does make for some awkward situations, I'll grant you that.

Salutaciones,
                         JCAB

> "D" <s_nudds@hotmail.com> ha scritto nel messaggio news:a3tvf5$r6f$1@digitaldaemon.com...
> > What the hell is a case insensitive string.  Now that is a dum idea.
Case
> > insensitive comparison.  That is a smart idea.

Roberto Mariottini writes:
> I think they are all good ideas.

 Clearly not.  Case insensitive strings provide no advantage.


> > By the way Roberto. if a case insensitive string is printed, is it
printed
> > in upper or lower case?
> >
> > Also Robert, you can create a case insensitive string simply by changing
> the
> > case to all upper or all lower during the load.  Since the case is insensitive, altering the case during the load is not relevant is it?


Roberto Mariottini writes:
> I'm thinking of Windows file names: they are case insensitive, but they preserve case.

  I am well aware of case insensitity.  Case sensitivity is one of the major
failings of C
and Unix in general.  WORDS DO NOT CHANGE THEIR MEANING IF THEIR
CASE CHANGES.  Hence labels should not change their meaning either.

  D should be case insensitive.

  Case insensitivity is best performed through a case insensitive compare
function, or
through conveting the source and target strings to a common case before a
typical
case sensitive conversion.

  Now before someone blathers that such conversions are ineffiicent, the
truth of the matter is
that there is no difference in computational efficiency since with a case
insensitive string,
ultimately both the source and destination will need to be converted to a
common case internally
on a character by character basis during the comparison.

  Case insensitive strings would also require the inclusion of an additional
string functions in the
default library for every string operation where case differences must be
ignored, thus increasing the
minimal footprint for the resulting programs.

  The only advantage a native case insensitive string type has over a normal
string type is that a
case insensitive string will carry with it a flag that indicates that it is
case insensitive.  I admit that
carrying such a flag is convenient.

  However, as long as we are carrying a single flag along with the string,
there is no additional cost to
us for carrying a generalized flag variable along with the string.  A single
byte can contain 8 or 16, general
purpose flags, or be used for other identification purposes.  One could use
the register as an integer for
the storage of an offset into the string, or an object reference, or
anything else the programmer desires.

  So, it is clear that if case insensitivity is seen as important, a general
purpose integer typed tag be
associated with each string instead.

As I recognized, case insensitivity is indeed a good thing.  A native type
case
insensensitive string is not.

As you indicate in those instances where they are convenient, they can be
created
by defining a new type.

Good programming languages do not have holes.  Questions do not arrise as to
how a specific
situation will be handled.

Good programming languages follow a design philosophy which indicate the
path taken when
or more logical options are available.  That is language consistancy.

Case invariant strings raise too many questions as to how specific instances
will be handled.  They
increase the minimum footprint of the language.  To be implemented properly
an insensitivity flag
must be stored along with the string, and if that is to be the case, on a
cost/benefit basis it is better
to break out the insensitivity flag to a general purpose flags register or
integer so that it can be used
for other purposes.


Juan Carlos Arevalo Baeza <jcab@roningames.com> wrote in message news:a419m3$2kgj$1@digitaldaemon.com...
>    :) That's the dark side of case insensitive strings. Personally, I use
> the Windows file system way: case is stored as given, but comparisons
don't
> use it. It's the same as ignoring part of a structure in its comparison operators. It does make for some awkward situations, I'll grant you that.

I've been thinking a lot about operator overloading.

1) The idea of 'special' operators for overloading, like :+: being the overloadable version of +, is a good idea, but it fails when used with templates.

2) Overloaded operator functions should be inlineable, which lets out interfaces.

3) I just don't like the idea of operator functions having hidden arguments:

    int operator+(int y);

A binary operator function should, gosh darn it, have TWO operands:

    static int operator+(Foo x, int y);

4) I don't see a point to smart pointers and such in a garbage collected language. Overloadable operators should be restricted to arithmetic operators.

5) Operator overloading should only be used to provide arithmetic operations on user defined arithmetic types. None of that << and >> for iostreams. I know many people like that, but a shift is not a stream operation. It just isn't.

6) I see no way to have the compiler enforce (5). Anyone caught violating
(5) should be forced to carry the Stone of Shame.

7) Note (3) means no virtual operator functions. To do that, you'd need:
    static int operator+(Foo x, int y)
    {
        return x.myadd(y);
    }
so no great loss.

8) If there are to be conversion operators, they will not participate in implicit conversions, only explicit ones.

None of this is implemented or specified yet, it's just some thoughts.

Walter <walter@digitalmars.com> wrote in message news:a4aril$ue9$2@digitaldaemon.com...
>
> I've been thinking a lot about operator overloading.
>
> 1) The idea of 'special' operators for overloading, like :+: being the overloadable version of +, is a good idea, but it fails when used with templates.

  Why?




> 2) Overloaded operator functions should be inlineable, which lets out interfaces.

In the best of all worlds yes.  But that is a limitation of the object
paradigm, not
operator notation.

The fact is, without new operators, the user is going to be forced to
perform the
same operations with standard function calls anyhow.  So functionally there
is no
substantive difference.


> 3) I just don't like the idea of operator functions having hidden
arguments:
>
>     int operator+(int y);

  I've never understood why this is a requirement.  Use a dummy argument
similar to "this"
in such cases.


> 4) I don't see a point to smart pointers and such in a garbage collected language. Overloadable operators should be restricted to arithmetic operators.

I disagree.  Restricting them would cause people to look for ways around the
restrictions,
and would also limit their usefulness in abstract logical systems.



> 5) Operator overloading should only be used to provide arithmetic
operations
> on user defined arithmetic types. None of that << and >> for iostreams. I know many people like that, but a shift is not a stream operation. It just isn't.

Shift operators are used for IO streams because there is no facility for
creating
new operators.with arbitrary names.


> 8) If there are to be conversion operators, they will not participate in implicit conversions, only explicit ones.

  All converstions should be explicit anyhow.  Implicit conversion promotes
error.

"Walter" <walter@digitalmars.com> wrote in message news:a4aril$ue9$2@digitaldaemon.com...

> I've been thinking a lot about operator overloading.
>
> 1) The idea of 'special' operators for overloading, like :+: being the overloadable version of +, is a good idea, but it fails when used with templates.

I think that most people here would be happy to be able to overload just the built-in operators... adding custom ones is quite a lot of work, and the result doesn't worth it (IMO).

> 3) I just don't like the idea of operator functions having hidden
arguments:
>
>     int operator+(int y);
>
> A binary operator function should, gosh darn it, have TWO operands:
>
>     static int operator+(Foo x, int y);

Agreed. Operators should only be declared outside of classes.

> 4) I don't see a point to smart pointers and such in a garbage collected language. Overloadable operators should be restricted to arithmetic operators.

I suppose you mean binary + - * / & | ^ ~ and unary ++ -- ~ ! and all the op= operators?

The question is, should logical operators be overloaded?

> 5) Operator overloading should only be used to provide arithmetic
operations
> on user defined arithmetic types. None of that << and >> for iostreams. I know many people like that, but a shift is not a stream operation. It just isn't.
>
> 6) I see no way to have the compiler enforce (5). Anyone caught violating
> (5) should be forced to carry the Stone of Shame.

Yep, right. There's no way to check how operators are used. Smart guys won't do that. Those who do... it's their problems =)

> 7) Note (3) means no virtual operator functions. To do that, you'd need:
>     static int operator+(Foo x, int y)
>     {
>         return x.myadd(y);
>     }
> so no great loss.

Absolutely.

> 8) If there are to be conversion operators, they will not participate in implicit conversions, only explicit ones.

Which really kills the idea. It's simplier to have the conversion function
then, toInt()/toDouble()/toString() etc.

> None of this is implemented or specified yet, it's just some thoughts.

<<< waiting patiently >>>

Hmmm....D beat me to the punch.  But there's a chance for intelligent conversation yet!

Walter wrote:

> I've been thinking a lot about operator overloading.
>
> 1) The idea of 'special' operators for overloading, like :+: being the overloadable version of +, is a good idea, but it fails when used with templates.

Are you suggesting that a special operator (like :+:) would always be associated with the related operator function operator+   ?   While I personally like having the same operators, I think this might be an excellent balance...it makes it clear that the operator is not a compiler operator, but it allows an inline syntax.

We still have to deal with the issues of things like dot-product vs. cross-product in vectors.  What if we used the same syntax for inline function names?  Basically, if you defined a function name with 2 arguments, you could call it as func(arg1,arg2)   or    arg1 :func: arg2.  Similarly, for those for whom a trailing unary operator is useful (like factorial), you could call a single-function argument with similary syntax     arg :unary-func:    Each of these syntaxes would be EXACTLY equivalent to the old C function call syntax, func(arg1,arg2)    and   unary-func(arg),  respectively.

class Vector {
    static Vector cp(Vector a,Vector b);
    static double dp(Vector a,Vector b);
}

long fact(int i);

Vector foo,bar;
...
double d = a :dp: b;
Vector baz = a :cp: b;
long fred = 6 :fact: ;

It's not pretty, but it allows an inline syntax of a sort without allowing wild creation of unlimited functions.

> 2) Overloaded operator functions should be inlineable, which lets out interfaces.

I'm uncomfortable about this (losing interfaces) in general, but I'm not totally sure why.  I would desire some more details about why interfaces get in the way.

> 3) I just don't like the idea of operator functions having hidden arguments:
>
>     int operator+(int y);
>
> A binary operator function should, gosh darn it, have TWO operands:
>
>     static int operator+(Foo x, int y);

It would sure make overloading the other way around (int + Foo) easier.

> 5) Operator overloading should only be used to provide arithmetic operations on user defined arithmetic types. None of that << and >> for iostreams. I know many people like that, but a shift is not a stream operation. It just isn't.

No reason that ALL operators have to be overridable right now.  You could stick to the basic operators and add support for stuff like << and >> if people show great desire to use them.

> 8) If there are to be conversion operators, they will not participate in implicit conversions, only explicit ones.

I agree :)

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Pavel Minayev wrote:

> > 4) I don't see a point to smart pointers and such in a garbage collected language. Overloadable operators should be restricted to arithmetic operators.
>
> I suppose you mean binary + - * / & | ^ ~ and unary ++ -- ~ ! and all the op= operators?
>
> The question is, should logical operators be overloaded?

I would like to see the compiler provide the remaining logical operators if only a few are defined.  That is, if you define

operator==(Foo,int);
    and
operator<(Foo,int);

(or any other combination of equality and inequality operators) the compiler should be able to provide the rest.  Of course, it won't always be 100% optimized...but if it's not, you can provide the rest of the operators yourself.  I just always hated having to have 4 extra useless functions just to define !=  <=  >= and > for every class.

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C690E8D.37852B1@deming-os.org...

> > The question is, should logical operators be overloaded?

I meant && and ||.

> I would like to see the compiler provide the remaining logical operators
if only
> a few are defined.  That is, if you define
>
> operator==(Foo,int);
>     and
> operator<(Foo,int);
>
> (or any other combination of equality and inequality operators) the
compiler
> should be able to provide the rest.  Of course, it won't always be 100% optimized...but if it's not, you can provide the rest of the operators yourself.  I just always hated having to have 4 extra useless functions
just to
> define !=  <=  >= and > for every class.

Yes, like in C#. The same should, IMO, apply to ++, -- and op= - you can supply them if you want, but if you don't, they are generated automatically from +, - and op.