D

[Hans Aberg]

Is it not time to make a new language D drawing on the experiences from C
and C++?

Specifically, such a language should zip out the parts of C that are
problematic and caused ambiguities and problems in C++. For example, the
many implicit type conversions and problems in the C syntax which are
difficult handle in a C++ high level language style. (There is an example
in the Bison manual in the GLR parser section of a C++ language
ambiguity).

Then one would first get a cleaner C core, not having to worry about
upwards compatibility so much anymore. Further this core can be designed
with respect to more modern CPU structures in mind.

The experiences from C++ will tell mainly how to implement statically
computable user definable structures, including some generic programming
then.

To this, one needs a level above the C++ level, handling parallelism,
distributed programming and better handling of dynamic objects (so it
becomes easier to create Java style polymorphic classes), including ones
choice of GC if needed.

On the level below the C level, one can think of a "portable assembler
level" like C-- and/or a byte code level, which can be used as an
intermediate to an assembler level. This level should also provide hooks
to "universal binary standards" like CORBA and Unicode, which C and C++
carefully avoids due to their history.

See you in comp.std.d. :-)

Hans Aberg * Anti-spam: remove "remove." from email address.
* Email: Hans Aberg <re***********@member.ams.org>
* Home Page: <http://www.math.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>

[pete]

Kevin Easton wrote:

In comp.lang.c Paul Hsieh <qe*@pobox.com> wrote:

co****@panix.com (Greg Comeau) wrote in message
news:<be**********@panix5.panix.com>...

[...] Many features in many languages are easy to misunderstand,
including in C, and do sometimes require a closer look.

You're right -- I'm sure there's a primitive rotate instruction in
there somewhere that I'm just not seeing.

Yes, it's quite cunningly hidden:

unsigned rot(unsigned n, int m)
{
return n >> (32-m) | n << m;
}

If you can't write it portably, then you're making the point
that a primative rotate instruction is not part of C.
Is that what you're getting at ?

--
pete

[Arthur J. O'Dwyer]

On Mon, 14 Jul 2003, pete wrote:

Kevin Easton wrote:

In comp.lang.c Paul Hsieh <qe*@pobox.com> wrote:

You're right -- I'm sure there's a primitive rotate instruction in
there somewhere that I'm just not seeing.
Yes, it's quite cunningly hidden:

unsigned rot(unsigned n, int m)
{
return n >> (32-m) | n << m;
}

If you can't write it portably,

[Note that he *could* have made it portable by clever use of UINT_MAX.]
then you're making the point
that a primitive rotate instruction is not part of C.
Is that what you're getting at ?

Yes. His point, as I understand it, was two-fold: first, that since
the "rotate" opcode itself is not portable, it doesn't make sense to
include it in [portable] C; and second, that on platforms which have
a "rotate" opcode to use, any decent optimizer will take care of it
for you. So Paul's "efficiency" argument is bogus.

Tested on DJGPP and Linux gcc for Intel x86 (worked), and gcc for
Solaris 4.something (didn't). I don't know whether the Sun architecture
has 'rotate' or not, but it still compiled to three instructions (with
mnemonics 'srl', 'sll', and 'or').

The details of specific optimizers and machine architectures are obviously
OT here, but it's also pretty clear that gcc -O3 doesn't need any help
from Paul, thankyouverymuch. ;-)

-Arthur

[Kevin Easton]

In comp.lang.c pete <pf*****@mindspring.com> wrote:

Kevin Easton wrote:

In comp.lang.c Paul Hsieh <qe*@pobox.com> wrote:

> co****@panix.com (Greg Comeau) wrote in message
> news:<be**********@panix5.panix.com>... >> [...] Many features in many languages are easy to misunderstand,
>> including in C, and do sometimes require a closer look.
>
> You're right -- I'm sure there's a primitive rotate instruction in
> there somewhere that I'm just not seeing.

Yes, it's quite cunningly hidden:

unsigned rot(unsigned n, int m)
{
return n >> (32-m) | n << m;
}

If you can't write it portably, then you're making the point
that a primative rotate instruction is not part of C.
Is that what you're getting at ?

It is portable, in that it gets the same mathematical result anywhere
(well, if I'd used unsigned long, or 16 instead of 32 there). It also
can (and commonly is) optimised down to a single "rotate" machine
instruction, on platforms where that will get the correct mathematical
result (what would be the point of a new operator that *didn't* get the
same result everywhere? It'd be like another signed-right-shift).

- Kevin.

[Paul Hsieh]

aj*@andrew.cmu.edu says...

On Mon, 14 Jul 2003, pete wrote:

Kevin Easton wrote:

In comp.lang.c Paul Hsieh <qe*@pobox.com> wrote:
> You're right -- I'm sure there's a primitive rotate instruction in
> there somewhere that I'm just not seeing.

Yes, it's quite cunningly hidden:

unsigned rot(unsigned n, int m)
{
return n >> (32-m) | n << m;
}
If you can't write it portably,

[Note that he *could* have made it portable by clever use of UINT_MAX.]

That's not what he's missing. He's missing a couple of "& 31"'s (%32 would be
incorrect since they might output negative numbers.)

then you're making the point
that a primitive rotate instruction is not part of C.
Is that what you're getting at ?

Yes. His point, as I understand it, was two-fold: first, that since
the "rotate" opcode itself is not portable, it doesn't make sense to
include it in [portable] C; and second, that on platforms which have
a "rotate" opcode to use, any decent optimizer will take care of it
for you. So Paul's "efficiency" argument is bogus.

That's not true because ...
Tested on DJGPP and Linux gcc for Intel x86 (worked), and gcc for
Solaris 4.something (didn't).
.... WATCOM, Intel, and Microsoft all fail to do it (I highly doubt that Borland
does it either, but optimization and Borland are oxymorons.) Of course I don't
blame them, the source given does not imply that a rotate instruction is the
necessary output.
The details of specific optimizers and machine architectures are obviously
OT here, but it's also pretty clear that gcc -O3 doesn't need any help
from Paul, thankyouverymuch. ;-)

Gcc's ability to translate undefined code and make it into something useful is
legendary. But even if by some tragedy gcc becomes the defacto standard
compiler that everyone uses, the performance problems will only get *WORSE*,
not better.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sourceforge.net/

[Paul Hsieh]

In article <ne********************@tomato.pcug.org.au>, kevin@-nospam-
pcug.org.au says...

In comp.lang.c pete <pf*****@mindspring.com> wrote:

Kevin Easton wrote:

In comp.lang.c Paul Hsieh <qe*@pobox.com> wrote:
> co****@panix.com (Greg Comeau) wrote in message
> news:<be**********@panix5.panix.com>...

>> [...] Many features in many languages are easy to misunderstand,
>> including in C, and do sometimes require a closer look.
>
> You're right -- I'm sure there's a primitive rotate instruction in
> there somewhere that I'm just not seeing.

Yes, it's quite cunningly hidden:

unsigned rot(unsigned n, int m)
{
return n >> (32-m) | n << m;
}

If you can't write it portably, then you're making the point
that a primative rotate instruction is not part of C.
Is that what you're getting at ?

It is portable, in that it gets the same mathematical result anywhere
(well, if I'd used unsigned long, or 16 instead of 32 there).

The size is only one of your issues. The C standard does not guarantee
anything about shifting past the size of integer in bits. While you can make
an argument about not needing to shift an integer beyond its size in bits,
that's *NOT* true about rotates.
[...] It also can (and commonly is) [...]

Its not as common as you think.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sourceforge.net/

[Chris Torek]

In article <MP************************@news.sf.sbcglobal.ne t>
Paul Hsieh <qe*@pobox.com> writes:

If I want a platform specific rotate then I'll just write:

int rot(int,char);
#pragma aux rot = "rol eax, cl" parm [eax] [cl] value [eax];

thank you very much.

But this does not work at all -- I wanted a 24-bit rotate!

Seriously, has no one yet noticed that "rotate" is inherently a
three-input operation? We have the bit mask to rotate, the number
of bits in that bit mask, and the number of bits by which the rotate
should happen.

Of course, all this "rotate" stuff is a red herring; the *correct*
primitive is "funnel shift", which is a *four*-input operation
(left side, right side, number of bits in each side, and position
of selector). Rotation is obtained by making the left and right
sides identical, and barrel-shifting is obtained by making one of
"left side" or "right side" all-zero-bits.
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.

[Chris Dollin]

Chris Torek wrote:

Seriously, has no one yet noticed that "rotate" is inherently a
three-input operation? We have the bit mask to rotate, the number
of bits in that bit mask, and the number of bits by which the rotate
should happen.
As soon as one wants to implement bignums, one notices this.
Of course, all this "rotate" stuff is a red herring; the *correct*
primitive is "funnel shift", which is a *four*-input operation
(left side, right side, number of bits in each side, and position
of selector). Rotation is obtained by making the left and right
sides identical, and barrel-shifting is obtained by making one of
"left side" or "right side" all-zero-bits.

Could you expand on this? I'm guessing the effect is something like:

(leftSide in numBits bits) concatenate (rightSide in numBits bits)
then extractBits [from selectorPosition width numBits]

?

--
Chris "electric hedgehog" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgrou...mp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambl...me_to_clc.html

[Chris Torek]

>Chris Torek wrote:

Of course, all this "rotate" stuff is a red herring; the *correct*
primitive is "funnel shift", which is a *four*-input operation
(left side, right side, number of bits in each side, and position
of selector). Rotation is obtained by making the left and right
sides identical, and barrel-shifting is obtained by making one of
"left side" or "right side" all-zero-bits.

In article <bf**********@murdoch.hpl.hp.com>
Chris Dollin <ke**@hpl.hp.com> writes:Could you expand on this? I'm guessing the effect is something like:

(leftSide in numBits bits) concatenate (rightSide in numBits bits)
then extractBits [from selectorPosition width numBits]

?

Right. Using this primitive, we can get shifts, rotates, and
field-extractions within multiword values. For instance, if you
wants bits 27 through 38 inclusive, as a 12-bit sub-field within
a 64-bit number, you simply concatenate the left and right 32-bit
numbers and extract 12 bits at position 27.

Some CPUs have direct access to funnel shifters; others use them
internally to implement shifts, rotates, and extractions.

(Bitfield insertion still requires read/modify/writeback, no matter
what you do, though.)
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.

[Kevin Easton]

In comp.lang.c Paul Hsieh <qe*@pobox.com> wrote:

[e-mail] says...

In comp.lang.c Paul Hsieh <qe*@pobox.com> wrote:

> co****@panix.com (Greg Comeau) wrote:
>> [...] Many features in many languages are easy to misunderstand,
>> including in C, and do sometimes require a closer look.
>
> You're right -- I'm sure there's a primitive rotate instruction in
> there somewhere that I'm just not seeing.
Yes, it's quite cunningly hidden:

unsigned rot(unsigned n, int m)
{
return n >> (32-m) | n << m;
}

Odd ... this will not actually rotate the bits correctly. Consider rot(1, 80)
for example. Shift on Intel processors happen to mod the shift value by the
size of the word so it actually works. However, according to the ANSI C
standard, there is no requirement for it to do that. Technically, this code is
not portable.

Well, I didn't state the domain of the function (... m should be in the
range 0 to 31 inclusive for this 32 bit left rotate). Replacing the ms
with (m & 0x1f) and the "unsigned" with "unsigned long" is easy enough,
though, if that's what you want.

gcc -S foo.c
cat foo.s

rot:
pushl %ebp
movl %esp,%ebp
movl 12(%ebp),%ecx
movl 8(%ebp),%edx
roll %cl,%edx
movl %edx,%eax
jmp .L2
.p2align 4,,7
.L2:
leave
ret

Have a bit more faith in the optimiser!

But this is just a fluke. shifting beyond the size of the word in bits is not
well defined. So while its *legal* for GCC to output this code, there is no
guarantee that it, or any other compiler (even on machines with 32 bit
integers) will output code which performs a proper 32 bit rotate.

Since the expression, over the domain in which its behaviour *is*
defined, is completely simulated by this platform's hardware rol
instruction, we're entitled to expect that the optimiser should
recognize this. The behaviour of the hardware rol instruction outside
the domain in which the function has defined behaviour is of course of
no importance (to this optimisation).
If I want a platform specific rotate then I'll just write:

int rot(int,char);
#pragma aux rot = "rol eax, cl" parm [eax] [cl] value [eax];

The overarching point being, that if you did have a rotate left bitwise
operator in C (shift-expression |< additive-expression maybe?), then
it's mathematical behaviour would depend entirely on the width of the
type you're working in, which would in practice make it as useless as
signed right shifts.

On the other hand, the next revision of C should certainly include some
vector operations, which can be optimised easily to SIMD instructions on
platforms that have those.

- Kevin.

[Ron Natalie]

"Paul Hsieh" <qe*@pobox.com> wrote in message news:MP************************@news.sf.sbcglobal. net...

Odd ... this will not actually rotate the bits correctly. Consider rot(1, 80)
for example

Well, one might argue that rotates of values greater than the number of bits
are undefined behavior just as shifts are in C and C++.

[Jarno A Wuolijoki]

On Tue, 15 Jul 2003, Kevin Easton wrote:

Odd ... this will not actually rotate the bits correctly. Consider rot(1, 80)
for example. Shift on Intel processors happen to mod the shift value by the
size of the word so it actually works. However, according to the ANSI C
standard, there is no requirement for it to do that. Technically, this code is
not portable.

Well, I didn't state the domain of the function (... m should be in the
range 0 to 31 inclusive for this 32 bit left rotate). Replacing the ms
with (m & 0x1f) and the "unsigned" with "unsigned long" is easy enough,
though, if that's what you want.

Problem: while gcc can indeed rewrite x>>n|x<<32-n as a rotate, it doesn't
remove the &31 in x>>(n&31).

I mean really: play nice and add the &31 there making it portable just
to see it actually performs the no-op. sigh.

BTW, ITYM 1 to 31 inclusive.

[Arthur J. O'Dwyer]

On Tue, 15 Jul 2003, Paul Hsieh wrote:

In article <bf**********@elf.eng.bsdi.com>, no****@elf.eng.bsdi.com says...

Paul Hsieh <qe*@pobox.com> writes:

If I want a platform specific rotate then I'll just write:

int rot(int,char);
#pragma aux rot = "rol eax, cl" parm [eax] [cl] value [eax];

thank you very much.
But this does not work at all -- I wanted a 24-bit rotate!
More likely 28. ;-)
Seriously, has no one yet noticed that "rotate" is inherently a
three-input operation? We have the bit mask to rotate, the number
of bits in that bit mask, and the number of bits by which the rotate
should happen.

Of course, all this "rotate" stuff is a red herring; the *correct*
primitive is "funnel shift", which is a *four*-input operation
(left side, right side, number of bits in each side, and position
of selector). Rotation is obtained by making the left and right
sides identical, and barrel-shifting is obtained by making one of
"left side" or "right side" all-zero-bits.

Your ill attempt at humor is [a non sequitur].

Not really humor. More like a technical description of the semantics
of the family of operations you've been calling "shift" and "rotate."
It's perfectly true that x86-style fixed-width rotate instructions
are fairly useless, compared to the "funnel shift" operation Chris
describes. Of course, with more than two inputs it's hard to make
this operation a primitive "operator" in C; that's why you don't want
to think about it. I still haven't figured out why you really *want*
a (or several) "rotate operator(s)" when an inline function is just
as fast, and can take the multiple inputs it needs to do the job right,
plus specializations for values of 'n' or 'b' that are easy to do
on whatever architecture you're targeting.
Ordinary rotates happen a lot.
Define "ordinary." Do you perhaps mean "32-bit rotates, with the
right-hand operator truncated modulo 32 and stored in the CL register"?
(--Now, that *was* an ill attempt at humor.)
Name me one feistel crypto algorithm that *DOESN'T* use a rotate. DES,
BlowFish, MD5, they *all* use rotate.

Blowfish does not use a rotate.
http://www.counterpane.com/bfdobsoyl.html

DES uses a 28-bit rotate.
http://www.aci.net/kalliste/des.htm

MD5 actually does use a 32-bit rotate. Congrats!
http://www.ietf.org/rfc/rfc1321.txt

[I am not a cryptography expert.]
-Arthur

[Paul Hsieh]

jw******@cs.Helsinki.FI says...

On Tue, 15 Jul 2003, Kevin Easton wrote:

Odd ... this will not actually rotate the bits correctly. Consider rot(1, 80)
for example. Shift on Intel processors happen to mod the shift value by the
size of the word so it actually works. However, according to the ANSI C
standard, there is no requirement for it to do that. Technically, this code is
not portable.

Well, I didn't state the domain of the function (... m should be in the
range 0 to 31 inclusive for this 32 bit left rotate). Replacing the ms
with (m & 0x1f) and the "unsigned" with "unsigned long" is easy enough,
though, if that's what you want.

Problem: while gcc can indeed rewrite x>>n|x<<32-n as a rotate, it doesn't
remove the &31 in x>>(n&31).

I mean really: play nice and add the &31 there making it portable just
to see it actually performs the no-op. sigh.

None of my compilers, including one extremely state of the art one (Intel C++),
fails to perform this transformation regardless of what I do. There is an
outside chance that by 2005 this compiler will pick up this capability, but
that's another story ...

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sourceforge.net/

[Morris Dovey]

Ron Natalie wrote:

"Paul Hsieh" <qe*@pobox.com> wrote in message news:MP************************@news.sf.sbcglobal. net...

Odd ... this will not actually rotate the bits correctly. Consider rot(1, 80)
for example

Well, one might argue that rotates of values greater than the number of bits
are undefined behavior just as shifts are in C and C++.

Or one might just argue the opposite. Are you worried that the
CPU will become dizzy after some arbitrary number of bits rotation?

8^)
--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c

[Paul Hsieh]

qe*@pobox.com says...

jw******@cs.Helsinki.FI says...

On Tue, 15 Jul 2003, Kevin Easton wrote:

Well, I didn't state the domain of the function (... m should be in the
range 0 to 31 inclusive for this 32 bit left rotate). Replacing the ms
with (m & 0x1f) and the "unsigned" with "unsigned long" is easy enough,
though, if that's what you want.

Problem: while gcc can indeed rewrite x>>n|x<<32-n as a rotate, it doesn't
remove the &31 in x>>(n&31).

I mean really: play nice and add the &31 there making it portable just
to see it actually performs the no-op. sigh.

None of my compilers, including one extremely state of the art one (Intel C++),
fails to perform this transformation regardless of what I do.

Sorry, I meant to write that *ALL* of my compilers fail to do this
transformation. I don't have/use gcc or its variants, so I can't verify that
one way or another.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sourceforge.net/

[Paul Hsieh]

ro*@sensor.com says...

"Paul Hsieh" <qe*@pobox.com> wrote:

Odd ... this will not actually rotate the bits correctly. Consider rot(1, 80)
for example

Well, one might argue that rotates of values greater than the number of bits
are undefined behavior just as shifts are in C and C++.

You can, but you'd be wrong. Rotations are operations which form a
mathematical object called a "group" -- but this is really only true if the
rotation index is unrestricted, or equivalently that the modulo on the rotation
index is applied. This is not true of shifts, which is why the argument is
different.

In essence, ror(ror(a,b),c) should be simplifiable to ror(a,b+c) without
question. (I could argue for different kinds properties for shifts, but they
are not the same as this one, and obviously the ANSI C committee isn't
concerned about such things.)

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sourceforge.net/

[Chris Torek]

>ro*@sensor.com says...

Well, one might argue that rotates of values greater than the number of bits
are undefined behavior just as shifts are in C and C++.

In article <MP************************@news.sf.sbcglobal.ne t>
Paul Hsieh <qe*@pobox.com> writes:You can, but you'd be wrong. Rotations are operations which form a
mathematical object called a "group" -- but this is really only true
if the rotation index is unrestricted, or equivalently that the modulo
on the rotation index is applied.
Yes, but -- mod WHAT?
In essence, ror(ror(a,b),c) should be simplifiable to ror(a,b+c) without
question.

Only if the number of bits being rotated matches.

In particular, if you want to do a 28-bit "rotation by 4", followed
by a 16-bit "rotation by 4", you *cannot* simply do a 28-bit rotation
by 8. (You will get the wrong answer.)

Note that in assembly, we might write:

ror.l %r1,6
rol.w %r1,4

to take a 32-bit input value in register 1 of the form:

abcdefgh.ijklmnop.qrstuvwx.yzABCDEF

and get:

ABCDEFab.cdefghij.opqrstuv.wxyzklmn

(where each letter represents a single bit).

Of course, as I noted earlier, I would rather have a funnel-shift
operation than merely a rotate operation.
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.

[Giuseppe]

>But how implement operator+ *without a copy* in a C++ class, or in C?

class num1 (if I read well) doesn't use copy (I use &) but don't work
because if I do
num1 x, a("100"), b("777");
x= a*b;
although inside operator* seems to be ok in operator= is KO. Why?
class num10 seems ok;

class num10{
friend int operator==(const num10& a, const num10& b);
friend int operator<( const num10& a, const num10& b);
friend int operator>( const num10& a, const num10& b);
friend int operator<=(const num10& a, const num10& b);
friend int operator>=(const num10& a, const num10& b);
friend int operator!=(const num10& a, const num10& b);

friend int operator==(const num10& a, unsigned b);
friend int operator<( const num10& a, unsigned b);
friend int operator>( const num10& a, unsigned b);
friend int operator<=(const num10& a, unsigned b);
friend int operator>=(const num10& a, unsigned b);
friend int operator!=(const num10& a, unsigned b);

friend int operator==(unsigned a, const num10& b);
friend int operator<( unsigned a, const num10& b);
friend int operator>( unsigned a, const num10& b);
friend int operator<=(unsigned a, const num10& b);
friend int operator>=(unsigned a, const num10& b);
friend int operator!=(unsigned a, const num10& b);

friend num10 operator+( const num10& a, const num10& b);
friend num10 operator+( const num10& a, unsigned b);
friend num10 operator+( unsigned b, const num10& a);

friend num10 operator-( const num10& a, const num10& b);
friend num10 operator-( const num10& a, unsigned b);
friend num10 operator-( unsigned b, const num10& a);

friend num10 operator*( const num10& a, const num10& b);
friend num10 operator*( const num10& a, unsigned b);
friend num10 operator*( unsigned b, const num10& a);

friend num10 operator/( const num10& a, const num10& b);
friend num10 operator/( const num10& a, unsigned b);
friend num10 operator/( unsigned b, const num10& a);

friend num10 operator%( const num10& a, const num10& b);
friend num10 operator%( const num10& a, unsigned b);
friend num10 operator%( unsigned b, const num10& a);
friend int resize( unsigned len);

friend void pr_num( const num10& a );
public :
num10();
num10(unsigned len);
num10(const char a[]);
num10(num10& r);
num10& operator=(const num10& r);
num10& operator=(unsigned r);
~num10();

numero* nume() { R &numer; }

unsigned char* ricon1();
void print();

private:
numero numer;
unsigned lung;
};

class num1{
friend int operator==(const num1& a, const num1& b);
friend int operator<( const num1& a, const num1& b);
friend int operator>( const num1& a, const num1& b);
friend int operator<=(const num1& a, const num1& b);
friend int operator>=(const num1& a, const num1& b);
friend int operator!=(const num1& a, const num1& b);

friend int operator==(const num1& a, unsigned b);
friend int operator<( const num1& a, unsigned b);
friend int operator>( const num1& a, unsigned b);
friend int operator<=(const num1& a, unsigned b);
friend int operator>=(const num1& a, unsigned b);
friend int operator!=(const num1& a, unsigned b);

friend int operator==(unsigned a, const num1& b);
friend int operator<( unsigned a, const num1& b);
friend int operator>( unsigned a, const num1& b);
friend int operator<=(unsigned a, const num1& b);
friend int operator>=(unsigned a, const num1& b);
friend int operator!=(unsigned a, const num1& b);

friend num1& operator+( const num1& a, const num1& b);
friend num1& operator+( const num1& a, unsigned b);
friend num1& operator+( unsigned b, const num1& a);

friend num1& operator-( const num1& a, const num1& b);
friend num1& operator-( const num1& a, unsigned b);
friend num1& operator-( unsigned b, const num1& a);

friend num1& operator*( const num1& a, const num1& b);
friend num1& operator*( const num1& a, unsigned b);
friend num1& operator*( unsigned b, const num1& a);

friend num1& operator/( const num1& a, const num1& b);
friend num1& operator/( const num1& a, unsigned b);
friend num1& operator/( unsigned b, const num1& a);

friend num1& operator%( const num1& a, const num1& b);
friend num1& operator%( const num1& a, unsigned b);
friend num1& operator%( unsigned b, const num1& a);

friend int resize1( unsigned len);
friend num10 conv(const num1& a);
friend num1& sqrt(const num1& a);
friend num1& gcd (const num1& a, const num1& b);

public :
num1();
num1(unsigned len);
num1(const char a[]);
num1(num1& r);

num1& operator=(num1* r);
num1& operator=(const num1& r);
num1& operator=(unsigned r);
~num1();

void print();
void prin();
void casuale(unsigned len);

private:
num_s numer;
unsigned lung;
};

[Giuseppe]

gi******@giuseppe.wwwew (Giuseppe) wrote:

But how implement operator+ *without a copy* in a C++ class, or in C?

class num1 (if I read well) doesn't use copy (I use &) but don't work
because if I do
num1 x, a("100"), b("777");
x= a*b;
although inside operator* seems to be ok in operator= is KO. Why?
class num10 seems ok;

"fixed"
because a*b have a result more large than a and b the operator= call
resize1 to resize the "static" buffers for the new max_dim and in
resize1(). I forgot to copy the 5 tmp numbers of the buffer (I use tmp
numbers in expressions when I call + * \ -. Does The number of tmp
buffers depend of the number of "(" ")" ?)
Thanks

if I have

int z=0

is right

int& f()
{z=7;
return z;
}

or

int z=0
is right
int& f()
{z=7;
return (int&) z;
}

or

int& f()
{int& u=z
u=7;
return u;
}

?

[Dave Thompson]

On Tue, 15 Jul 2003 09:18:49 GMT, qe*@pobox.com (Paul Hsieh) wrote:

aj*@andrew.cmu.edu says... <about supposedly idiomatic rotate>

> unsigned rot(unsigned n, int m)
> {
> return n >> (32-m) | n << m;
> }

<snip> [Note that he *could* have made it portable by clever use of UINT_MAX.]

That's not what he's missing. He's missing a couple of "& 31"'s (%32 would be
incorrect since they might output negative numbers.)

Assuming unsigned is 32 bits, or you use uint32_t or equivalent.

% 32U would be safe, and have the putative advantage of generalizing
to machines with non-power-of-two word sizes, if anyone ever starts
making them again, as well as being a slightly more direct
representation of the programmer's actual intent.

<snip> Gcc's ability to translate undefined code and make it into something useful is
legendary. But even if by some tragedy gcc becomes the defacto standard
compiler that everyone uses, the performance problems will only get *WORSE*,
not better.

Of course in this case the code is still *correct* even if not
optimized as by gcc to an actual rotate instruction.

- David.Thompson1 at worldnet.att.net