Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #15924 > unrolled thread

Am I being too C++ like?

Back to article view | Back to comp.lang.c

Contents

  Am I being too C++ like? nroberts <roberts.noah@gmail.com> - 2012-01-18 13:53 -0800
    Re: Am I being too C++ like? Shao Miller <sha0.miller@gmail.com> - 2012-01-18 18:50 -0500
      Re: Am I being too C++ like? Nobody <nobody@nowhere.com> - 2012-01-19 04:13 +0000
      Re: Am I being too C++ like? ImpalerCore <jadill33@gmail.com> - 2012-01-19 09:09 -0800
    Re: Am I being too C++ like? Philip Lantz <prl@canterey.us> - 2012-01-18 21:42 -0800
    Re: Am I being too C++ like? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-19 12:30 +0000
      Re: Am I being too C++ like? "BartC" <bc@freeuk.com> - 2012-01-19 15:17 +0000
        Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-01-19 18:44 -0800
          Re: Am I being too C++ like? "BartC" <bc@freeuk.com> - 2012-01-20 13:44 +0000
            Re: Am I being too C++ like? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-20 09:08 -0500
              Re: Am I being too C++ like? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-20 07:58 -0800
              Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-01-20 11:25 -0800
              Re: Am I being too C++ like? Kleuske <kleuske@nowhere.net> - 2012-01-20 20:17 +0000
                Re: Am I being too C++ like? Ian Collins <ian-news@hotmail.com> - 2012-01-21 09:23 +1300
                  Re: Am I being too C++ like? Kleuske <kleuske@nowhere.net> - 2012-01-20 22:00 +0000
                  Re: Am I being too C++ like? Stephen Sprunk <stephen@sprunk.org> - 2012-01-20 16:28 -0600
                    Re: Am I being too C++ like? Ian Collins <ian-news@hotmail.com> - 2012-01-21 11:43 +1300
                    Re: Am I being too C++ like? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-20 18:02 -0500
                    Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-01-20 16:12 -0800
                      Re: Am I being too C++ like? Kaz Kylheku <kaz@kylheku.com> - 2012-01-21 00:13 +0000
                        Re: Am I being too C++ like? William Ahern <william@wilbur.25thandClement.com> - 2012-01-20 17:37 -0800
                          Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-01-20 22:25 -0800
                            Re: Am I being too C++ like? gazelle@shell.xmission.com (Kenny McCormack) - 2012-01-21 16:07 +0000
                              Re: Am I being too C++ like? Bill Reid <hormelfree@gmail.com> - 2012-01-23 17:26 -0800
                          Re: Am I being too C++ like? Kaz Kylheku <kaz@kylheku.com> - 2012-01-21 18:00 +0000
                            Re: Am I being too C++ like? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-21 21:25 +0000
                              Re: Am I being too C++ like? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-02-11 23:46 +0200
                                Re: Am I being too C++ like? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-11 22:56 +0000
                                  Re: Am I being too C++ like? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-02-22 02:34 +0200
                            Re: Am I being too C++ like? Jens Gustedt <jens.gustedt@loria.fr> - 2012-01-21 22:42 +0100
                            Re: Am I being too C++ like? James Kuyper <jameskuyper@verizon.net> - 2012-01-21 21:22 -0500
                              Re: Am I being too C++ like? Jens Gustedt <jens.gustedt@loria.fr> - 2012-01-22 14:56 +0100
                        Re: Am I being too C++ like? Ian Collins <ian-news@hotmail.com> - 2012-01-22 10:29 +1300
                    Re: Am I being too C++ like? Kleuske <kleuske@nowhere.net> - 2012-01-21 11:36 +0000
                Re: Am I being too C++ like? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-22 12:13 +0000
                  Re: Am I being too C++ like? Kleuske <kleuske@nowhere.net> - 2012-01-22 12:39 +0000
                    Re: Am I being too C++ like? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-23 23:45 +0000
                      Re: Am I being too C++ like? Kleuske <kleuske@nowhere.net> - 2012-01-24 16:54 +0000
              Re: Am I being too C++ like? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-22 04:43 -0800
                Re: Am I being too C++ like? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-22 15:29 +0000
            Re: Am I being too C++ like? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-21 11:58 +0000
            Re: Am I being too C++ like? Seebs <usenet-nospam@seebs.net> - 2012-01-21 21:32 +0000
    Re: Am I being too C++ like? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-19 04:23 -0800
      Re: Am I being too C++ like? Rui Maciel <rui.maciel@gmail.com> - 2012-01-19 14:39 +0000
      Re: Am I being too C++ like? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-22 05:14 -0800
        Re: Am I being too C++ like? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-23 23:42 +0000
    Re: Am I being too C++ like? Rui Maciel <rui.maciel@gmail.com> - 2012-01-19 14:51 +0000
    Re: Am I being too C++ like? jgk@panix.com (Joe keane) - 2012-01-19 23:04 +0000
    Re: Am I being too C++ like? Ian Collins <ian-news@hotmail.com> - 2012-01-20 16:03 +1300
      Re: Am I being too C++ like? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-20 06:01 -0800
        Re: Am I being too C++ like? Ian Collins <ian-news@hotmail.com> - 2012-01-21 08:03 +1300
          Re: Am I being too C++ like? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-21 12:31 -0800
            Re: Am I being too C++ like? Ian Collins <ian-news@hotmail.com> - 2012-01-22 10:18 +1300
    Re: Am I being too C++ like? cri@tiac.net (Richard Harter) - 2012-01-20 05:22 +0000
    Re: Am I being too C++ like? Marco <prenom_nomus@yahoo.com> - 2012-01-21 07:29 -0800
      Re: Am I being too C++ like? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-24 12:13 +0000
        Re: Am I being too C++ like? Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 14:32 -0800
          Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-01-31 15:32 -0800
            Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-01-31 19:46 -0800
            Re: Am I being too C++ like? Shao Miller <sha0.miller@gmail.com> - 2012-01-31 23:54 -0500
              Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-01-31 22:24 -0800
            Re: Am I being too C++ like? Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 23:28 -0800
              Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-02-01 11:23 -0800
                Re: Am I being too C++ like? Stephen Sprunk <stephen@sprunk.org> - 2012-02-01 15:01 -0600
                  Re: Am I being too C++ like? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-02-01 14:09 -0800
                    Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-02-01 14:44 -0800
                  Re: Am I being too C++ like? Shao Miller <sha0.miller@gmail.com> - 2012-02-01 17:36 -0500
                Re: Am I being too C++ like? Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-08 12:45 -0800
                  Re: Am I being too C++ like? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-03-08 21:41 +0000
                    Re: Am I being too C++ like? Ian Collins <ian-news@hotmail.com> - 2012-03-09 17:42 +1300
                      Re: Am I being too C++ like? Kaz Kylheku <kaz@kylheku.com> - 2012-03-09 08:12 +0000
                        Re: Am I being too C++ like? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-03-09 12:01 +0000
                  Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-03-08 14:19 -0800
                    Re: Am I being too C++ like? Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-09 13:32 -0800
                  Re: Am I being too C++ like? nick_keighley_nospam@hotmail.com - 2012-03-09 04:18 -0800
                    Re: Am I being too C++ like? Ike Naar <ike@iceland.freeshell.org> - 2012-03-09 13:04 +0000
                      Re: Am I being too C++ like? Kaz Kylheku <kaz@kylheku.com> - 2012-03-10 01:02 +0000
                        Re: Am I being too C++ like? Ike Naar <ike@iceland.freeshell.org> - 2012-03-10 07:59 +0000
                          Re: Am I being too C++ like? Ian Collins <ian-news@hotmail.com> - 2012-03-10 21:17 +1300
                      Re: Am I being too C++ like? nick_keighley_nospam@hotmail.com - 2012-03-10 02:39 -0800
                    Re: Am I being too C++ like? Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-09 13:51 -0800
                      Re: Am I being too C++ like? nick_keighley_nospam@hotmail.com - 2012-03-10 02:54 -0800
              Re: Am I being too C++ like? Ian Collins <ian-news@hotmail.com> - 2012-03-10 12:27 +1300
            Re: Am I being too C++ like? Rui Maciel <rui.maciel@gmail.com> - 2012-02-01 07:41 +0000
              Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-02-01 11:24 -0800
          Re: Am I being too C++ like? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-01 21:55 +0000

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#16003

Kaz Kylheku <kaz@kylheku.com> wrote:
> On 2012-01-21, Keith Thompson <kst-u@mib.org> wrote:
> > Do you know of any systems that support uint128_t?

> gcc

GCC has __uint128_t and __int128_t on a few platforms, but there's no
typedefs for uint128_t or int128_t. And there's no UINT128_C, INT128_C, or
equivalents, which makes it difficult to use 128-bit constants.

[toc] | [prev] | [next] | [standalone]

#16004

William Ahern <william@wilbur.25thandClement.com> writes:
> Kaz Kylheku <kaz@kylheku.com> wrote:
>> On 2012-01-21, Keith Thompson <kst-u@mib.org> wrote:
>> > Do you know of any systems that support uint128_t?
>
>> gcc
>
> GCC has __uint128_t and __int128_t on a few platforms, but there's no
> typedefs for uint128_t or int128_t. And there's no UINT128_C, INT128_C, or
> equivalents, which makes it difficult to use 128-bit constants.

I hope Kaz is aware that I won't necessarily see anything he posts
here, even if it's a direct response to something I posted, since
I killfiled him a couple of months ago.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#16010

In article <lnty3pwp0b.fsf@nuthaus.mib.org>,
Keith Thompson  <kst-u@mib.org> wrote:
...
>I hope Kaz is aware that I won't necessarily see anything he posts
>here, even if it's a direct response to something I posted, since
>I killfiled him a couple of months ago.

Only total dorks feel the need to tell people who they've killfiled.

Kiki fits the bill admirably.

-- 
"The anti-regulation business ethos is based on the charmingly naive notion
that people will not do unspeakable things for money." - Dana Carpender

Quoted by Paul Ciszek (pciszek at panix dot com).  But what I want to know
is why is this diet/low-carb food author doing making pithy political/economic
statements?

Nevertheless, the above quote is dead-on, because, the thing is - business
in one breath tells us they don't need to be regulated (which is to say:
that they can morally self-regulate), then in the next breath tells us that
corporations are amoral entities which have no obligations to anyone except
their officers and shareholders, then in the next breath they tell us they
don't need to be regulated (that they can morally self-regulate) ...

[toc] | [prev] | [next] | [standalone]

#16085

On Jan 21, 8:07 am, gaze...@shell.xmission.com (Kenny McCormack)
wrote:
> In article <lnty3pwp0b....@nuthaus.mib.org>,
> Keith Thompson  <ks...@mib.org> wrote:
> ...
>
> >I hope Kaz is aware that I won't necessarily see anything he posts
> >here, even if it's a direct response to something I posted, since
> >I killfiled him a couple of months ago.
>
> Only total dorks feel the need to tell people who they've killfiled.
>
It's what I call the "talking kill-file"...it's the emotional
equivalent of a six-year-old putting their hands over their
ears and screaming when their parents try to discipline them...

> Kiki fits the bill admirably.
>
Well, there's a couple of fun things about talking kill-files.
First, in my experience, most of them are imaginary, they never
kill-filed anybody in the first place, just like saying they
did because they think that somehow it "hurts" the victim's
feelings...

Which ties in with the second fun thing, you can say anything
you want to a person who claims they kill-filed you, and they
can't respond even if they lied and read it, because then everybody
would know they're a liar...but they usually crack and respond,
and that's just great fun (Mr. Thompson probably uses an imaginary
kill-file based on his response above, which makes him even
LESS mature than the screaming six-year-old).

---
William Ernest Reid

[toc] | [prev] | [next] | [standalone]

#16011

On 2012-01-21, William Ahern <william@wilbur.25thandClement.com> wrote:
> Kaz Kylheku <kaz@kylheku.com> wrote:
>> On 2012-01-21, Keith Thompson <kst-u@mib.org> wrote:
>> > Do you know of any systems that support uint128_t?
>
>> gcc
>
> GCC has __uint128_t and __int128_t on a few platforms, but there's no
> typedefs for uint128_t or int128_t. 

typedef __uint128_t uint128_t;

> And there's no UINT128_C, INT128_C, or
> equivalents, which makes it difficult to use 128-bit constants.

#define UINT128_C(X) ((uint128_t) (X))

[toc] | [prev] | [next] | [standalone]

#16017

Kaz Kylheku <kaz@kylheku.com> writes:

> On 2012-01-21, William Ahern <william@wilbur.25thandClement.com> wrote:
>> Kaz Kylheku <kaz@kylheku.com> wrote:
>>> On 2012-01-21, Keith Thompson <kst-u@mib.org> wrote:
>>> > Do you know of any systems that support uint128_t?
>>
>>> gcc
>>
>> GCC has __uint128_t and __int128_t on a few platforms, but there's no
>> typedefs for uint128_t or int128_t. 
>
> typedef __uint128_t uint128_t;
>
>> And there's no UINT128_C, INT128_C, or
>> equivalents, which makes it difficult to use 128-bit constants.
>
> #define UINT128_C(X) ((uint128_t) (X))

I don't see how that is supposed to work:

  #include <stdio.h>
   
  typedef __uint128_t uint128_t;
  #define UINT128_C(X) ((uint128_t) (X))
   
  int main(void)
  {
       uint128_t j = UINT128_C(0x10000000000000000ULL);
       puts(j ? "ok" : "fail");
       return 0;
  }

prints "fail" (with a compiler-time warning about the constant being too
large for its type).

The UINTx_C macros usually need compiler magic and the manual says:

  "There is no support in GCC to express an integer constant of type
  __int128 for targets having long long integer with less then 128 bit
  width"

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#17134

Late to the party. Usenet is an occasional treat currently.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Kaz Kylheku <kaz@kylheku.com> writes:
> 
> > On 2012-01-21, William Ahern <william@wilbur.25thandClement.com> wrote:
> >> Kaz Kylheku <kaz@kylheku.com> wrote:
> >>> On 2012-01-21, Keith Thompson <kst-u@mib.org> wrote:
> >>> > Do you know of any systems that support uint128_t?
> >>
> >>> gcc
> >>
> >> GCC has __uint128_t and __int128_t on a few platforms, but there's no
> >> typedefs for uint128_t or int128_t. 
> >
> > typedef __uint128_t uint128_t;
> >
> >> And there's no UINT128_C, INT128_C, or
> >> equivalents, which makes it difficult to use 128-bit constants.
> >
> > #define UINT128_C(X) ((uint128_t) (X))
> 
> I don't see how that is supposed to work:
> 
>   #include <stdio.h>
>    
>   typedef __uint128_t uint128_t;
>   #define UINT128_C(X) ((uint128_t) (X))
>    
>   int main(void)
>   {
>        uint128_t j = UINT128_C(0x10000000000000000ULL);

Don't force it to be a ULL before casting it to the 128-bit type then?

>        puts(j ? "ok" : "fail");
>        return 0;
>   }
> 
> prints "fail" (with a compiler-time warning about the constant being too
> large for its type).
> 
> The UINTx_C macros usually need compiler magic and the manual says:
> 
>   "There is no support in GCC to express an integer constant of type
>   __int128 for targets having long long integer with less then 128 bit
>   width"

Yikes, they did indeed write "less then".

Phil
-- 
Unix is simple. It just takes a genius to understand its simplicity
-- Dennis Ritchie (1941-2011), Unix Co-Creator

[toc] | [prev] | [next] | [standalone]

#17151

Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:

> Late to the party. Usenet is an occasional treat currently.
>
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Kaz Kylheku <kaz@kylheku.com> writes:
>> 
>> > On 2012-01-21, William Ahern <william@wilbur.25thandClement.com> wrote:
>> >> Kaz Kylheku <kaz@kylheku.com> wrote:
>> >>> On 2012-01-21, Keith Thompson <kst-u@mib.org> wrote:
>> >>> > Do you know of any systems that support uint128_t?
>> >>
>> >>> gcc
>> >>
>> >> GCC has __uint128_t and __int128_t on a few platforms, but there's no
>> >> typedefs for uint128_t or int128_t. 
>> >
>> > typedef __uint128_t uint128_t;
>> >
>> >> And there's no UINT128_C, INT128_C, or
>> >> equivalents, which makes it difficult to use 128-bit constants.
>> >
>> > #define UINT128_C(X) ((uint128_t) (X))
>> 
>> I don't see how that is supposed to work:
>> 
>>   #include <stdio.h>
>>    
>>   typedef __uint128_t uint128_t;
>>   #define UINT128_C(X) ((uint128_t) (X))
>>    
>>   int main(void)
>>   {
>>        uint128_t j = UINT128_C(0x10000000000000000ULL);
>
> Don't force it to be a ULL before casting it to the 128-bit type then?

I don't see how that helps.  It certainly doesn't alter the behaviour of
the example program when compiler with gcc.

>>        puts(j ? "ok" : "fail");
>>        return 0;
>>   }

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#17758

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
> 
> > Late to the party. Usenet is an occasional treat currently.
> >
> > Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> >> Kaz Kylheku <kaz@kylheku.com> writes:
> >> 
> >> > On 2012-01-21, William Ahern <william@wilbur.25thandClement.com> wrote:
> >> >> Kaz Kylheku <kaz@kylheku.com> wrote:
> >> >>> On 2012-01-21, Keith Thompson <kst-u@mib.org> wrote:
> >> >>> > Do you know of any systems that support uint128_t?
> >> >>
> >> >>> gcc
> >> >>
> >> >> GCC has __uint128_t and __int128_t on a few platforms, but there's no
> >> >> typedefs for uint128_t or int128_t. 
> >> >
> >> > typedef __uint128_t uint128_t;
> >> >
> >> >> And there's no UINT128_C, INT128_C, or
> >> >> equivalents, which makes it difficult to use 128-bit constants.
> >> >
> >> > #define UINT128_C(X) ((uint128_t) (X))
> >> 
> >> I don't see how that is supposed to work:
> >> 
> >>   #include <stdio.h>
> >>    
> >>   typedef __uint128_t uint128_t;
> >>   #define UINT128_C(X) ((uint128_t) (X))
> >>    
> >>   int main(void)
> >>   {
> >>        uint128_t j = UINT128_C(0x10000000000000000ULL);
> >
> > Don't force it to be a ULL before casting it to the 128-bit type then?
> 
> I don't see how that helps.  It certainly doesn't alter the behaviour of
> the example program when compiler with gcc.

I'm glad you replied - I now see that my assumptions were not 100% correct, 
thanks for the nudge. I see the opening for 0x10000000000000000ULL to be of
no type, as p6 contains a "may" - there's no obligation for use of an 
extended integer type. Presumably bad things happen in that case, and gcc
would barf, but that's not what you're seeing. Curious...

I will note that I find 6.4.4.1 p2 and p5+p6 to be somewhat conflicting, 
and consider p2 to be the paragraph at fault, as the suffix doesn't 
necessarily specify the type, it merely restricts the type it may have.

Phil
-- 
> I'd argue that there is much evidence for the existence of a God.
Pics or it didn't happen.
-- Tom (/. uid 822)

[toc] | [prev] | [next] | [standalone]

#16024

Am 01/21/2012 07:00 PM, schrieb Kaz Kylheku:
>> And there's no UINT128_C, INT128_C, or
>> equivalents, which makes it difficult to use 128-bit constants.
> 
> #define UINT128_C(X) ((uint128_t) (X))

No this wouldn't result in an expression that the preprocessor could
interpret as an integer expression.

Better would be something like

#define UINT128_C(X) (0u+((uint128_t)+(X)))

to ensure that it would even work for preprocessor constants in #if
clauses. (The preprocessor would replace the uint128_t with 0 for the
purpose of evaluation.)

But to support uint128_t needs more than that. You'd have to

- make uintmax_t also that type
- as a consequence have to compute with that width in the preprocessor
- implement all the library support, in particular PRIu128 and stuff
  like that for printing

Jens

[toc] | [prev] | [next] | [standalone]

#16030

On 01/21/2012 01:00 PM, Kaz Kylheku wrote:
> On 2012-01-21, William Ahern <william@wilbur.25thandClement.com> wrote:
...
>> And there's no UINT128_C, INT128_C, or
>> equivalents, which makes it difficult to use 128-bit constants.
> 
> #define UINT128_C(X) ((uint128_t) (X))

7.18.4p3: "Each invocation of one of these macros shall expand to an
integer constant expression suitable for use in #if preprocessing
directives."

In the context of a #if preprocessing directive, uint123_t is a
meaningless identifier that would get converted to a 0 (6.10.1p4),
resulting in a syntax error. That's an example of why the macros
governed by 7.18.4p3 cannot contain casts. I believe that they're
supposed to limit their operations to appending appropriate suffixes
like U, or L, or LL; the only example given in the standard appends ULL.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#16038

Am 01/22/2012 03:22 AM, schrieb James Kuyper:

> That's an example of why the macros
> governed by 7.18.4p3 cannot contain casts.

They can contain casts, you just have to trick the preprocessor.

(0u+((uint128_t)+(X)))

works. For prepocessor evaluation this is (0u+((0)+(X)), so this will
evaluate to an unsigned quantity of value X. Since the preprocessor
calculates with uintmax_t, this is best what you can get.

For later translation phases this is a cast of +(X) followed by an
addition, which is fine, too.

Jens

[toc] | [prev] | [next] | [standalone]

#16018

On 01/21/12 01:13 PM, Kaz Kylheku wrote:
> On 2012-01-21, Keith Thompson<kst-u@mib.org>  wrote:
>> Do you know of any systems that support uint128_t?
>
> gcc

Does glibc support inputting and outputting them?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#16006

On Fri, 20 Jan 2012 16:28:43 -0600, Stephen Sprunk saw fit to publish the
following:

> On 20-Jan-12 14:23, Ian Collins wrote:
>> On 01/21/12 09:17 AM, Kleuske wrote:
>>> In many cases a well_chosen name can actually _add_ some information.
>>> Consider something like:
>>>
>>> typedef unsigned int ipaddr_t;
>>>
>>> and speculate what variables of this type are used for.
>>>
>>> PS. Target platform allows the assumption sizeof(unsigned int)==4.
>> 
>> Why assume?
>> 
>> typedef uint32_t ipaddr_t;
> 
> That won't work; IP addresses can be 128 bits, so that should be
> "typedef uint128_t ipaddr_t;".
> 
> Kleuske must have a system with CHAR_BIT>=32, which is the only way his
> ipaddr_t can hold any IP address _and_ sizeof(unsigned int)==4 can be
> true.

The object of the little example was to show how a typedef alias can benefit
treadability of code. Its intention was _not_ to provide a watertight
solution portable over ipv4 and ipv6 architectures, but to illustrate a
point.

I am sorry if you missed that.

-- 
... The prejudices people feel about each other disappear when they get
to know each other.
		-- Kirk, "Elaan of Troyius", stardate 4372.5

[toc] | [prev] | [next] | [standalone]

#16034

On Fri, 2012-01-20, Kleuske wrote:
...
> In many cases a well_chosen name can actually _add_ some information. Consider
> something like:
>
> typedef unsigned int ipaddr_t;
>
> and speculate what variables of this type are used for.

I strongly prefer the BSD sockets solution:

struct in_addr {
    unsigned s_addr;
};

Your ipaddr_t can easily be confused with normal integers. The struct
cannot -- it's unique.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#16035

On Sun, 22 Jan 2012 12:13:20 +0000, Jorgen Grahn saw fit to publish the
following:

> On Fri, 2012-01-20, Kleuske wrote:
> ...
>> In many cases a well_chosen name can actually _add_ some information.
>> Consider something like:
>>
>> typedef unsigned int ipaddr_t;
>>
>> and speculate what variables of this type are used for.
> 
> I strongly prefer the BSD sockets solution:
> 
> struct in_addr {
>     unsigned s_addr;
> };
> 
> Your ipaddr_t can easily be confused with normal integers. The struct
> cannot -- it's unique.
> 
> /Jorgen

<sigh>

Again... The point was not to provide a way of dealing with IP-addresses
(v4 or v6), but to illustrate the point that a well chosen name for a
typedef can actually _add_ information.

I consider that point made.

-- 
Hailing frequencies open, Captain.

[toc] | [prev] | [next] | [standalone]

#16083

On Sun, 2012-01-22, Kleuske wrote:
> On Sun, 22 Jan 2012 12:13:20 +0000, Jorgen Grahn saw fit to publish the
> following:
>
>> On Fri, 2012-01-20, Kleuske wrote:
>> ...
>>> In many cases a well_chosen name can actually _add_ some information.
>>> Consider something like:
>>>
>>> typedef unsigned int ipaddr_t;
>>>
>>> and speculate what variables of this type are used for.
>> 
>> I strongly prefer the BSD sockets solution:
>> 
>> struct in_addr {
>>     unsigned s_addr;
>> };
>> 
>> Your ipaddr_t can easily be confused with normal integers. The struct
>> cannot -- it's unique.
>> 
>> /Jorgen
>
> <sigh>
>
> Again... The point was not to provide a way of dealing with IP-addresses
> (v4 or v6), but to illustrate the point that a well chosen name for a
> typedef can actually _add_ information.

I was /not/ talking about IP addresses -- I showed how the typedef
with the well-chosen name was still inferior to a new type. That this
happened to be a well-known example from the real world was a bonus.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#16099

On Mon, 23 Jan 2012 23:45:27 +0000, Jorgen Grahn saw fit to publish the
following:

> On Sun, 2012-01-22, Kleuske wrote:
>> On Sun, 22 Jan 2012 12:13:20 +0000, Jorgen Grahn saw fit to publish the
>> following:
>>
>>> On Fri, 2012-01-20, Kleuske wrote:
>>> ...
>>>> In many cases a well_chosen name can actually _add_ some information.
>>>> Consider something like:
>>>>
>>>> typedef unsigned int ipaddr_t;
>>>>
>>>> and speculate what variables of this type are used for.
>>> 
>>> I strongly prefer the BSD sockets solution:
>>> 
>>> struct in_addr {
>>>     unsigned s_addr;
>>> };
>>> 
>>> Your ipaddr_t can easily be confused with normal integers. The struct
>>> cannot -- it's unique.
>>> 
>>> /Jorgen
>>
>> <sigh>
>>
>> Again... The point was not to provide a way of dealing with
>> IP-addresses (v4 or v6), but to illustrate the point that a well chosen
>> name for a typedef can actually _add_ information.
> 
> I was /not/ talking about IP addresses -- I showed how the typedef with
> the well-chosen name was still inferior to a new type. That this
> happened to be a well-known example from the real world was a bonus.

<Whoosh...>

<sigh again>

Ok. You win. Happy?

-- 
There is an order of things in this universe.
		-- Apollo, "Who Mourns for Adonais?" stardate 3468.1

[toc] | [prev] | [next] | [standalone]

#16036

On Jan 20, 2:08 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> On 1/20/2012 8:44 AM, BartC wrote:
>
>
>
>
>
> > "Keith Thompson" <ks...@mib.org> wrote in message
> >news:lnfwfbxfcx.fsf@nuthaus.mib.org...
> >> "BartC" <b...@freeuk.com> writes:
> >>> "Jorgen Grahn" <grahn+n...@snipabacken.se> wrote in message
>
> >>>> I'd skip the typedef -- if something is a struct, I want to see
> >>>> that immediately. People typedef the weirdest things, so I feel I
> >>>> cannot assume such a name is a struct, and not a pointer or something.
>
> >>> Couldn't you make exactly the same argument for *anything* defined with
> >>> typedef?
>
> >> Not quite.
>
> >> A typedef for a struct type just creates a new name (like "foo") for
> >> something that already has a name (like "struct foo"). It typically
> >> provides no new information, nor does it hide information that
> >> should be hidden;
>
> > But if I create a new typedef T, and then declare:
>
> > T a;
>
> > I can't see at a glance whether T is a number, struct, and anything
> > else. That seemed to be the point of JG's remark. In this case it *does*
> > hide some information.
>
>      Not very effectively, since you need to rediscover at least
> some of the "hidden" information before you can use `a'.

unless you are using it a completly opaque type

    T t = create_T ();
    operation1_t (t, 1, 2);
    operation2_t (t, 1, 2);
    print_t (t);
    destroy_t (t);

The actual type of T could be completly hidden and yet be useful.

>         a = 42;          // legal?
>         *a |= 42;        // legal?
>         a.fizz = 42;     // legal?
>         a->buzz = 42;    // legal?
>         puts(a);         // legal?
>         longjmp(a, 42);  // legal?
>         a(42);           // legal?
>
>      As a matter of personal taste I rather like typedef aliases
> for struct types

I happen not to like the "struct" keyword scattered all over the place
so I'm happy to hide it behind a typedf. This is something I think C++
gets right.

>(and less often, union types),

I hardly ever use them. I do use typedefs with enums.

> and I intensely
> dislike them for data pointer types

ditto.

> (but sometimes use them for
> function pointers).

definitely, I think function pointer syntax is a bit nasty, and as
soon as you try and pass a function pointer as a parameter or return
it or make an array of them or have them as members of a struct the
readability plummets.

> For scalar types, I use typedef not so much
> for opacity but for portability, using <limits.h> and #if to find
> a type with suitable range and publishing the result as a typedef
> name.

I quite like Byte or Octet because they state their intended use and
involve less typeing!

> But these are just my preferences, not binding on anyone
> and not enshrined in a style standard.

[toc] | [prev] | [next] | [standalone]

#16040

Nick Keighley <nick_keighley_nospam@hotmail.com> writes:

> On Jan 20, 2:08 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>> On 1/20/2012 8:44 AM, BartC wrote:
>>
>> > "Keith Thompson" <ks...@mib.org> wrote in message
>> >news:lnfwfbxfcx.fsf@nuthaus.mib.org...
>> >> "BartC" <b...@freeuk.com> writes:
>> >>> "Jorgen Grahn" <grahn+n...@snipabacken.se> wrote in message
>>
>> >>>> I'd skip the typedef -- if something is a struct, I want to see
>> >>>> that immediately. People typedef the weirdest things, so I feel I
>> >>>> cannot assume such a name is a struct, and not a pointer or something.
>>
>> >>> Couldn't you make exactly the same argument for *anything* defined with
>> >>> typedef?
>>
>> >> Not quite.
>>
>> >> A typedef for a struct type just creates a new name (like "foo") for
>> >> something that already has a name (like "struct foo"). It typically
>> >> provides no new information, nor does it hide information that
>> >> should be hidden;
>>
>> > But if I create a new typedef T, and then declare:
>>
>> > T a;
>>
>> > I can't see at a glance whether T is a number, struct, and anything
>> > else. That seemed to be the point of JG's remark. In this case it *does*
>> > hide some information.
>>
>>      Not very effectively, since you need to rediscover at least
>> some of the "hidden" information before you can use `a'.
>
> unless you are using it a completly opaque type
>
>     T t = create_T ();
>     operation1_t (t, 1, 2);
>     operation2_t (t, 1, 2);
>     print_t (t);
>     destroy_t (t);
>
> The actual type of T could be completly hidden and yet be useful.

I realise you are responding to the comment that you need to be able to
tell something about T to use it by giving an example where all the uses
are covered by function calls, but the last remark is still not true.

To declare an object of type T, it can't be "completely hidden" -- at
best it can be a pointer to an incomplete type.  It's possible that you
intended to write

  T *t;

in which case we know something about t (it's a pointer) and almost
nothing about T.

The trouble with making a type like T declarable, is that the users of
your interface will think that Ts are copyable without knowing what that
means.  For example:

  T save, t = create_T();
  save = t;
  operation1_T(t, 1, 2);
  t = save

Does this restore the state or not?  Of course this can be cleared up in
the documentation, but using a pointer to an incomplete type make things
clear.  My own preference is to make "abstract" types declarable only
when they are copyable.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web