On 23 Jan, 17:01, Mathias Gaunard <loufo...@gmail.com> wrote:
> > * Integers variables of any bit length (1 to a specified maximum).
>
> It's usually more useful to have an integer type that is at least big
> enough.
> If you want real 42 bits, you'd have to perform a modulus operation
> after each arithmetic operation to mimic overflow. Which is fairly
> inefficient.

But maybe you have a 42-bit ALU.  Certainly, a lot of
systems have a 40-bit adder.  And even if you're only
emulating such a machine there are techniques that
don't involve a separate modulus operation (e.g. storing
your numbers in the top 42 bits of a 64-bit register rather
than the bottom 42 bits).

The original poster is quite right that this is a requirement
that doesn't seem to have been taken seriously, but
really this is more the domain of C than C++.
C ought to have taken more from Ada's support for
low-level programming, e.g. representation clauses.
Whether or not Ada did it the right way it's evidence
that the need exists.

Support for mixed-endian data is another obvious lack,
again one that can be synthesised but not necessarily
in a way that exploits whatever hardware features exist.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Hello

I belong to the group of people who's activities are mainly focussed
on lower level development using C and C++, so I'm curious whether C+
+0x will support the following features that a.f.a.i.k. are currenty
not standard in C and C++:

* A syntax for binary numbers.

* Support for data alignment. Currently, we rely on #pragma pack() but
it's not standard.

* Integers variables of any bit length (1 to a specified maximum). C, C
++ and also some other languages have a limited set of integer types
(typically boolean, 8-bit, 16-bit, 32-bit, 64-bit). I know you can use
bit fields in structures, but it's not the same. Often one wants to
work with, say, a 20-bit integer value and pass it around. Currently,
you've to use a 32-bit integer to do so.

* Parameterised goto; goto into an array of labels. This may improve
code generation and readability, for example when implementing a FSM.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Vetzak" <ptrshrn@gmail.com> wrote in message
news:cb83f812-92dc-409e-91aa-df29efca2636@w1g2000prm.googlegroups.com...
>
> Hello
>
> I belong to the group of people who's activities are mainly focussed
> on lower level development using C and C++, so I'm curious whether C+
> +0x will support the following features that a.f.a.i.k. are currenty
> not standard in C and C++:
>
> * A syntax for binary numbers.

This is not present in the current C++ draft.
However, I belive it should be possible to define a constexpr
non-cooked user defined literal syntax such that: 01110111_B  would
work anywhere where an integer could be used.

My guess is that C++ will not get the 0b10011101 notation until after
C adopts it, (assuming that C does ever adopt it)


> * Support for data alignment. Currently, we rely on #pragma pack() but
> it's not standard.

It does have extensive support for data alignment.

> * Integers variables of any bit length (1 to a specified maximum). C, C
> ++ and also some other languages have a limited set of integer types
> (typically boolean, 8-bit, 16-bit, 32-bit, 64-bit). I know you can use
> bit fields in structures, but it's not the same. Often one wants to
> work with, say, a 20-bit integer value and pass it around. Currently,
> you've to use a 32-bit integer to do so.

Not present.

> * Parameterised goto; goto into an array of labels. This may improve
> code generation and readability, for example when implementing a FSM.
>

Not present.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jan 22, 7:54 pm, Vetzak <ptrs...@gmail.com> wrote:
> Hello
>
> I belong to the group of people who's activities are mainly focussed
> on lower level development using C and C++, so I'm curious whether C+
> +0x will support the following features that a.f.a.i.k. are currenty
> not standard in C and C++:
>
> * A syntax for binary numbers.

This is currently not in the draft standard and doesn't look like it
will be. C++1x does offer the new extensible literal functionality,
allowing you to add your own syntax. It is also possible that a binary
literal will be pushed as a late change if member nations express
interest.

> * Support for data alignment. Currently, we rely on #pragma pack() but
> it's not standard.

Yes. C++1x will offer a new attribute system, including an alignment
attribute. However, since you use #pragma pack(), I would assume you
use MSVC. Microsoft has publicly stated they have no desire to
implement C++1x attributes - you would be best to contact them and
complain.

> * Integers variables of any bit length (1 to a specified maximum). C, C
> ++ and also some other languages have a limited set of integer types
> (typically boolean, 8-bit, 16-bit, 32-bit, 64-bit). I know you can use
> bit fields in structures, but it's not the same. Often one wants to
> work with, say, a 20-bit integer value and pass it around. Currently,
> you've to use a 32-bit integer to do so.

C++ will import C99's <stdint.h> as <cstdint>, offering the same
features. It will not offer integers of a specific size, however, a
good compiler for a processor that is not 8 bits wide should (but may
not) provide types that are in multiples of the processor's width
(anything else and it probably doesn't matter).

> * Parameterised goto; goto into an array of labels. This may improve
> code generation and readability, for example when implementing a FSM.

These will not be added. Goto has been discouraged in programming
circles for a long time; you can do pretty much anything you can with
parameterised goto with a class, and with far more readable code and
little overhead (and possibly more optimizations). You might as well
use longjmp().

I hope this helps!

Sean


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 23 jan, 03:54, Vetzak <ptrs...@gmail.com> wrote:
> I'm curious whether C+
> +0x will support the following features that a.f.a.i.k. are currenty
> not standard in C and C++:
>
> * A syntax for binary numbers.

You can do that in C++03 with macros or meta-programming.
Boost has an implementation.


> * Support for data alignment. Currently, we rely on #pragma pack() but
> it's not standard.

Present in TR1, implementable as a library in standard C++03.
Boost has an implementation.

C++0x also adds native functionality in the language, but I never
understood what it brings that wasn't available before.


> * Integers variables of any bit length (1 to a specified maximum).

It's usually more useful to have an integer type that is at least big
enough.
If you want real 42 bits, you'd have to perform a modulus operation
after each arithmetic operation to mimic overflow. Which is fairly
inefficient. Of course, you're free to do that as a library, it's not
a problem at all.

And types that are at least big enough are available in TR1. Boost
also has an implementation within the Boost.Integer library.



> * Parameterised goto; goto into an array of labels. This may improve
> code generation and readability, for example when implementing a FSM.

Good programming practices already advocate to avoid goto.
There is always a better alternative.

I don't even see how it would be useful for a FSM. It's a simple
switch/case in a loop.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Vetzak <ptrshrn@gmail.com> writes:

> I belong to the group of people who's activities are mainly focussed
> on lower level development using C and C++, so I'm curious whether C+
> +0x will support the following features that a.f.a.i.k. are currenty
> not standard in C and C++:
>
> * A syntax for binary numbers.

Though not supported directly, C++0x supports user-defined literals,
so you can define a literal suffix "b" for binary and have

01101011b

yield a value of 107.

> * Support for data alignment. Currently, we rely on #pragma pack() but
> it's not standard.

This is supported through the "align" attribute:

char buffer [[align(16)]] [32];

> * Integers variables of any bit length (1 to a specified maximum). C, C
> ++ and also some other languages have a limited set of integer types
> (typically boolean, 8-bit, 16-bit, 32-bit, 64-bit). I know you can use
> bit fields in structures, but it's not the same. Often one wants to
> work with, say, a 20-bit integer value and pass it around. Currently,
> you've to use a 32-bit integer to do so.

This is not supported.

> * Parameterised goto; goto into an array of labels. This may improve
> code generation and readability, for example when implementing a FSM.

Neither is this.

Anthony
--
Anthony Williams
Author of C++ Concurrency in Action | http://www.manning.com/williams
just::thread C++0x thread library   | http://www.stdthread.co.uk
Custom Software Development         | http://www.justsoftwaresolutions.co.uk
Just Software Solutions Ltd, Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

* Vetzak:
>
> * Parameterised goto; goto into an array of labels. This may improve
> code generation and readability, for example when implementing a FSM.

Assuming that by 'FSM' you mean Finite State Machine, and not one of the
other
possibilities listed at <url: http://acronyms.tfd.com/FSM> (e.g., in the
context
of 'goto' perhaps 'Flying Spaghetti Monster'? :-)), well, haven't you
forgotten
the humble 'switch'?

But for the purpose of implementing an Finite State Machine I'd much
rather have
language support for coroutines.

There are a number of Java libraries implementing coroutines in terms of
threads, and C++0x will have threads, but even though that strategy can
make
sense in terms of simplified synchronization concerns it's really backward:
coroutines should not just have simpler behavior but they should be really
really lightweight, and they need language support (in the old days we
could
build them on top of 'longjmp', but is that at all possible in modern C++?).


Cheers,

- Alf  (nostalgic)

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jan 23, 6:01 pm, Mathias Gaunard <loufo...@gmail.com> wrote:
> On 23 jan, 03:54, Vetzak <ptrs...@gmail.com> wrote:

      [...]
> > * Support for data alignment. Currently, we rely on #pragma
> > pack() but it's not standard.

> Present in TR1, implementable as a library in standard C++03.
> Boost has an implementation.

> C++0x also adds native functionality in the language, but I
> never understood what it brings that wasn't available before.

Mainly, the fact that it is guaranteed to work.  The Boost
implementation may work in practice, on the most frequently
encountered platforms, but there's no way you can guarantee
anything about alignment without language support.  In fact, as
I understand it, attributes aren't guaranteed to work either.
But the compiler will at least tell you when they don't.  And of
course, the fact that the compiler knows of some stricter
alignment can affect its choice of instructions, resulting in
significantly faster code in some cases.

> > * Integers variables of any bit length (1 to a specified maximum).

> It's usually more useful to have an integer type that is at
> least big enough.  If you want real 42 bits, you'd have to
> perform a modulus operation after each arithmetic operation to
> mimic overflow. Which is fairly inefficient. Of course, you're
> free to do that as a library, it's not a problem at all.

> And types that are at least big enough are available in TR1.
> Boost also has an implementation within the Boost.Integer
> library.

The standard simply adopts the C solution here (which IMHO is
the correct way to go---let's stick with C compatibility where
integral types are concerned).  So you have typedef's for exact
size (provided the machine has it, and uses 2's complement),
smallest type with at least n bits, and fastest type with at
least n bits.

> > * Parameterised goto; goto into an array of labels. This may
> > improve code generation and readability, for example when
> > implementing a FSM.

> Good programming practices already advocate to avoid goto.
> There is always a better alternative.

> I don't even see how it would be useful for a FSM. It's a
> simple switch/case in a loop.

I agree with regards to an FSM---Alf's suggestion of
co-processes is far more pertinent (but an obviously looser,
because more complicated solutions exist).  There is only one
place where I see a reasonable use for a calculated goto: when
using the language as an intermediate language for a compiler.
And that's C's job, not C++'s.

--
James Kanze

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]