Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ proposal: There are exactly 8 bits in a byte

open-std.org

Post reply on HN
Print view View original

311–320 of 357 posts

Re: C++ proposal: There are exactly 8 bits in a byte

#311

Post by kazinator »

heinrich5991 wrote: post #252
pezezin wrote: post #151

Earlier quoted context omitted.

If you don't care about the size of your number, just use isize or usize. If you do care, then isn't it better to specify it explicitly than trying to guess it and having different compilers disagreeing on the size?

Actually, if you don't care about the size of your small number, use `i32`. If it's a big number, use `i64`. `isize`/`usize` should only be used for memory-related quantities — that's why they renamed from `int`/`uint`.

If you use i32, it looks like you care. Without studying the code, I can't be sure that it could be changed to i16 or i64 without breaking something.

Usually, I just want the widest type that is efficient on the machine, and I don't want it to have an inappropriate name. I don't care about the wasted space, because it only matters in large arrays, and often not even then.

Re: C++ proposal: There are exactly 8 bits in a byte

#312

Post by kazinator »

Spivak wrote: post #160
kazinator wrote: post #138

Earlier quoted context omitted.

> you have to mention the size explicitly It's unbelievably ugly. Every piece of code working with any kind of integer screams "I am hardware dependent in some way". E.g. in a structure representing an automobile, the number of wheels has to be some i8 or i16, which looks ridiculous. Why would you take a language in which you can write functional pipelines over collections of objects, and make it look like assembler.

Is it any better calling it an int where it's assumed to be an i32 and 30 of the bits are wasted.

what you call things matters, so yes, it is better.

Re: C++ proposal: There are exactly 8 bits in a byte

#313

Post by stkdump »

mort96 wrote: post #221
stkdump wrote: post #208

Earlier quoted context omitted.

I mean practically speaking in C++ we have (it just hasn't made it to the standard): 1. char 8 bit 2. short 16 bit 3. int 32 bit 4. long long 64 bit 5. arithmetic is 2s complement 6. IEEE floating point (float is 32, double is 64 bit) Along with other stuff like little endian, etc. Some people just mistakenly think they can't rely on such stuff, because it isn't in the standard. But they forget that having an ISO sta…

> (it just hasn't made it to the standard) That's the problem

You are aware that D and rust and all the other languages this is being compared to don't even have an ISO standard, right?

Re: C++ proposal: There are exactly 8 bits in a byte

#314

Post by stkdump »

bregma wrote: post #262
stkdump wrote: post #208

Earlier quoted context omitted.

I mean practically speaking in C++ we have (it just hasn't made it to the standard): 1. char 8 bit 2. short 16 bit 3. int 32 bit 4. long long 64 bit 5. arithmetic is 2s complement 6. IEEE floating point (float is 32, double is 64 bit) Along with other stuff like little endian, etc. Some people just mistakenly think they can't rely on such stuff, because it isn't in the standard. But they forget that having an ISO sta…

I work every day with real-life systems where int can be 32 or 64 bits, long long can be 64 or 128 bits, long double can be 64 or 80 or 128 bits, some systems do not have IEEE 754 floating point (no denormals!) some are big endian and some are little endian. These things are not in the language standard because they are not standard in the real world. Practically speaking, the language is the way it is, and has succe…

There are also people who write COBOL for a living. What you say is not relevant at all for 99.99% of C++ code written today. Also, all compilers can be configured to be non-standard compliant in many different ways, the classic example being -fno-exceptions. Nobody says all kinds of using a standardized language must be standard conformant.

Re: C++ proposal: There are exactly 8 bits in a byte

#315

Post by stephencanon »

FooBarBizBazz wrote: post #294
stephencanon wrote: post #264

Earlier quoted context omitted.

It’s absolutely harmful. It turns computations that would be guaranteed to be exact (e.g. head-tail arithmetic primitives used in computational geometry) into “maybe it’s exact and maybe it’s not, it’s at the compiler’s whim” and suddenly your tests for triangle orientation do not work correctly and your mesh-generation produces inadmissible meshes, so your PDE solver fails.

Thank you, I found this hint very interesting. Is there a source you wouldn't mind pointing me to for those "head, tail" methods? I am assuming it relates to the kinds of "variable precision floating point with bounds" methods used in CGAL and the like; Googling turns up this survey paper: https://inria.hal.science/inria-00344355/PDF/p.pdf Any additional references welcome!

Note here is a good starting point for the issue itself: http://www.cs.cmu.edu/~quake/triangle.exact.html

References for the actual methods used in Triangle: http://www.cs.cmu.edu/~quake/robust.html

Re: C++ proposal: There are exactly 8 bits in a byte

#316

Post by speedyjay »

consteval wrote: post #303
josefx wrote: post #268

Earlier quoted context omitted.

I would say anyone mentioning a specific encoding / size just wants to see the world burn. Unicode is variable length on various levels, how many people want to deal with the fact that the unicode of their text could be non normalized or want the ability to cut out individual "char" elements only to get a nonsensical result because the following elements were logically connected to that char? Give developers a decent…

I think this is what Rust does, if I remember correctly, it provides APIs in string to enumerate the characters accurately. That meaning, not necessarily byte by byte.

https://pastebin.com/raw/D7p7mRLK

My comment in a pastebin. HN doesn't like unicode.

You need this crate to deal with it in Rust, it's not part of the base libraries:

https://crates.io/crates/unicode-segmentation

The languages that have this kind of feature built-in in the standard library, to my knowledge, are Swift, JavaScript, C# and Java. Swift is the only one, of those four, that treat operating on graphemes as the default. JavaScript requires Intl.Segmenter, C# requires StringInfo, Java requires BreakIterator.

By the way, Python, the language caused so much hurt with their 2.x->3.x transition promising better unicode support in return for this pain couldn't even do this right. There is no concept of graphemes in the standard library. So much for the batteries included bit.

>>> test = " "

>>> [char for char in test]

['', '\u200d', '', '\u200d', '', '\u200d', '']

>>> len(test)

7

In JavaScript REPL (nodejs):

> let test = " "

undefined

> [...new Intl.Segmenter().segment(test)][0].segment;

' '

> [...new Intl.Segmenter().segment(test)].length;

1

Works as it should.

In python you would need a third party library.

Swift is truly the nicest of programming languages as far as strings are concerned. It just works as it always should have been.

let test = " "

for char in test {

    print(char)
}

print(test.count)

output :

1

[Execution complete with exit code 0]

I, as a non-Apple user, feel quite the Apple envy whenever I think about swift. It's such a nice language, but there's little ecosystem outside of Apple UIs.

But man, no using third party libraries, or working with a wrapper segmenter class or iterator. Just use the base string literals as is. It. Just. Works.

Re: C++ proposal: There are exactly 8 bits in a byte

#317

Post by oxnrtr »

kmeisthax wrote: post #207
Negitivefrags wrote: post #185

Earlier quoted context omitted.

It can be harmful. In GCC while compiling a 32 bit executable, making an std::map can cause infinite loops or crashes in your program. This is because when you insert a value into the map, it has 80 bit precision, and that number of bits is used when comparing the value you are inserting during the traversal of the tree. After the float is stored in the tree, it's clamped to 32 bits. This can cause the element to be…

What use case do you have that requires indexing a hashmap by a floating point value? Keep in mind, even with a compliant implementation that isn't widening your types behind your back, you still have to deal with NaN. In fact, Rust has the Eq trait specifically to keep f32/f64s out of hash tables, because NaN breaks them really bad.

That's purely a problem of Rust being wrong.

Floats have a total order, Rust people just decided to not use it.

Re: C++ proposal: There are exactly 8 bits in a byte

#318

Post by pests »

kreco wrote: post #39

I'm totally fine with enforcing that int8_t == char == 8-bits, however I'm not sure about spreading the misconception that a byte is 8-bits. A byte with 8-bits is called an octet. At the same time, a `byte` is already an "alias" for `char` since C++17 anyway[1]. [1] https://en.cppreference.com/w/cpp/types/byte

> A byte with 8-bits is called an octet

The networking RFC's since inception have always used octet as well.

Re: C++ proposal: There are exactly 8 bits in a byte

#319

Post by heinrich5991 »

kazinator wrote: post #311
heinrich5991 wrote: post #252

Earlier quoted context omitted.

Actually, if you don't care about the size of your small number, use `i32`. If it's a big number, use `i64`. `isize`/`usize` should only be used for memory-related quantities — that's why they renamed from `int`/`uint`.

If you use i32, it looks like you care. Without studying the code, I can't be sure that it could be changed to i16 or i64 without breaking something. Usually, I just want the widest type that is efficient on the machine, and I don't want it to have an inappropriate name. I don't care about the wasted space, because it only matters in large arrays, and often not even then.

> If you use i32, it looks like you care.

In Rust, that's not really the case. `i32` is the go-to integer type.

`isize` on the other hand would look really weird in code — it's an almost unused integer type. I also prefer having integers that don't depend on the machine I'm running them on.

Re: C++ proposal: There are exactly 8 bits in a byte

#320

Post by nullc »

jfbastien wrote: post #147
nullc wrote: post #12

Earlier quoted context omitted.

The tms320c28x DSPs have 16 bit char, so e.g. the Opus audio codec codebase works with 16-bit char (or at least it did at one point -- I wouldn't be shocked if it broke from time to time, since I don't think anyone runs regression tests on such a platform). For some DSP-ish sort of processors I think it doesn't make sense to have addressability at char level, and the gates to support it would be better spent on bette…

I added a mention of TI's hardware in my latest draft: https://isocpp.org/files/papers/D3477R1.html

Any thoughts on the fact that some vendors basically don't offer a C compiler now? E.g. MSVC has essentially forced C++ limitations back onto the C language to reduce C++ vs C maintance costs?
Post reply on HN