"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C6F577B.4030803@estarcion.com...

> I'd prefer that both | and + be available, and retain the distinct meanings they have for ints. In the colors example, if MAGENTA is defined as either RED+BLUE or RED|BLUE, there's a useful semantic difference between MAGENTA+BLUE and MAGENTA|BLUE (especially when you get away from constants and into variables). Generations of us filthy unwashed C fanatics have learned this weird distinction, and IMO it would be Evil and Rude to suddenly make + do a bitwise OR.

It's not a bitwise OR, it's a union operator. Just forget
about flags as a set of bits, implementation is of compiler's
business only. Think of it just as of set of flags where
each can be set or reset. a + b means unionize, so the result
will have all flags from a set, as well as all flags from b.
Since you cannot set the same flag twice, it is simply set
once. Internally, this is of course implemented by the bitwise
OR operator. But we shouldn't care about such things.

BTW if flags aren't integers (at least not implicitly castable), usual arithmetic + has no meaning on them. Nobody uses + to construct flagsets out of distinct flags because it is unsafe. You use | anyhow. Making + a synonym for it shouldn't hurt...

The same would apply to -. a - b results in all flags from a set except of those that were set in b. In C you'd write it as a & ~b. I claim that a - b is easier to read and understand here...

> You and your project team, of course, Pavel, are more than welcome to define a "class Color" which overloads the plus sign to do a bitwise OR. Or perhaps a bitwise AND. Whatever.

This doesn't only apply to colors. This applies to any flag sets. What's the reason of adding a bitset to a bitset anyhow? You won't get any useful result, nothing of real interest...

"Pavel Minayev" <evilone@omen.ru> wrote in message
> Oh, BTW, Walter, what about private imports?

I'm focussed on the inline assembler <g>.

"Walter" <walter@digitalmars.com> wrote in message news:a4pp99$1ek3$1@digitaldaemon.com...

> I'm focussed on the inline assembler <g>.

GREAT!

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a4nsf4$ob3$1@digitaldaemon.com...
> "Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C6F577B.4030803@estarcion.com...
>
> > I'd prefer that both | and + be available, and retain the distinct meanings they have for ints. In the colors example, if MAGENTA is defined as either RED+BLUE or RED|BLUE, there's a useful semantic difference between MAGENTA+BLUE and MAGENTA|BLUE (especially when you get away from constants and into variables). Generations of us filthy unwashed C fanatics have learned this weird distinction, and IMO it would be Evil and Rude to suddenly make + do a bitwise OR.
>
> It's not a bitwise OR, it's a union operator. Just forget
> about flags as a set of bits, implementation is of compiler's
> business only. Think of it just as of set of flags where
> each can be set or reset. a + b means unionize, so the result
> will have all flags from a set, as well as all flags from b.
> Since you cannot set the same flag twice, it is simply set
> once. Internally, this is of course implemented by the bitwise
> OR operator. But we shouldn't care about such things.
>
> BTW if flags aren't integers (at least not implicitly castable), usual arithmetic + has no meaning on them. Nobody uses + to construct flagsets out of distinct flags because it is unsafe. You use | anyhow. Making + a synonym for it shouldn't hurt...
>
> The same would apply to -. a - b results in all flags from a set except of those that were set in b. In C you'd write it as a & ~b. I claim that a - b is easier to read and understand here...
>
> > You and your project team, of course, Pavel, are more than welcome to define a "class Color" which overloads the plus sign to do a bitwise OR. Or perhaps a bitwise AND. Whatever.
>
> This doesn't only apply to colors. This applies to any flag sets. What's the reason of adding a bitset to a bitset anyhow? You won't get any useful result, nothing of real interest...
>
>

I really like this flag idea, but isn't it just a subset of Pascal sets? Here is what it could look like in D style notation:

enum EColors {RED, GREEN, BLUE};
set[EColors] SColorFlags;

SColorFlags = [RED, GREEN];
SColorFlags -= RED;
SColorFlags += BLUE;
if (BLUE in SColorFlags)

something like that?
Then you could also make sets of characters, a very usefull feature
in Pascal IMHO:

set[char] SCharSet;
SCharSet scValidPasswordChars = ['a'..'z', 'A'..'Z', '_', '-', '0'..'9'];
if (cTypedChar in scValidPasswordChars)

I always missed sets in C/C++...


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a4rlaa$27ug$1@digitaldaemon.com...

> I really like this flag idea, but isn't it just a subset of Pascal sets?

Absolutely, I've mentioned this already, and I suggested using the keyword "set" for this";

> Here is what it could look like in D style notation:
>
> enum EColors {RED, GREEN, BLUE};
> set[EColors] SColorFlags;

Maybe it's better to make sets separate types, like structs or enums?

    set EColors {RED, GREEN, BLUE}

    -- or --

    enum EColor {RED, GREEN, BLUE}
    set EColors: EColor;

    ...
    EColors colors;

> SColorFlags = [RED, GREEN];

First of all, don't forget that each enum/set has its own namespace. So you use EColor.RED and EColor.BLUE, not just RED or BLUE.

Then, to simplify things for the compiler, and to distinguish from awaited array literals, some form of "set constructor" could be used:

    colors = EColors[RED, GREEN];
    // the same as above...
    colors = EColors.RED + EColors.GREEN;

> SColorFlags -= RED;
> SColorFlags += BLUE;
> if (BLUE in SColorFlags)

I propose SColorFlags.BLUE - this is not Pascal, so it's better to follow the C/D notation here, IMO.

> something like that?
> Then you could also make sets of characters, a very usefull feature
> in Pascal IMHO:
>
> set[char] SCharSet;
> SCharSet scValidPasswordChars = ['a'..'z', 'A'..'Z', '_', '-', '0'..'9'];
> if (cTypedChar in scValidPasswordChars)

Ugh... this means sets should support ranges and stuff... something I think would be too huge to ask Walter for. I'd be pretty happy with sets as "bit flags".

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a4rmpd$28jn$1@digitaldaemon.com...
> "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a4rlaa$27ug$1@digitaldaemon.com...
>
> > I really like this flag idea, but isn't it just a subset of Pascal sets?
>
> Absolutely, I've mentioned this already, and I suggested using the keyword "set" for this";
>
> > Here is what it could look like in D style notation:
> >
> > enum EColors {RED, GREEN, BLUE};
> > set[EColors] SColorFlags;
>
> Maybe it's better to make sets separate types, like structs or enums?
>
>     set EColors {RED, GREEN, BLUE}

What about a set of chars...
set SChars {'a', 'b', 'c', Aaargh :)


>
>     -- or --
>
>     enum EColor {RED, GREEN, BLUE}
>     set EColors: EColor;
>

Would work ok


>     ...
>     EColors colors;
>
> > SColorFlags = [RED, GREEN];
>
> First of all, don't forget that each enum/set has its own namespace. So you use EColor.RED and EColor.BLUE, not just RED or BLUE.
>

Autch....I don't know if I like that...Although it has some great advantages...But I thought prepending the namespace was only necessary if there could be ambiguity?


> Then, to simplify things for the compiler, and to distinguish from awaited array literals, some form of "set constructor" could be used:
>
>     colors = EColors[RED, GREEN];
>     // the same as above...
>     colors = EColors.RED + EColors.GREEN;
>

Ok


> > SColorFlags -= RED;
> > SColorFlags += BLUE;
> > if (BLUE in SColorFlags)
>
> I propose SColorFlags.BLUE - this is not Pascal, so it's better to follow the C/D notation here, IMO.
>

Could you explain some more?
Would you mean that

if (SColorFlags.BLUE)

would be the same as

if (BLUE in SColorFlags)

in Pascal?


> > something like that?
> > Then you could also make sets of characters, a very usefull feature
> > in Pascal IMHO:
> >
> > set[char] SCharSet;
> > SCharSet scValidPasswordChars = ['a'..'z', 'A'..'Z', '_', '-',
'0'..'9'];
> > if (cTypedChar in scValidPasswordChars)
>
> Ugh... this means sets should support ranges and stuff... something I think would be too huge to ask Walter for. I'd be pretty happy with sets as "bit flags".
>


It's a lot to ask, okay, but it also offers some great advantages.
I would be okay with bit flags too though, but I would then call
them flags to avoid confusion with pascal.
Whichever way you put it, I think a way to define flags would
be a great benefit, because they are used *very* often!


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a4u115$8h1$1@digitaldaemon.com...

> What about a set of chars...
> set SChars {'a', 'b', 'c', Aaargh :)

For simplicity, it'd be better for sets to fit into
32 bits, I believe. But if they don't, then...

    set SChars { a = 'a', b, c , ... }

Some architectures out there have 128 bit registers... wouldn't want them to feel overpowered would we?  ;)  Besides, you can just continue chaining together registers until you have enough bits... they are flags after all, there's no carry to worry about;  It's not nearly as complicated as, say, long division.  So I wouldn't advise imposing an absolute limit.  Pascal sets had a limit of 256 bits and that wasn't enough from what I remember trying to use it for sometimes.

Sean

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a4u1cf$8o8$1@digitaldaemon.com...
> "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a4u115$8h1$1@digitaldaemon.com...
>
> > What about a set of chars...
> > set SChars {'a', 'b', 'c', Aaargh :)
>
> For simplicity, it'd be better for sets to fit into
> 32 bits, I believe. But if they don't, then...
>
>     set SChars { a = 'a', b, c , ... }

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:a4vok0$n4e$1@digitaldaemon.com...
> Some architectures out there have 128 bit registers... wouldn't want them
to
> feel overpowered would we?  ;)  Besides, you can just continue chaining together registers until you have enough bits... they are flags after all, there's no carry to worry about;  It's not nearly as complicated as, say, long division.  So I wouldn't advise imposing an absolute limit.  Pascal sets had a limit of 256 bits and that wasn't enough from what I remember trying to use it for sometimes.

There are only 3 numbers in computers: 0, 1, and any number. Any oddball limits, like 256 bits, 6 windows, 80 character command lines, etc., is a bug <g>. Take quicken's checkbook program, for example. It is so enormous it fills a CD. But I can only type in 10 characters or so into the [memo] field. Go figure.

"Walter" <walter@digitalmars.com> escribió en el mensaje
news:a4pp99$1ek3$1@digitaldaemon.com...
|
| "Pavel Minayev" <evilone@omen.ru> wrote in message
| > Oh, BTW, Walter, what about private imports?
|
| I'm focussed on the inline assembler <g>.
|
|
|

Inline assembler is already implemented, isn't it? :D

I mean, if I had:

------a.d
class A {}
------b.d
private import a;  /*1*/
class B:A {}
------c.d
import b;
B _b;
A _a; /*2*/

Because of /*1*/, I don't want /*2*/ to work. But it does.

————————————————————————— Carlos Santander


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.463 / Virus Database: 262 - Release Date: 2003-03-17