Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Unsigned types are DANGEROUS??

Reply
Thread Tools

Unsigned types are DANGEROUS??

 
 
Ian Collins
Guest
Posts: n/a
 
      03-28-2011
On 03/29/11 12:04 PM, Leigh Johnston wrote:
> On 28/03/2011 23:20, James Kanze wrote:
>>
>> It's a question of expectations, not a language issue, nor a
>> techical issue. The expectations of most programmers I've met
>> (and practically all I've worked with) are that unsigned means
>> bitwise or modulo. I've also pointed out where those
>> expectations come from.
>>

>
> Again you are uttering nonsense (or bullshit: you choose); unsigned
> types are not just for "bitwise or modulo": std::size_t is an unsigned
> type and is used to represent sizes and indices; char can be an unsigned
> type and char is used for representing string characters.


Wow, is this argument still going on?

I think I'll go back to clearing earthquake debris...

--
Ian Collins
 
Reply With Quote
 
 
 
 
Michael Doubez
Guest
Posts: n/a
 
      03-29-2011
On 29 mar, 01:04, Leigh Johnston <(E-Mail Removed)> wrote:
> On 28/03/2011 23:20, James Kanze wrote:
>
>
>
>
>
>
>
>
>
> > On Mar 26, 4:55 pm, "MikeP"<(E-Mail Removed)> *wrote:
> >> James Kanze wrote:
> >>> On Mar 23, 9:51 am, Michael Doubez<(E-Mail Removed)> *wrote:
> >>>> On 22 mar, 18:04, Leigh Johnston<(E-Mail Removed)> *wrote:

>
> >>> * * [...]
> >>>> Using unsigned to indicate the parameter must be positive

>
> >>> Is not a valid argument for anything, unless the valid range is
> >>> exactlyl [0...UINT_MAX]. *C++ doesn't have ranged integral
> >>> types, so you have to make do. *Any type which will hold the
> >>> desired range is equally good from that point of view, and the
> >>> type of an argument can never be assumed to tell you anything
> >>> about the range.

>
> >>> Suppose I want to represent the value of a six sided die which
> >>> has been thrown. *The legal range is 1...6. *Which type,
> >>> unsigned or int, tells me more about this? *The answer, of
> >>> course, is neither.

>
> >> Focusing on an exact range is a strawman, for it is not relevant to the
> >> discussion of the relative semantic value of using signed or unsigned.

>
> > Which is exactly what I said. *Arguments concerning the range
> > are vacuous, since C++ doesn't support ranged variables.

>
> >> Any suggestion that unsigned does not give more meaning than
> >> signed (when signed is used to represent variables that cannot
> >> be negative) is, of course, incorrect.

>
> > But it doesn't give any additional useful information, in most
> > cases.

>
> >> Using signed for the die value gives rise to questions
> >> about what kind of concoction the programmer developed where a die value
> >> CAN be negative.

>
> > No. *In the places I've worked, using unsigned for the die value
> > gives rise to questions as to why the programmer wanted modulo
> > arithmetic, or what sort of bitwise operations he had in mind.

>
> > It's a question of expectations, not a language issue, nor a
> > techical issue. *The expectations of most programmers I've met
> > (and practically all I've worked with) are that unsigned means
> > bitwise or modulo. *I've also pointed out where those
> > expectations come from.

>
> Again you are uttering nonsense (or bullshit: you choose); unsigned
> types are not just for "bitwise or modulo": std::size_t is an unsigned
> type and is used to represent sizes and indices; char can be an unsigned
> type and char is used for representing string characters.


IMO, the fact that a size type is used for indices is part of the
problem. Shouldn't it be an index type ?
An index is likely to be computed and eventually become negative at
some point (when computing a difference); so it should be a signed
type

But we want to compare an index to a size, that led to having index
type the same as size type.

I would have prefered the other way around: the size type same as
index type - i.e signed.

--
Michael
 
Reply With Quote
 
 
 
 
werasm
Guest
Posts: n/a
 
      03-29-2011
On Mar 12, 11:35*pm, "MikeP" <(E-Mail Removed)> wrote:
> If you investigate the tcmalloc code (by Google), you will find the
> following warning:
>
> // NOTE: unsigned types are DANGEROUS in loops and other arithmetical
> // places. Use the signed types unless your variable represents a bit
> // pattern (eg a hash value) or you really need the extra bit. Do NOT
> // use 'unsigned' to express "this value should always be positive";
> // use assertions for this.
>
> Is it just their idiom? What's the problem with using unsigned ints in
> loops (it seems natural to do so)? Are C++ unsigned ints "broken"
> somehow?


This reminds me of a little piece of code that bit me recently (it
crashed):

void ScanPatternDataMdl::moveCursorToNextPeak( double& cursor )
{
bool peakFound = false;
for( size_t i = 0; !peakFound && (i < peakGraphData_->size()); ++i )
{
double peakX = peakGraphData_->x( i );
peakFound = (peakX > cursor);
if( peakFound ){ cursor = peakX; }
}
}
void ScanPatternDataMdl::moveCursorToPrevPeak( double& cursor )
{
bool peakFound = false;
for( size_t i = peakGraphData_->size()-1; !peakFound && (i >= 0); --
i )
{
double peakX = peakGraphData_->x( i );
peakFound = (peakX < cursor);
if( peakFound ){ cursor = peakX; }
}
}

Spot the bug??? Using unsigned types are certainly not symmetrical
in their use. I prefer signed but used unsigned in this case
(ignorantly)
as I wanted to hush the compiler warning (in the increment case).

I'd say the only reason for using unsigned types would be if the
signed
range cannot hold the value required.

Kind regards,

Werner

 
Reply With Quote
 
Michael Doubez
Guest
Posts: n/a
 
      03-29-2011
On 29 mar, 13:45, Leigh Johnston <(E-Mail Removed)> wrote:
> On 29/03/2011 08:33, Michael Doubez wrote:
>
>
>
>
>
>
>
>
>
> > On 29 mar, 01:04, Leigh Johnston<(E-Mail Removed)> *wrote:
> >> On 28/03/2011 23:20, James Kanze wrote:

>
> >>> On Mar 26, 4:55 pm, "MikeP"<(E-Mail Removed)> * *wrote:
> >>>> James Kanze wrote:
> >>>>> On Mar 23, 9:51 am, Michael Doubez<(E-Mail Removed)> * *wrote:
> >>>>>> On 22 mar, 18:04, Leigh Johnston<(E-Mail Removed)> * *wrote:

>
> >>>>> * * *[...]
> >>>>>> Using unsigned to indicate the parameter must be positive

>
> >>>>> Is not a valid argument for anything, unless the valid range is
> >>>>> exactlyl [0...UINT_MAX]. *C++ doesn't have ranged integral
> >>>>> types, so you have to make do. *Any type which will hold the
> >>>>> desired range is equally good from that point of view, and the
> >>>>> type of an argument can never be assumed to tell you anything
> >>>>> about the range.

>
> >>>>> Suppose I want to represent the value of a six sided die which
> >>>>> has been thrown. *The legal range is 1...6. *Which type,
> >>>>> unsigned or int, tells me more about this? *The answer, of
> >>>>> course, is neither.

>
> >>>> Focusing on an exact range is a strawman, for it is not relevant to the
> >>>> discussion of the relative semantic value of using signed or unsigned.

>
> >>> Which is exactly what I said. *Arguments concerning the range
> >>> are vacuous, since C++ doesn't support ranged variables.

>
> >>>> Any suggestion that unsigned does not give more meaning than
> >>>> signed (when signed is used to represent variables that cannot
> >>>> be negative) is, of course, incorrect.

>
> >>> But it doesn't give any additional useful information, in most
> >>> cases.

>
> >>>> Using signed for the die value gives rise to questions
> >>>> about what kind of concoction the programmer developed where a die value
> >>>> CAN be negative.

>
> >>> No. *In the places I've worked, using unsigned for the die value
> >>> gives rise to questions as to why the programmer wanted modulo
> >>> arithmetic, or what sort of bitwise operations he had in mind.

>
> >>> It's a question of expectations, not a language issue, nor a
> >>> techical issue. *The expectations of most programmers I've met
> >>> (and practically all I've worked with) are that unsigned means
> >>> bitwise or modulo. *I've also pointed out where those
> >>> expectations come from.

>
> >> Again you are uttering nonsense (or bullshit: you choose); unsigned
> >> types are not just for "bitwise or modulo": std::size_t is an unsigned
> >> type and is used to represent sizes and indices; char can be an unsigned
> >> type and char is used for representing string characters.

>
> > IMO, the fact that a size type is used for indices is part of the
> > problem. Shouldn't it be an index type ?
> > An index is likely to be computed and eventually become negative at
> > some point (when computing a difference); so it should be a signed
> > type

>
> No; size_type is used for indices and difference_type is used for ..
> wait for it.. differences.


Between iterator. Which is much help at this point.

Does the standard guarantee that difference_type works in all case
with size_t ?


> > But we want to compare an index to a size, that led to having index
> > type the same as size type.

>
> > I would have prefered the other way around: the size type same as
> > index type - i.e signed.

>
> Your personal preferences are not really relevant; what is relevant are
> the idioms that have been standardized by the C++ Standard.


Like vector<bool>, valarray<> and auto_ptr<> ?

--
Michael


 
Reply With Quote
 
xiilin
Guest
Posts: n/a
 
      03-30-2011
MikeP wrote:
> If you investigate the tcmalloc code (by Google), you will find the
> following warning:
>
> // NOTE: unsigned types are DANGEROUS in loops and other arithmetical
> // places. Use the signed types unless your variable represents a bit
> // pattern (eg a hash value) or you really need the extra bit. Do NOT
> // use 'unsigned' to express "this value should always be positive";
> // use assertions for this.
>
> Is it just their idiom? What's the problem with using unsigned ints in
> loops (it seems natural to do so)? Are C++ unsigned ints "broken"
> somehow?



"for (i = 0; i <100; i++)"may written as "for (i = 99 ; i > 0; i--) "
when u want to search from end to start place, if "i" is a signed
type, it gets no problems, but if the"i"is an unsigned type, which
will be an endless loop.

Some hidden overflow may happened, so "unsigned types are DANGEROUS in
loops and other arithmetical places."

Sorry for my terrible English.
 
Reply With Quote
 
werasm
Guest
Posts: n/a
 
      03-30-2011
On Mar 30, 6:14*am, xiilin <(E-Mail Removed)> wrote:
> MikeP wrote:
> > If you investigate the tcmalloc code (by Google), you will find the
> > following warning:

>
> > // NOTE: unsigned types are DANGEROUS in loops and other arithmetical
> > // places. Use the signed types unless your variable represents a bit
> > // pattern (eg a hash value) or you really need the extra bit. Do NOT
> > // use 'unsigned' to express "this value should always be positive";
> > // use assertions for this.

>
> > Is it just their idiom? What's the problem with using unsigned ints in
> > loops (it seems natural to do so)? Are C++ unsigned ints "broken"
> > somehow?

>
> "for (i = 0; i <100; i++)"may written as "for (i = 99 ; i > 0; i--) "


"for (i = 0; i <100; ++i)"may written as "for (i = 99 ; i >= 0; --i)

I suppose using pre -increment -decrement could be considered
pedantic. The "i >=0" is correct, as the expression is only executed
after the statement (see par 6.5.3 of the working draft).

>> if "i" is a signed
>> type, it gets no problems, but if the"i"is an unsigned type, which
>> will be an endless loop.


My point exactly...

Regards,

Werner
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
(int) -> (unsigned) -> (int) or (unsigned) -> (int) -> (unsigned):I'll loose something? pozz C Programming 12 03-20-2011 11:32 PM
unsigned long to unsigned char ashtonn@gmail.com Python 1 06-01-2005 07:00 PM
comparing unsigned long and unsigned int sridhar C Programming 6 11-03-2004 03:52 AM
unsigned int const does not match const unsigned int Timo Freiberger C++ 3 10-30-2004 07:02 PM
Assigning unsigned long to unsigned long long George Marsaglia C Programming 1 07-08-2003 05:16 PM



Advertisments