Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > size_t problems

Reply
Thread Tools

size_t problems

 
 
Flash Gordon
Guest
Posts: n/a
 
      09-07-2007
Malcolm McLean wrote, On 07/09/07 21:58:
>
> "Flash Gordon" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)-gordon.me.uk...
>> Malcolm McLean wrote, On 06/09/07 21:03:
>>>

>> our 10 servers that is another 5000UKP. Will you give us that 5000UKP
>> to cover the increased costs you want to force on us? We are only a
>> small company, our customers will find there costs increased by rather
>> more. That is assuming your are write that it will have only a small
>> impact on performance, if everyone else is write you will have to give
>> us a lot more money!
>>

> Ten thousand pounds, or twenty thousand UD dollars, is by business
> standards quite a small amount of money.


We are a small company. In any case, why should we bare the costs for
*your* ideas and wants?

> If you are at all typical your
> costs are not in the hardware,


This year HW is a significant cost, so significant that we are having to
borrow the money to do it.

BTW, I was understating the real costs, those would be much higher since
we have already bought the replacement HW and would have to upgrade it.

> which in any case doubles in speed and
> capacity every eighteen months or so, but in the software.


The existing HW is failing NOW. If we wait 18 months, or even 6 months,
we could have lost out entire customer base for half of our products.
--
Flash Gordon
 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      09-08-2007
Tor Rustad wrote:
>

.... snip ...
>
> so your replacement reads:
>
> j = 7;
> do {
> if ( (bitmap[i] >> j) & 1 )
> {
> has_field[k] = TRUE;
> }
> else
> {
> has_field[k] = FALSE;
> }
> ++k;
> } while (j--);
>
> To me, the first option is more readable by far. for(...) loops
> are excellent for looping over an index, doing the same with
> while(..) and do while(...) loops, gives me headache.


Note the simplicity of:

j = 7;
do {
has_field[k++] = (bitmap[i] >> j) & 1;
} while (j--);

which obviously executes for j = 7, 6, ... 0 and stops.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>


--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
 
 
 
Tor Rustad
Guest
Posts: n/a
 
      09-08-2007
CBFalconer wrote:
> Tor Rustad wrote:
> ... snip ...
>> so your replacement reads:
>>
>> j = 7;
>> do {
>> if ( (bitmap[i] >> j) & 1 )
>> {
>> has_field[k] = TRUE;
>> }
>> else
>> {
>> has_field[k] = FALSE;
>> }
>> ++k;
>> } while (j--);
>>
>> To me, the first option is more readable by far. for(...) loops
>> are excellent for looping over an index, doing the same with
>> while(..) and do while(...) loops, gives me headache.

>
> Note the simplicity of:
>
> j = 7;
> do {
> has_field[k++] = (bitmap[i] >> j) & 1;
> } while (j--);
>
> which obviously executes for j = 7, 6, ... 0 and stops.


Sorry, I don't find your *style* an easy read, we clearly differ in
opinions on this, you might get away with a one-liner, but my basic
point still stands. Even in the above compressed version, I find this
more readable:

for(j=7; j>=0; j--)
{
has_field[k++] = (bitmap[i] >> j) & 1;
}

When looping over a known range (j = 7, 6, ... 0), the natural choice is
to use for loops. When not knowing in advance the number of iterations,
that's when while() and do while() loops comes into play.


"To this day, many C programmers believe that 'strong typing' just means
pounding extra hard on the keyboard."
-Peter van der Linden, "Expert C Programming"


So what is "wrong" with:

has_field[k++] = (bitmap[i] >> j) & 1;

?

'has_field' has a boolean type, which was typedef'ed elsewhere together
with the TRUE and FALSE macros. So not only have you hard-coded the
values of TRUE and FALSE, but also assume LHS and RHS will have the same
type.


--
Tor <torust [at] online [dot] no>
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      09-08-2007
Tor Rustad wrote:
> CBFalconer wrote:
>> Tor Rustad wrote:
>>
>> ... snip ...
>>
>>> so your replacement reads:
>>>
>>> j = 7;
>>> do {
>>> if ( (bitmap[i] >> j) & 1 )
>>> {
>>> has_field[k] = TRUE;
>>> }
>>> else
>>> {
>>> has_field[k] = FALSE;
>>> }
>>> ++k;
>>> } while (j--);
>>>
>>> To me, the first option is more readable by far. for(...) loops
>>> are excellent for looping over an index, doing the same with
>>> while(..) and do while(...) loops, gives me headache.

>>
>> Note the simplicity of:
>>
>> j = 7;
>> do {
>> has_field[k++] = (bitmap[i] >> j) & 1;
>> } while (j--);
>>
>> which obviously executes for j = 7, 6, ... 0 and stops.

>
> Sorry, I don't find your *style* an easy read, we clearly differ
> in opinions on this, you might get away with a one-liner, but my
> basic point still stands. Even in the above compressed version,
> I find this more readable:
>
> for(j=7; j>=0; j--)
> {
> has_field[k++] = (bitmap[i] >> j) & 1;
> }


That won't work. The original of this was to implement the loop
with unsigned loop variables, so the >= 0 test is always true.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>


--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
Tor Rustad
Guest
Posts: n/a
 
      09-08-2007
CBFalconer wrote:
> Tor Rustad wrote:


[...]

>> for(j=7; j>=0; j--)
>> {
>> has_field[k++] = (bitmap[i] >> j) & 1;
>> }

>
> That won't work. The original of this was to implement the loop
> with unsigned loop variables, so the >= 0 test is always true.


I fixed *my* bug a long time ago, by using

int j;

--
Tor <torust [at] online [dot] no>
 
Reply With Quote
 
Kelsey Bjarnason
Guest
Posts: n/a
 
      09-09-2007
[snips]

On Fri, 07 Sep 2007 21:58:28 +0100, Malcolm McLean wrote:

> "Flash Gordon" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)-gordon.me.uk...
>> Malcolm McLean wrote, On 06/09/07 21:03:
>>>

>> our 10 servers that is another 5000UKP. Will you give us that 5000UKP to
>> cover the increased costs you want to force on us? We are only a small
>> company, our customers will find there costs increased by rather more.
>> That is assuming your are write that it will have only a small impact on
>> performance, if everyone else is write you will have to give us a lot more
>> money!
>>

> Ten thousand pounds, or twenty thousand UD dollars, is by business standards
> quite a small amount of money.


Yet since the cost would be for *no* purpose other than to make *you*
happy, you should be the one to pay it. For every company, every person,
every organization which has to increase their hardware costs just to meet
your weird little preferences.

Going to fork over the dough? No, thought not.

Increased costs where there is a justification for them is generally
acceptable. Making Malcolm happy is not a justification for such costs.
 
Reply With Quote
 
David Thompson
Guest
Posts: n/a
 
      09-16-2007
On Thu, 30 Aug 2007 18:53:48 -0700, Keith Thompson <(E-Mail Removed)>
wrote:
<snip>
> "const" in a parameter declaration doesn't do anything useful for the
> caller, since (as I'm sure you know) a function can't modify an
> argument anyway. It does prevent the function from (directly)
> modifying its own parameter (a local object), but that's of no concern
> to the caller.
>
> It would make more sense to be able to specify "const" in the
> *definition* of a function but not in the *declaration*. And gcc
> seems to allow this:
>
> int foo(int x);

<snip>
> int foo(const int x)
> {
> return x;
> }
>
> but I'm not sure whether it's actually legal. In any case, it's not a
> style that seems to be common.
>

It is. C99 6.7.5.3p15 not significantly changed from C90 6.5.4.3:
For two function types to be compatible, both shall specify compatible
return types.
Moreover, the parameter type lists, if both are present, shall agree
in the number of
parameters and in use of the ellipsis terminator; corresponding
parameters shall have
compatible types. <snip stuff about oldstyle vs newstyle>
(In the determination of type
compatibility and of a composite type, each parameter declared with
function or array
type is taken as having the adjusted type and each parameter declared
with qualified type
is taken as having the unqualified version of its declared type.)

Thus the definition is compatible with the declaration (and vice
versa), so no constraint is violated, and calls must work. (Assuming
no CV or UB elsewhere, of course.)

OTOH I have encountered a compiler that got this wrong -- IIRC (some
version of) AIX xlc. Plus, it provides IMJ very little benefit.

- formerly david.thompson1 || achar(64) || worldnet.att.net
 
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
reinterpret_cast<std::size_t>(p) and reinterpret_cast<std::size_t&>() Alex Vinokur C++ 1 02-06-2011 07:48 AM
Casting from const pair<const unsigned char*, size_t>* to constpair<unsigned char*, size_t>* Alex Vinokur C++ 9 10-13-2008 05:05 PM
Re: for(size_t a=begin();a!=end();++a){} Chris \( Val \) C++ 2 07-14-2003 06:31 AM
Re: size_t ... standards Howard Hinnant C++ 5 06-30-2003 07:22 PM
Re: size_t ... standards Howard Hinnant C++ 0 06-29-2003 05:45 PM



Advertisments