Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Strong typedefs.

87 views
Skip to first unread message

Mr Flibble

unread,
May 18, 2020, 2:13:12 PM5/18/20
to
Hi!

When is C++ getting strong typedefs? I want strong typedefs!

/Flibble

--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin

“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who doesn’t believe in any God the most. Oh, no..wait.. that never happens.” – Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."

Alf P. Steinbach

unread,
May 18, 2020, 6:32:58 PM5/18/20
to
On 18.05.2020 20:13, Mr Flibble wrote:
>
> When is C++ getting strong typedefs? I want strong typedefs!

AOL.

It will probably be never, because it's something that practitioners
actually want and that could be of practical utility.

However, if someone can come with some ivory tower reason for it, e.g.
grounded in type theory, and expressed in math notation, then, possibly.

Meanwhile the Boost Operators sub-library can help generate operators
from a few basic ones, to reduce the amount of boilerplate.

<url:
https://www.boost.org/doc/libs/1_41_0/libs/utility/operators.htm#integer_arithmetic1>


- Alf

David Brown

unread,
May 19, 2020, 4:19:34 AM5/19/20
to
On 18/05/2020 20:13, Mr Flibble wrote:
> Hi!
>
> When is C++ getting strong typedefs? I want strong typedefs!
>

The trouble with adding "strong typedefs" to C++ is that people have
very different ideas about what they mean by "strong typedefs". Many
people (including me) agree that they want strong typedefs in the
language, but disagree on /how/ strong, and on many of the details.
(There are lots of proposals for adding the feature to the language -
I'm sure you can google these as well as anyone else.)

For integer types, "enum class" may give you what you need.


There are also various template based solutions - you may or may not
find them suitable:

<https://foonathan.net/2016/10/strong-typedefs/>


And there is always boost, if you don't mind the macros.

Sam

unread,
May 19, 2020, 7:07:21 AM5/19/20
to
Mr Flibble writes:

> Hi!
>
> When is C++ getting strong typedefs? I want strong typedefs!

So, make your own. I did, it wasn't very hard at all.

Bonita Montero

unread,
May 19, 2020, 8:21:21 AM5/19/20
to
Use BOOST_STRONG_TYPEDEF.

Thiago Adams

unread,
May 19, 2020, 8:34:12 AM5/19/20
to
On Monday, May 18, 2020 at 3:13:12 PM UTC-3, Mr Flibble wrote:
> Hi!
>
> When is C++ getting strong typedefs? I want strong typedefs!
>

[[ironic]]

Yes. But this feature is too simple. No one wants to propose or
implement this.

Meanwhile, concepts are implemented.

(I guess C++ is following a web browser strategy.
Make a so complex standard in a way just few companies are
able to implement it.)






David Brown

unread,
May 19, 2020, 10:06:18 AM5/19/20
to
On 19/05/2020 14:34, Thiago Adams wrote:
> On Monday, May 18, 2020 at 3:13:12 PM UTC-3, Mr Flibble wrote:
>> Hi!
>>
>> When is C++ getting strong typedefs? I want strong typedefs!
>>
>
> [[ironic]]
>
> Yes. But this feature is too simple. No one wants to propose or
> implement this.

It turns out that strong typedefs are very hard to define and pin down
exactly what people mean by the term.

>
> Meanwhile, concepts are implemented.
>
> (I guess C++ is following a web browser strategy.
> Make a so complex standard in a way just few companies are
> able to implement it.)
>

Concepts are not that hard to use, and simplify code and error messages.
What's your problem with them?

Thiago Adams

unread,
May 19, 2020, 10:59:52 AM5/19/20
to
On Tuesday, May 19, 2020 at 11:06:18 AM UTC-3, David Brown wrote:
> On 19/05/2020 14:34, Thiago Adams wrote:
> > On Monday, May 18, 2020 at 3:13:12 PM UTC-3, Mr Flibble wrote:
> >> Hi!
> >>
> >> When is C++ getting strong typedefs? I want strong typedefs!
> >>
> >
> > [[ironic]]
> >
> > Yes. But this feature is too simple. No one wants to propose or
> > implement this.
>
> It turns out that strong typedefs are very hard to define and pin down
> exactly what people mean by the term.

Just add a warning inside the compiler.

typedef int BOOL;

BOOL F() {
return E_FAIL; //WARNING.. E_FAIL IS NOT A BOOL
}

int main() {
F();
}


> >
> > Meanwhile, concepts are implemented.
> >
> > (I guess C++ is following a web browser strategy.
> > Make a so complex standard in a way just few companies are
> > able to implement it.)
> >
>
> Concepts are not that hard to use, and simplify code and error messages.
> What's your problem with them?

It is not necessarily a problem, but my opinion about
c++ priorities.

Concepts were in the last position in my top 100 for instance.
Modules as well.

Unfortunately, my priorities are much different from C++
committee.

I would like simple multi platform libs for sockets, console
for instance.












The Real Non Homosexual

unread,
May 19, 2020, 11:10:54 AM5/19/20
to
Your no talent monkey ass missed the argument. Maybe you should consider something else since it appears computers don't quite to be your thing

The Real Non Homosexual

unread,
May 19, 2020, 11:14:24 AM5/19/20
to
I swear Thiago makes fir over at comp.lang.c look smart.

David Brown

unread,
May 19, 2020, 11:25:36 AM5/19/20
to
On 19/05/2020 16:59, Thiago Adams wrote:
> On Tuesday, May 19, 2020 at 11:06:18 AM UTC-3, David Brown wrote:
>> On 19/05/2020 14:34, Thiago Adams wrote:
>>> On Monday, May 18, 2020 at 3:13:12 PM UTC-3, Mr Flibble wrote:
>>>> Hi!
>>>>
>>>> When is C++ getting strong typedefs? I want strong typedefs!
>>>>
>>>
>>> [[ironic]]
>>>
>>> Yes. But this feature is too simple. No one wants to propose or
>>> implement this.
>>
>> It turns out that strong typedefs are very hard to define and pin down
>> exactly what people mean by the term.
>
> Just add a warning inside the compiler.
>
> typedef int BOOL;
>
> BOOL F() {
> return E_FAIL; //WARNING.. E_FAIL IS NOT A BOOL
> }
>
> int main() {
> F();
> }
>

The idea of "strong typedef" is a bit more complicated than that...

>
>>>
>>> Meanwhile, concepts are implemented.
>>>
>>> (I guess C++ is following a web browser strategy.
>>> Make a so complex standard in a way just few companies are
>>> able to implement it.)
>>>
>>
>> Concepts are not that hard to use, and simplify code and error messages.
>> What's your problem with them?
>
> It is not necessarily a problem, but my opinion about
> c++ priorities.
>
> Concepts were in the last position in my top 100 for instance.
> Modules as well.
>
> Unfortunately, my priorities are much different from C++
> committee.

C++ is used on a /huge/ range of program types. The priorities picked
by the C++ committee will never match the priorities of any one
programmer. This is especially true because the priorities are guided
by practicalities - the community debates on ideas and details before
deciding on how a feature will be implemented, and nothing makes it into
the standards before there is a certain level of agreement.

It has taken something like 20 years for concepts and modules to make it
to the top of the list - it's not a rush job.

>
> I would like simple multi platform libs for sockets, console
> for instance.
>

These would be almost totally and completely useless to me. Different
people have different priorities.

And this stuff can all be implemented as libraries - so people can try
it out and see if particular libraries become popular and useful before
standardising. Concepts and modules are language changes.

Thiago Adams

unread,
May 19, 2020, 11:49:18 AM5/19/20
to
Did you take your medicine today?

Jorgen Grahn

unread,
May 19, 2020, 12:08:43 PM5/19/20
to
On Tue, 2020-05-19, David Brown wrote:
> On 19/05/2020 16:59, Thiago Adams wrote:
>> On Tuesday, May 19, 2020 at 11:06:18 AM UTC-3, David Brown wrote:
>>> On 19/05/2020 14:34, Thiago Adams wrote:
>>>> On Monday, May 18, 2020 at 3:13:12 PM UTC-3, Mr Flibble wrote:
>>>>> Hi!
>>>>>
>>>>> When is C++ getting strong typedefs? I want strong typedefs!
>>>>>
>>>>
>>>> [[ironic]]
>>>>
>>>> Yes. But this feature is too simple. No one wants to propose or
>>>> implement this.
>>>
>>> It turns out that strong typedefs are very hard to define and pin down
>>> exactly what people mean by the term.
>>
>> Just add a warning inside the compiler.
...

> The idea of "strong typedef" is a bit more complicated than that...

To me it appears simple: 'typedef foo bar', and bar will be exactly
like foo, except there will be no conversions between them. But I see
no use case for such a thing ...

The one time in the past when I wanted something like that, it
turned out I really wanted my own template class. I remember asking
here about it in 2009 or so ... I wrote a protocol encoder/decoder
for GTPv2, and the protocol carried a lot of tag-length-value data
which often was some tag, length 4 and a value which was a 32-bit
integer. I ended up with the tag as the template argument, and
typedefs like

typedef Element32<4711> UPTunnelId;

...
>> I would like simple multi platform libs for sockets, console
>> for instance.
>>
>
> These would be almost totally and completely useless to me. Different
> people have different priorities.
>
> And this stuff can all be implemented as libraries - so people can try
> it out and see if particular libraries become popular and useful before
> standardising.

And that hasn't happened yet. For sockets I'm happy with BSD sockets;
they are well-known, work on all machines I care about, and are
documented in manpages and Stevens' books. I'm not that impressed
with Qt's sockets or with Boost.Asio. They are useful, but I wouldn't
want them standardized.

/Jorgen

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

Thiago Adams

unread,
May 19, 2020, 12:08:47 PM5/19/20
to
On Tuesday, May 19, 2020 at 12:25:36 PM UTC-3, David Brown wrote:
...
> C++ is used on a /huge/ range of program types. The priorities picked
> by the C++ committee will never match the priorities of any one
> programmer. This is especially true because the priorities are guided
> by practicalities - the community debates on ideas and details before
> deciding on how a feature will be implemented, and nothing makes it into
> the standards before there is a certain level of agreement.

I wish we had a public poll about features by sector like
games, industry, embedded etc.






The Real Non Homosexual

unread,
May 19, 2020, 12:09:25 PM5/19/20
to
I don't think you fully grasp the concept and/or purpose of strong typedes. Presumably because you're a neanderthal. Now shut up and take heed to David Brown's comment.

Thiago Adams

unread,
May 19, 2020, 12:14:48 PM5/19/20
to
On Tuesday, May 19, 2020 at 1:08:43 PM UTC-3, Jorgen Grahn wrote:
...
> And that hasn't happened yet. For sockets I'm happy with BSD sockets;
> they are well-known, work on all machines I care about, and are
> documented in manpages and Stevens' books. I'm not that impressed
> with Qt's sockets or with Boost.Asio. They are useful, but I wouldn't
> want them standardized.
>

I also don't want asio etc.

Just BSD sockets but multiplatform with the small
differences fixed.
For instance on linux we have errno and on windows WSAGetLastError.

The Real Non Homosexual

unread,
May 19, 2020, 2:11:21 PM5/19/20
to
The Linux implemention sucks compared to BSD. But I'm sure that a talented programmer like yourself is aware of these subtle but important differences.

Jorgen Grahn

unread,
May 19, 2020, 4:51:02 PM5/19/20
to
The problem is, I think, more in how you handle the I/O from a whole
program perspective. Threads, fork, select, poll, epoll, mixing
sockets with other event sources ...

But like I hinted at above, I'm not interested in Windows, so
personally I have no problem.

Keith Thompson

unread,
May 19, 2020, 5:29:43 PM5/19/20
to
Thiago Adams <thiago...@gmail.com> writes:
> On Tuesday, May 19, 2020 at 11:06:18 AM UTC-3, David Brown wrote:
[...]
>> It turns out that strong typedefs are very hard to define and pin down
>> exactly what people mean by the term.
>
> Just add a warning inside the compiler.
>
> typedef int BOOL;
>
> BOOL F() {
> return E_FAIL; //WARNING.. E_FAIL IS NOT A BOOL
> }

Changing the existing meaning of typedefs is a non-starter.
Existing code can reasonably rely on a typedef creating an alias
for an existing type, not a new type. And I don't think there are
any existing features that require a warning while disallowing a
fatal error message.

I'd like to see something that might reasonably be called "strong
typedefs", but it needs to be a new feature.

And I doubt that you could get universal agreement on whether
something like this:

strong_typedef int mytype;
mytype obj = 42;

should require a diagnostic.

For integral types, you *probably* want to create a type that's
distinct from existing types in the same way that int and long are
distinct from each other (even if they have the same representation).
But that implies that you have implicit conversions to and from
other numeric types.

So you likely want the ability to create a new integer type with
implicit conversions *and* the ability to create an new integer
type without implicit conversions.

Implementing this in a compiler probably isn't too difficult. The hard
part is defining the feature in the first place.

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

Thiago Adams

unread,
May 19, 2020, 8:54:56 PM5/19/20
to
On Tuesday, May 19, 2020 at 6:29:43 PM UTC-3, Keith Thompson wrote:
> Thiago Adams writes:
> > On Tuesday, May 19, 2020 at 11:06:18 AM UTC-3, David Brown wrote:
> [...]
> >> It turns out that strong typedefs are very hard to define and pin down
> >> exactly what people mean by the term.
> >
> > Just add a warning inside the compiler.
> >
> > typedef int BOOL;
> >
> > BOOL F() {
> > return E_FAIL; //WARNING.. E_FAIL IS NOT A BOOL
> > }
>
> Changing the existing meaning of typedefs is a non-starter.
> Existing code can reasonably rely on a typedef creating an alias
> for an existing type, not a new type. And I don't think there are
> any existing features that require a warning while disallowing a
> fatal error message.

Yes. I did not give details but I imagine that is something not
difficult to do compare with other new C++ features.

This static analysis tool have this feature.

https://www.gimpel.com/archive/strong.htm

and it also have some interesting comments about
the problem.

Öö Tiib

unread,
May 20, 2020, 7:07:16 PM5/20/20
to
On Monday, 18 May 2020 21:13:12 UTC+3, Mr Flibble wrote:
> Hi!
>
> When is C++ getting strong typedefs? I want strong typedefs!

There are various implementations available, even boost contains
a macro STRONG_TYPEDEF(a,b) AFAIK somewhere.

I have tried such but I did not observe significant benefits
from that. Same happened with enum class when used as kind of strong
typedef of underlying type. Idea feels god but reality does not
confirm it.

Daniel P

unread,
May 20, 2020, 8:06:03 PM5/20/20
to
On Wednesday, May 20, 2020 at 7:07:16 PM UTC-4, Öö Tiib wrote:
> On Monday, 18 May 2020 21:13:12 UTC+3, Mr Flibble wrote:
> >
> > When is C++ getting strong typedefs? I want strong typedefs!
>
> Same [did not observe significant benefits] happened with enum class when
> used as kind of strong typedef of underlying type. Idea feels good but
> reality does not confirm it.

What do you think of std::byte? Did we need that?

Daniel

Öö Tiib

unread,
May 21, 2020, 2:51:26 AM5/21/20
to
I again like the idea. What std::byte hopefully fixes is for example
that the raw chars are source of illusions as these are eagerly and
silently promoted to signed int by most operations. Since if char is
signed or not is implementation defined result of such promotion is
also implementation defined.

But by C++17 the std::byte was made worse. It said that:

| A value of integral or enumeration type can be explicitly converted
| to a complete enumeration type. The value is unchanged if the original
| value is within the range of the enumeration values (10.2). Otherwise,
| the behavior is undefined.

Where char was signed there half of direct conversions of char to
std::byte were formally undefined behavior. However most raw data
from most APIs are chars. So some implementation-defined illusions
blocked but even worse undefined behaviors added.
That is fortunately fixed in C++20.

Above kind of illustrates my uncertainly about such things, everything
tends to enter standard with good promises but on closer inspection
with even worse bear traps attached.

The Real Non Homosexual

unread,
May 21, 2020, 1:36:39 PM5/21/20
to
I think you all just confused that dumbass Thiago.

Jorgen Grahn

unread,
May 21, 2020, 2:23:22 PM5/21/20
to
On Thu, 2020-05-21, The Real Non Homosexual wrote:
> I think you all just confused that dumbass Thiago.

A tip: repeated posts like that one makes /you/, not Thiago, look bad.
0 new messages