[C] Бесполезные типы данных?

stdint.h появился только в c99, а раньше с типами был бардак.

Как и нет stdint.h и прочих хидеров от C99

Поддерживает, и в 2010-й тоже. Либо .c файл, либо /Tc флаг.

В 2010 есть, в предыдущих версиях нужно было самому писать (или использовать готовые).

Поддерживает, и в 2010-й тоже. Либо .c файл, либо /Tc флаг.

И он даже вот такой код теперь проглатывает:

int main()
{
	int class = 8;
	return class;
}

В 2010 есть, в предыдущих версиях нужно было самому писать (или использовать готовые).

А поддержку C99 в 2010 добавили?

>long int - 4 или 8 байт
я кстати реально с этим сталкивался
пришлось long long для достоверности юзать

Тогда пардон)

Для достоверности как раз надо юзать int??_t типы.

так-то оно так, но я не стал изза того что я не доверяю как то сторонним типам =) тем более говорят что в студии нет, или еще где нибудь, изза этого юзаю int. А буду писать под специфические процы (если когда нибудь придется), то заюзаю int**_t, пока что не вижу смысла менять short и int на чтото другое

Должен, возможно надо будет /Tc указать, сейчас под рукой нет, чтобы проверить.

Полностью вроде нет, основные фичи есть. В gcc, насколько я знаю, тоже не всё реализовано.

>говорят что в студии нет, или еще где нибудь, изза этого юзаю int

Да, в 2005й действительно не было, сам же и сталкивался. Для виндового билда заюзал pstdint.h, всё было ок.

>float же, ну! Мат. сопроцессоры уже повсюду

Такой наивный.

ммм.. хорошо что есть сторонняя либа для студий..

$ cat test_sizeof.cpp 
#include <iostream>

int main(int argc, char* argv[]) {
  std::cout << "short: " << sizeof(short) << std::endl;
  std::cout << "int: " << sizeof(int) << std::endl;
  std::cout << "long: " << sizeof(long) << std::endl;
  std::cout << "long long: " << sizeof(long long) << std::endl;

  return 0;
}

$ g++ -m32 test_sizeof.cpp ; ./a.out 
short: 2
int: 4
long: 4
long long: 8

$ g++ -m64 test_sizeof.cpp ; ./a.out 
short: 2
int: 4
long: 8
long long: 8

У MS VC sizeof(long) в обоих случаях 4.

>float же, ну!

float? Эффективен? Только в тех редких случаях, когда можно избежать конверсии в double

Мат. сопроцессоры уже повсюду

вы в каком веке живете, они уже вымерли сто лет назад

Они не вымерли, их в основной камень впаяли.

Ну так ЧО, ответит кто-нибудь на вопрос топик-стартера? Нафига я должен догадаться использовать long, если есть int и никто не гарантирует, что long будет больше int?

> Ну так ЧО, ответит кто-нибудь на вопрос топик-стартера? Нафига я должен догадаться использовать long

Если ты не знаешь, зачем его использовать - не используй. Всё просто.

Не, вопрос не в том, почему я должен его ИСПОЛЬЗОВАТЬ, а почему я должен ДОГАДАТЬСЯ его использовать. Всё сложно.

> Не, вопрос не в том, почему я должен его ИСПОЛЬЗОВАТЬ, а почему я должен ДОГАДАТЬСЯ его использовать.

Опять же - не догадываешься -> не используешь.

Впрочем, если в 64-бит режиме long - 4 байта, я тоже не знаю, для чего он нужен %)

kiverattes, еще раз говорят тебе, что ты хуеблядская, толстотрольная проёёбина

Догадаться - не догадаться...

Вот ты попробуй, без знания архитектуры системы (т.е. 32 бита или 64) догадаться, какой тип у off_t. Вроде, по умолчанию, должно быть long long. Компилируешь так программку, работающую с файлами, а она - бац, и на размере 2Гб затыкается... А такая штука может и не сразу всплыть.

Так что, лучше везде писать #define _FILE_OFFSET_BITS 64 ...

Это не опять же, это о другом. Догадаться никак не связано с использованием, чеши тебя коленом.

Нет, просто long long long long long int.

Я не толстотрольная, ибо естественно при попытке разглядеть троллизм там, где его нет, тонкого троллизма не разглядишь, обязательно получается толстый.

А почему Вы должны догадаться что 3/2 дает 1 а не 1.5? RTFM наверное... че поделать, мы живем в несовершенном мире - c неба падает ледяной дождь, в Египте переворот а long-и бывают разные...

Ну вот я и спрашиваю почему. Непочему?

Так уж исторически сложилось...

Ок.

Ох да. double я и имел в виду. Правда-правда.

вы в каком веке живете, они уже вымерли сто лет назад

? Разве они не встроены непосредственно в CPU?

>int - это сокращенно от long int так что long int и просто int - одно и тоже

Школоло?

$ echo -e '#include <stdio.h>
> int main(){ printf("%d %d\\n", sizeof(int), sizeof(long int)); }' |gcc -xc -; ./a.out
4 8

>Разве они не встроены непосредственно в CPU?

Все-таки FPU и сопроцессор - это немного разные вещи

> Вижал студия не знает про твой int32_t, например.

Бгг, это поделие до сих пор так и не научилось C99 ?

>Так что, лучше везде писать #define _FILE_OFFSET_BITS 64 ...

вообще-то даже этого не достаточно :)
я гарантирую это)
в одном проекте (который тестил на разных архитектурах) пришлось писать так:
#if (defined(__USE_FILE_OFFSET64) || _FILE_OFFSET_BITS == 64 || __WORDSIZE == 64)

ps: хот дело было давно и под древнюю платформу. сейчас м.б. все и проще...

так что пожалуй погорячился с гарантией)

>>А что известно про long int? Только гарантированная ширина 32 бита.

4.2. Учи матчасть.

байт != 8 бит

> Бгг, это поделие до сих пор так и не научилось C99 ?

variable size arrays оно тож не умеет... ну то бишь a[n] при n не const.

Ну да, почему тебя не спросили - ты бы точно сделал всё правильно.

почему сразу все? он мог бы например только это сделать правильно

вот я не знаю, зачем нужены short, кроме как для того, чтобы попытаться определить int16_t, а если не получится — то заплакать сказать #error there is no 2-byte integral type on this compiler

так что его можно было бы сразу не вводить вообще

для char, допустим, есть отмазка, что это якобы размер одного символа (что не мешает его иметь (по слухам) кое-где в 4 байта); для short такой отмазки я не знаю

__u8 __u16 __32 __64 What else?

была бы моя воля - я бы в сях оставил четыре целочисленных типа:
byte - минимально адресуемая единица для конкретного процессора
sbyte - он же, знаковый
word - машинное слово, тип с шириной в sizeof(void*)
sword - знаковый word

а всех любителей попользовать типы с «размытыми» размерами, типа int и long, пересажал бы на колы

когда компьютеры были большими и слабыми, а 32-битная адресация была редкостью, модно было размеры переменных на стеке, размеры структур, и другого, задрач^W оптимизировать вплоть до отдельных байтов

Короче, Си это куча легаси говна сорокалетней давности. Не такого вонючего говна, как C++, но тем не менее.

Си тормозит прогресс в развитии операционных систем.

Благодаря тому, что на Си многие до сих пор пишут прикладной софт, мы имеем столько дерьмовых программ.

Его надо давно закопать к херам. Жаль долго еще не закопают - куда столько сишкодрочеров девать то.

и что взамен? жабку чтоли или си-шарп?

так у жабки виртуальная машина написана на с++, а у си-шарпа компилятор unmanaged

так что закапывалка еще не отросла :-)

> была бы моя воля - я бы в сях оставил четыре целочисленных типа:

byte - минимально адресуемая единица для конкретного процессора

sbyte - он же, знаковый

word - машинное слово, тип с шириной в sizeof(void*)

sword - знаковый word

Это потому, что ты молодой и глупый, и не знаешь, что такое PL/M, Bliss, и прочие BCPL.

у C# в .NET компилятор на .NET, емнип
жаба для прикладного софта неплоха, в принципе, но .NET лучше.

для системного софта надо придумывать нормальный язык, с GC и прочими плюшками, и пилить на нем ОС. чтобы забыть о линейной виртуальной памяти и прочем говне сорокалетней давности как о страшном сне. Что-то типа CL бы подошло, но CL для этой цели надо улучшать - добавлять низкоуровневые фичи, и фичи для многопоточного и асинхронного программирования.

да, давай попробуй докажи мне, нафига на современных системах нужен зоопарк char(название вообще смешное, с учетом реальности, т.е. юникода в т.ч.), short, long, int и прочего говна с хер пойми каким размером

Singularity уже есть. Но у MS вряд ли хватит духа сделать полностью managed ОС в продакшн, хотя могли бы на какие-нибудь мобильники засунуть.