LOL

gross
flat > *

File: 1477566646639.png (108KB, 357x368px)

108KB, 357x368px

>mfw to smart to laugh at immature "jokes"

File: CEv2EWTWoAEcFyo.jpg (27KB, 500x372px) Image search: [Google]

27KB, 500x372px

>>58344180

i'm still hurt that there's no good byte variable type in C

>>58344231
uint8_t
int8_t

>>58344231

typedef char byte;

try {
    ...
} catch(Exception up) {
    throw up;
}

>>58344239

typedef unsigned char byte;

float f_cup1;

>>58344238
>>58344239
nope, sorry. not the same thing

>>58344281
But a char is always equal to 1 byte

File: 1477576769912.png (299KB, 680x598px) Image search: [Google]

299KB, 680x598px

>>58344281
>tfw to smart to have a machine that uses 8 bit bytes

>>58344289
No, char is always equal to the smallest representable unit.

Your computer might have registers that operate on bytes, but can only do load and stores of words or halfwords, for example.

>>58344231
See above. Use char.

>>58344289
but char will still be treated differently
unsigned type is also not always wanted

This is not a duplicate reply.

>>58344342
>but char will still be treated differently
How? It's treated like an (unsigned) integer value.

>unsigned type is also not always wanted
Use int_least_8_t then.

>>58344190
best programming language

double long d;

>>58344380
I'll have you signed my

long long double d

File: 1401369116152.png (37KB, 833x768px) Image search: [Google]

37KB, 833x768px

>>58344380

 short d; 

>>58344360
the fact that you have to use tricks like typedef should speak for itself

>>58344412
>the fact that you have to use tricks like typedef should speak for itself
int_least8_t is part of the standard.

>>58344425
but that's still a typedef

>>58344452
it's standard

>>58344340
No, char is always equal to 1 byte, how many bits are are in the byte is machine dependent.

>>58344492
but if i used a system that wouldn't be 2^n bit, i would have a bad day

>>58344249
Get raped and kill yourself, you retarded fucking faggot sack of nigger shit with down syndrome.

>>58344360
chars are signed.

>>58344535
>No, char is always equal to 1 byte,
No, it's equal to the smallest representable unit (which may or may not be a byte).

>how many bits are are in the byte is machine dependent.
Yes

>>58344452
>but that's still a typedef
No, it MAY be a typedef. The standard only specifies that the type must exist.

File: Screen Shot 2017-01-06 at 00.04.29.png (49KB, 1268x138px) Image search: [Google]

49KB, 1268x138px

>>58344612
Seriously, doesn't anyone here read the standard?

>>58344551
then it would be typedef'd to something that isn't a 2^n byte

that's the beauty of typedefs

Sorry, I fucked up.

>>58344612
>>58344644
>>58344360

char may be signed or unsigned.

>>58344617
intN_t IS a typedef
>>58344651
it's standard only for 2^N

>>58344617
>smallest representable unit
which is a byte.
you can have 4-bit bytes.

>>58344644
they are on every compiler i've ever used.

who gives a fuck about that shitty standard? lmao

>>58344200
Library kid looks Jewish...

-----
|DDD|
|D@D|
|DDD|
-----

>>58344676
>which is a byte.
No. As I said, you may have an architecture that can only do memory load and stores on full WORDs but have registers that handle BYTEs.

>>58344675
>intN_t IS a typedef
No, it MAY be a typedef.

>you can have 4-bit bytes.
chars must be at least CHAR_BITS wide, and CHAR_BITS is always at least 8.

>>58344690
>they are on every compiler i've ever used.
Then you've never compiled with GCC or Clang for x86?

uint4096_t d;

>>58344200
Too pretentious for my taste

>>58344737
that is the point of the meme

// Length in inches
ulong muhDik = UInt64.MaxValue;

>>58344731
>intN_t is platform independent so it's not a one byte like every char. you actually define it

>>58344790
>not DBL_MAX

>>58344793
Who are you quoting?

intN_t may be a #define, the only requirement by the standard is that it is defined in stdint.h

>>58344166

foo

File: Screen Shot 2017-01-06 at 00.18.11.png (132KB, 1370x446px) Image search: [Google]

132KB, 1370x446px

>>58344829
>>58344793
And exact-width types are optional, btw.

>>58344829
why thank you for proving me right. saved me the effort

>>58344869
meant to
>>58344853

>>58344869
>>58344889
>intN_t might not be defined at all
How is that proving your point? If anything, this proves that you should use char to represent bytes.

>>58344903
it says that it's a typedef everywhere

>>58344919
>I don't want to use char to represent a byte

Wasn't this your original point?

>>58344935
wnd where did i said such thing. i said that there's no good standard, byte variable in C amongst other primitives

>>58344965
>wnd where did i said such thing
In this post: >>58344342
Maybe I misunderstood?

>>58344965
>byte variable
This is a bad idea, as mentioned before in this thread, it isn't given that a byte is an actual representable primitive.

>Scenario 1) Bytes are shorter than 8 bits.
Since the smallest representable unit in C must have AT LEAST 8 bits (CHAR_BITS >= 8), you can't represent a byte.

>Scenario 2) CPU can operate on bytes in register, but for memory loads/stores only halfwords can be stored due to alignment requirements
In this case you can't have a byte pointer, because you can't store it or load it from memory because of the alignment requirement. So you have to point at every halfword, instead of every byte.

>>58344180
>tfw to intelilgent to be fun at parties

>>58345018
i meant that char is a character primitive and can be or not be an integer
>Since the smallest representable unit in C must have AT LEAST 8 bits (CHAR_BITS >= 8), you can't represent a byte.
course we can. if they byte is less than 8 bits

>>58345171
>i meant that char is a character primitive and can be or not be an integer
character primitives are integers. They have an integer range.

>course we can. if they byte is less than 8 bits
Then it isn't representable in C.

>>58345171
I can't actually think of a machine that has a C++ compiler but also bytes less than 8-bits.

>>58344617
the standard states that sizeof(char) == 1, always. It also states that sizeof returns the number of bytes in an expression or type. Therefore char is a byte always, even if char is not 8 bits.

>>58345250
>They have an integer range
but they don't need to represent a number, nor they're really used for it
also C saw some history and changed some standards
>>58345262
>C++

>>58345342
No, you retard.

The standard states that it MUST BE AT LEAST 8 BITS.

The standard also states that it must be the smallest representable unit (given at least 8 bits).

Even if an architecture uses 8-bit bytes, char may be 32-bit if you can only do memory load/store of 32-bit values.

Go kill yourself for being a fucking mongo

File: 718smiley.svg.png (161KB, 2000x2000px) Image search: [Google]

161KB, 2000x2000px

>>58344166
haah

>>58345342
The ANSI C is also very specific about the fact that a char must fit 95 different values (for the 95 characters in the execution character set) and also that CHAR_BIT must be >= 8 and iirc UCHAR_MAX must be >= 255.

In effect, those conditions together limit standard ANSI C to architectures that have bytes of 8 bits. You can always have non-standard C, but then it's not really C anymore.

>>58345405
>but they don't need to represent a number, nor they're really used for it
But they do and they are.

You can do arithmetics with chars and arithmetic comparison. Also bitwise operations and bitwise comparisons.

>>58345432
>have bytes of 8 bits
I meant bytes of 8 bits or more.

>>58344239
>Unsigned bytes
triggered.

>>58345432
>You can always have non-standard C, but then it's not really C anymore.
In OS development, there is no such thing as standard C

there was a great paper written about this but I cant find it

>>58345465
That's really beside the point, seeing how we're talking about the C standard.

>>58345438
you can. and you can put an ASCII symbol in it. it's a CHARACTER primitive

>>58345432
>>58345454
>In effect, those conditions together limit standard ANSI C to architectures that have bytes of 8 bits
Untrue. If a byte has less than 8 bits, then the only effect is that chars no longer represent bytes.

>>58345517
bytes aren't defined as 8 bits

>>58345513
You can also put an ASCII symbol in an unsigned long long and then convert that unsigned long long into a wchar_t. What's your point?

>>58345538
you can also put an ascii symbol in seven bits

>>58345533
I didn't write so either, you blind retard.

>>58345517
sizeof(char) must still be 1 by definition, though.

File: Casadasdpture.png (100KB, 631x427px) Image search: [Google]

100KB, 631x427px

>>58345417
>The standard states that it MUST BE AT LEAST 8 BITS
When did I state anything contradicting this?

>it must be the smallest representable unit
the standard states that sizeof returns the size of the operand in bytes and that sizeof(char) == 1. Therefore your compiler would have to do bit manipulation to access individual chars in a system that can only access 32-bit words in memory at a time.

>>58345432
Why are you assuming that a byte must be 8 bits or less?

>>58345538
>convert
tsk tsk tsk...
is the idea of standard primitive not clear to you?
also no, you can't. it will be a number and treated as number, not character

>>58345517
Read the standard, you fucking idiot.
In C, a char is the definition of a byte, and is the smallest addressable unit of memory.

>>58345564
Yes, and that is because char represents the smallest representable UNIT (not BYTE).

For the millionth time, if you use an architecture that ALWAYS align memory with 16 bits, then char will be 16 bit wide. But char will still be 1.

>>58345587
A byte is the smallest representable unit.

>>58345569
>Therefore your compiler would have to do bit manipulation to access individual chars in a system that can only access 32-bit words in memory at a time
Actually I just realized that this is wrong. It could just require you to do that manually, although it would still be considered bytes.

>>58345584
>>58345569
You are retards. The standard even defines what it means by BYTE, and protip: It doesn't mean what you think it means.

>Therefore your compiler would have to do bit manipulation to access individual chars in a system that can only access 32-bit words in memory at a time.
Wrong, retard. It will use 32-bit bytes, because pointer arithmetics.

>>58345614
a bit is the smallest representable unit

>>58345587
>(not BYTE)
anon, plz...char is the byte. 8bit, 16 bit, whatever. 1 byte

>>58345620
>You are retards. The standard even defines what it means by BYTE, and protip: It doesn't mean what you think it means.
it defines byte as char

>>58345614
No. The smallest representable unit is the smallest unit you can retrieve with a memory pointer (which may or may NOT be an architectural byte, see memory alignment considerations).

>>58345569
>Why are you assuming that a byte must be 8 bits or less?
What are you on about? According to the ANSI C standard, based on the following two conditions:

1.- sizeof(char) == 1
2.- CHAR_BIT >= 8

A byte must be 8 bits or more.

actually you can adress one bit

man woman
finger sister
unzip dick
mount

>>58345652
I didn't read your correction before I read your post.

File: Screen Shot 2017-01-06 at 01.07.47.png (76KB, 1378x336px) Image search: [Google]

76KB, 1378x336px

>>58345638
This guy is correct, and you're all a bunch of illiterate niggers.

Protip: The keyword here is "addressable".

A char must be large enough to hold the smallest object/unit/whatever you can retrieve with a pointer. That is, if your architecture uses 256-bit alignment in memory, then your char will have 256 bits.

>>58345638
As far as ANSI C is concerned, a char is a byte is the smallest representable unit without bit fields.

>>58345697
That's exactly what I said.......

>>58345697
See >>58345693

>>58345664
you can adress a bit, faggots

>>58345638
If memory is nybble addressable, wouldn't that prevent a compliant ANSI C implementation, since byte would have to be at least an octet? If you had a pointer with the top bit high, that overflow in the address calculation, when the final address is scaled by two. Is that case handled by the C standard?

>>58345737
The picture says exactly what my post says.

>>58345779
>>58345733

>>58345767
>If memory is nybble addressable, wouldn't that prevent a compliant ANSI C implementation, since byte would have to be at least an octet?
There is no requirement that char must be exactly as small as the smallest addressable unit.

The requirement is that it is AT LEAST as big and that it can hold any member of the basic character execution set (aka it can hold opcodes and/or operands).

>If you had a pointer with the top bit high, that overflow in the address calculation, when the final address is scaled by two. Is that case handled by the C standard?
Pointer sizes can be arbitrary large. I'm not following what you mean here?

>>58345799
>>58345779
i said bit not byte

> Go -f>@+?*<.-&'_:$#/%! yourself!

Valid Perl.

>>58345822
kek

>>58345665

man man

it's a good read

>>58344407
you can still try to be a cute trap

>>58345665

make love

or alternatively

man love

Software is like sex: It's never REALLY free.

alias sex "updatedb; locate; talk; date; cd; strip; look; touch; finger; unzip; uptime; gawk; head; apt-get install condom; mount; fsck; gasp; more; yes; yes; yes; more; umount; apt-get remove --purge condom; make clean; sleep"

>>58345936
You forgot

cd /pub

cd /home

>>58345814
>There is no requirement that char must be exactly as small as the smallest addressable unit.
Depends, normally a "byte" is defined as the smallest addressable unit (on the Intel 4004, it would be 4 bits, for example), and a char is defined as being 1 byte in size, along with some other requirements, so it seems like there is a requirement that a char must be the smallest addressable unit (byte), if I'm reading that standard correctly.

>>58345979
>normally a "byte" is defined as the smallest addressable unit (on the Intel 4004, it would be 4 bits, for example)
An architectural byte, yes.

> and a char is defined as being 1 byte in size, along with some other requirements
That's a "C standard byte", which is defined as seen in >>58345693

You must differentiate between what the C standard calls a byte and what the actual byte is.

>so it seems like there is a requirement that a char must be the smallest addressable unit (byte), if I'm reading that standard correctly.
It must be the smallest addressable unit that is equal to or larger than 8 bits AND that can contain any value from the basic execution character set.

If the smallest addressable unit, as seen from the system, is a single bit or a nibble or whatever, char must still be 8 bits and sizeof(char) will still be 1.

but you guys know that basic character sets changed over time, right?

>>58346061
Basic execution character set refers to the instruction set, not to ASCII.

>>58346030
The ANSI C language does not officially support processors where the architectural byte is different from the C standard byte.

I'm sure you can do it and I'm sure there have been C implementations that have done it, but as far as ANSI C is concerned, char is the smallest addressable unit.

In particular this means that ANSI C does not support CPUs with 4-bit data word length.

File: 1405522103074.gif (17KB, 376x385px) Image search: [Google]

17KB, 376x385px

>>58344166

>112 replies to this thread

>>58346107
I think standard C will still work on 4-bit addressable CPUs, you just won't be able to access those 4-bit values using standard C types.

>>58346187
It would not be standards compliant. ANSI C expects char to be the smallest addressable unit and all other data-types must be multiples of char.

But C implementations that are not standards compliant are not exactly rare, so I'm sure that if you look hard enough you'll find C compilers for systems with bytes smaller than 8 bits.

>>58346241
I don't think char has to be the smallest addressable type on the CPU in general, just the smallest addressable type in terms of the standard C types.
I don't see why you couldn't just have 8-bit chars and pretend that 4-bit values don't exist.

http://sdcc.sourceforge.net/

>>58344166
>/reddit/

>>58344231
vector<bool> byte;
byte.resize(8);

>>58345665
loooooool

>>58344166
>image with "double"
>gets dubs
cool

File: vr.png (66KB, 390x440px) Image search: [Google]

66KB, 390x440px

>>58344407

virtual long d ();

>>58344180
>too intelligent to use word too

>>58346161
>non-animated gif

>>58344551
Nobody cares about that system.

>>58344238
He said good.
char and unsigned char is a poor excuse of a "byte"

>>58347764

>Non-doubles post

>>58347793
in the early ears of C and microprocessor world: yes, they do

>>58344360
>How? It's treated like an (unsigned) integer value.
No it's not. It's treated like a character

#include <iostream>

int main()
{
    std::cout << static_cast<unsigned char>(97) << '\n';
}

a

>>58347838
>in the early ears of C and microprocessor world
>times high past and EE shit

Nobody fucking cares.

>>58344166
I didn't even know double meant "double-precision floating point" until after I graduated

>>58347851
did you even try to read the thread?

>>58347851
I care, faggot. Kill yourself.

File: 3eb.jpg (42KB, 602x481px)

42KB, 602x481px

>>58347822

>>58347867
No because you people are fucking retarded and any system that can communicate with the internet will use octets.

>>58347926
you must be 18 or older to use this site

>>58344363
this mane

>>58346982
underrated post

>>58344853
So the standard mandates that implementations provide [u]intN_t types when available. So, if you ever want exactly 8 bits, you should fucking use uint8_t because it will definitely be defined on platforms that support 8-bit units of memory (e.g. every relevant computer made in the last 40 years)

>>58344166
You must be at least 18 years old to post here.

>>58344249
is it retarded to think that using try catch is retarded?

>>58349994
Using try catch is not retarded, but catching an exception and immediately throwing it again is.

>>58349994
no

try catch blocks are retarted
>LOL just use exceptions bro it saves you from doing all of this:

e = func();
if (e == -1) {
    //handle error
}

>and turns it into this!:

try {
    func();
} catch (e) {
    //handle error
}

it doesn't fucking fix the fucking problem, it just makes it "prettier" and prevents you from having to put goto labels at the end of your functions

>>58346343
you monster

who

namespace my { namespace swag { namespace lib {
using u8=std::uint8_t
}}}

here

File: girl.png (245KB, 811x421px) Image search: [Google]

245KB, 811x421px

>>58346982

private long d;

>>58344200
Isn't there an editof this whereone of them has both a huge head and a huge bodyfor you?

>>58344731
An architecture that can only load and store WORDshas no use for a bytedatatype.

>>58350248
>private

File: .png (1MB, 1061x800px) Image search: [Google]

1MB, 1061x800px

>>58344166
>double d

File: shared feel.png (98KB, 600x553px) Image search: [Google]

98KB, 600x553px

>>58344407

private void vag (long d);

File: 1480835206139.png (31KB, 372x300px) Image search: [Google]

31KB, 372x300px

>>58347568
>tfw to new too get the joke

>>58350602
>implying vag returns void

>>58350849
>not understanding the counter meme meme

i like this thread lets all post here

>>58350602

private Niglet vag (long bbc);

>>58347854
Which uni did you go to, so that I can tell people to never go there?

>>58344340
Bytes have nothing to do with registers. A byte is the smallest addressable unit.

>>58344676
That's not allowed by the C standard, it says a byte must be at least 8 bits.

>>58344731
You not it backwards. A byte is the smallest addressable unit, a word is the size of the integer registers. You can have an 8 bit word and 16 bit byte,but its retarded since you'd need to set up an overflow register for ever load.

>>58351268
>it says a byte must be at least 8 bits.
no, it says a char must be at least 8 bits

>>58345262
A lot of old mainframes, like the PDP, VAX, and CDC 6600 used 6 bit characters, packed 3, 6, or 10 to a word. And those machines did have C compilers, a!though this was before the standard came out (so there were no CHAR_BIT conformance issues). And many of these machines were word-addressed rather than using bytes, so dereferencing a pointer-to-char would require doing an indirect load of a word, and then using another machine instruction to select a character within that word.

>>58345569
The standard doesn't define a byte as 8 bits. On 36-bit architecture with fullword and half word addressing, ANSI C would define CHAR_BIT as 18, use 18-bits for char and short, 36-bits for int and long, and probably 72 bit (with multi-register instructions or software routines) for long long.

>>58344166
ha ha it's like there's two peni instead of one penises that's the joke right?

>>58345581
Chars aren't characters, they're an int appropriately sized to represent characters. The compiler converts character literals to integers using the appropriate character set, but internally its all integers. "Characters" are something that your display drivers deal with.

sockhead

>>58346982
haehahaehaehehea! I love this thread

>>58346072
Lolno, execution character set is term used to clarify that the character set used by an executing program isn't necessarily the same one the source code is written in. Characters have nothing to do with opcodes.

>>58344563
This insult made me want to cut myself

>>58347849
Only in terms of how cout formats in. You can still do arithmetic with it, assign sufficientluly small integer values to it (floats get rounded just like when theyre assigned to any other integer type} & u can use chars as counters in a for. Loop, if the range of values is small enough

>>58350430
finally

>>58351278
In C standard talk, "byte" means "object with a size of CHAR_BIT bits"

>>58346982
Okay, I laughed.

File: 14678427055860-pr.jpg (208KB, 1024x1448px) Image search: [Google]

208KB, 1024x1448px

Dick myDick = Optional.ofNullable(me.getDick()).orElse(DickUtils.DILDO);

>>58351569
that is just plain confusing

>>58344200
Really makes you think

>>58345053
>tfw too intelligent to go to parties
I don't want to disrupt the frivolous activities of the low classes

>>58351118
>black trap
does this even exist?

>>58345665
touch boobs

>>58351533
Yes but the fact that it's still a char makes it shit for function overloading.

>>58352176
To add. C++ added a bool type, so why the fuck not just add a byte type too?

>>58351943
no traps involved
private function `vag` takes long `bbc` and returns a Niglet

>>58352184
Just use an integer type

>>58344166
hehe