- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
#include <stdio.h>
#include <stdlib.h>
typedef struct {
int field1;
int field2;
} teststr;
typedef struct {
char data[sizeof(teststr)];
} teststr_holder __attribute__ (( aligned (__alignof__ (teststr)) ));
typedef union {
teststr n1;
teststr_holder n2;
} str_conv;
int field1_get(teststr_holder a)
{
str_conv cnv = {.n2 = a};
return cnv.n1.field1;
}
int field2_get(teststr_holder a)
{
str_conv cnv = {.n2 = a};
return cnv.n1.field2;
}
teststr_holder init_teststr(int field1, int field2)
{
str_conv cnv = {.n1 = {field1, field2}};
return cnv.n2;
}
int main(void)
{
teststr_holder a = init_teststr(1234, 5678);
printf("%d %d\n", field1_get(a), field2_get(a));
return EXIT_SUCCESS;
}
нет ли тут UB?
void* завезли в c89 кажется, в K&R его не ьыло
потом понарадился всякий скрипторак
З.Ы. Инкапсуляция? Но у тебя sizeof/alignof не скомпилятся не увидев структуру. Т.е. она один фиг в паблик торчит.
Сишники плакали, кололись, но продолжали генерить обвес для инкапсуляции и полиморфизма.
не документируй функци -- вот тебе и инкапусляция
слинкуйся с другим .so, вот тебе и полямофризм
Не работает это так. Всем насрать, что они не документированы.
Уже сколько примеров было, когда софт юзал структуры из опенсурсных либ напрямую, а авторам либ приходилось свои правки откатывать и тащить совместимость дальше.
Юзерам похуй кто был прав, а кто писал говно. Посыпалась куча софта после обновления либы - значит либа виновата.
А private то не завезли.
тип это не символ и он не линкуеца же
* static внутри фукнции влияет на время жизни. Он живет вечно, но доступен только внутри функции (примерно как статическое приватное поле в жабах и шарпах)
* static на топлевеле запрещает доступ к символу из других единиц трансляции
Лучше уже ничего не закрывать: завязался на говно -- сам себе злобный.
Это не работает когда ты Торвальдс, но мы не торвальдсы
А HANDLE это смещение в таблице хендлов процесса (в структуре EPROCESS кажется).
Вроде бы примерно так, но могу наврать
Кстати, сисколы в винде не документированы: API винды это Win32API (и частично NativeAPI, только в документированных местах). Это не линукс, где сисколы и их ABI рок солид
https://govnokod.ru/23287#comment389547
> Тоесть, смотрите, как ведет себя настоящий, состоявшийся, знающий себе цену программист? А он ведет себя очень просто: плюсы - говно, но и си - говно, кричит он громко, ничуть не смущаясь подходящих к нему слева - одептов плюсов, а справа - почетателей битоебского низкоуровневого язычка типа Си
Так что крестоговно сосет
UPD: ну и собирать единый язык проще. Добавлять в сборку лишний этап — геморрой.
Не факт. Свой генератор я могу написать через какие-нибудь гомоиконы, и там этой крестопараши не будет
Для достижения аналогичного результата твоему генератору на гомоиконах в любом случае придётся проанализировать весь крестокод, найти вызовы add(), вычислить типы аргументов и сгенерировать две специализации — add<int, int> -> int и add<int, double> -> double. И это ещё самый простой пример.
Я вообще о другой хуйне. Вот хотим мы делать кодохуерацию не только в Си, но и в Java допустим, а там типопитушня отличается. Какие есть предложения? Ну если надо чтоб хуйня с такими типами превращалась в вызов того говна, а хуйня с другими типами - в вызов другого, можно дрочиться с каким-то говном, умеющим анализировать код, чтобы смотреть, тот ли тип мы в такую-то поебень передаем, или не тот (при этом отдельно дрочиться в Си, отдельно в жабе), а можно тупо не завязываться на языковую типопитушню, и просто генерить код, реальный пример: https://govnokod.ru/23246#comment388906
Настоящие Цари не опускаются до такого анскильного говна
Что-то типа
Средствами крестоговна такое просто нельзя реализовать, разве что написать нахуй парсер крестов в constexpr и через парашу типа std::embed https://govnokod.ru/26022 свой же исходник парсить. А через какие-то костыли через clang какой-нибудь можно сделать намного проще.
Говностандартизаторы могут конечно насрать в стандарт нового говна, и тогда арсенал немного увеличится, но предыдущие компоненты говнорецепта остаются теми же.