Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+5
#include <stdio.h>
#define UPP 300
float conversion(float fahr);
main(){
float far;
int a;
a = UPP;
for(far = 0; far <= a; ++++++++++++++++++++++++++++++++++++++++far)
printf("%.f\t%.1f\n", far, conversion(far));
}
float conversion(float cels){
float c;
c = ((5*(cels-32))/(9));
return c;
}
how do I make it 20 by 20 in a shorter way, without having to put 20 times "++" please
https://www.reddit.com/r/C_Programming/comments/ff5zph/how_do_i_make_it_20_by_20_in_a_shorter_w ay/
Запостил: 
eukaryote,
08 Марта 2020
Follow us!
Тут проблема в том, что он пытался писать на «C», но компилировал «Dev-C++». В итоге получилось говно, которое могут сожрать только кресты. Поэтому «C++».
Сишка не может проглотить ++++++++++++++++++++++++++++++++++++++++ far:
error: lvalue required as increment operand
Именно поэтому я за.
https://ideone.com/1KMvNh
К сожалению, ничего изящнее в рамках чистой сишки придумать не могу.
Попробуй #define.
Взрослые говорят что он вреден, но это ложь.
Ты сможешь отказаться #define в любой момент.
#define делает жизнь интереснее и ярче.
Если использовать препроцессор редко, то зависимость не возникает.
https://ideone.com/IKPf7X
В «Паскале» есть отдельный символьный тип данных, там можно написать Inc(bukva); или bukva = Succ(bukva); а вот bukva := bukva + 1; написать нельзя.
В «C++» можно создать класс с перегрузкой операторов, у которого перегрузить операторы ++ и --, а про арифметические операторы «забыть».
А вот в сишке что-то подобное бывает?
§ 6.5.3.1/2 (N2346)
Так что нет, не бывает.
Кстати, в крестах есть https://en.cppreference.com/w/cpp/types/byte, для которого определены только битовые операции.
Компилятор сам догадывается вызвать у x оператор int(), хотя я его об этом не просил. В более реальных примерах это может привести к непредсказуемой питушне.
Вероятно, именно поэтому у std::byte не стали перегружать операторы каста, а просто сделали метод to_integer.
https://en.cppreference.com/w/cpp/language/explicit
В языке Ада строгая типизация, предикаты, контракты. В нём нельзя просто так скопировать символ в число. Нужно указать, что именно ты хочешь получить.
Крестостандартизаторы захотели сделать что-то, как у взрослых дяденек, не переделывая сам язык. Для этого они наговнокодили класс из соломы и банановых листьев с нужными перегрузками и с директивой explicit.
There are no implicit conversions from the values of a scoped enumerator to integral types, although static_cast may be used to obtain the numeric value of the enumerator.
То есть в кресты начинают потихоньку добавлять строгость и явность, которые в «Паскале» были изначально.
enum class вроде добавили только в C++11, раньше его не было?
Питушня там, а не «строгость и явность».
В кресты завозят не настолько сырые концепты.
https://govnokod.ru/26318#comment519640
https://govnokod.ru/26389#comment523404
Это питушня. Там можно сломать математику и писать в константную питушню. Написать любой питухкод.
Реальный пример - std::list<pituz>::iterator.
https://overiq.com/c-programming-101/pointer-arithmetic-in-c/
The only valid arithmetic operations applicable on pointers are:
1) Addition of integer to a pointer
2) Subtraction of integer to a pointer
3) Subtracting two pointers of the same type
При этом ++ -- вполне работает
1. ++p, --p
2. p = p + 1, p = p - 1
3. p += 1, p -= 1
Более того, они эквивалентны.
Тут всё хорошо.
Значит, примера, когда в сишке нужно применять именно ++p, потому что другие операции отсутствуют или неэквивалентны, нет?
В принципе, container.end() может быть чем угодно, главное, чтобы инкремент итератора, указывающего на последний элемент, возвращал этот самый container.end().
На практике же для какого-нибудь std::vector итератор — это просто (обёрнутый) указатель на соответствующий элемент во внутреннем массиве. В результате vec.end() — это указатель на элемент, следующий за последним (т.е. «arr + arr_size»).
Такой подход позволяет делать итераторы и их инкременты максимально быстрыми.
Мне понятно, почему плохие указатели не нужно разыменовывать, но вот абсолютно неясно, чем может насолить хранение плохого указателя. Под какой платформой начинается питушня, если кто-то сохранил указатель не туда, вычисление которого не вызвало переполнение и влезло в максимум для size_t, что это включили в стандарт?
P.S. Ну я вообще ещё не сильно понимаю, почему ещё диапазон size_t ограничен чем-то, кроме размеров size_t, и это ограничение не связано с конкретным типом (если бы у меня были питухи по 1 инту и по 100000 интов, я бы не удивился, если std::array<int, 1>::size_max был бы больше std::array<int, 100000>::size_max, и это бы вызывало компиляцию в более короткий size_t для второго случая), а стоит для всего языка.
Видимо, дальше они решили, что хранить покоцанные указатели никому нинужно, а раз нинужно — значит, можно просто забить хуй и не определять поведение этого говна.
Вообще, у меня складывается впечатление, что когда Комитету лень что-то делать — он это что-то объявляет UB и течёт.
Да, а что не так с size_t?
По Стандарту,
§ 17.2.4/3 (N4842)
То есть каких-то исхуйственных ограничений не ставится, это просто беззначный инт, в который влезет размер самого большого объекта, который на целевой машине можно в теории создать.
О, вот тогда мотив ясен, спасибо!
> Да, а что не так с size_t?
Мне казалось, что в мире C/C++
UINT_MAX == pow(2, sizeof(int) * CHAR_BIT)) - 1,
а
SIZE_MAX < pow(2, sizeof(size_t) * CHAR_BIT)) - 1,
и потому size_t выделяется на фоне остальных чисел, все биты которой забивают полезной информацией. Хотя, я мог спутать это с ptrdiff_t или ещё какой питушнёй.
Ко-ко-кокая-то залупа там с «rsize_t»:
§ K.3.5/2 (N2346)
§ K.3.5/4 (N2346)
Недавно я приводил хак, для вычисления размера массива/структуры.
А ещё нельзя кастовать указатели на функции в обычные и наоборот - к примеру, на ARM'е указатель на функцию может быть нечётным (+1 от настоящего адреса).
Кстати в последних итерациях штеуда и фьв unaligned access тормозит уже гораздо меньше.
В стандарте POSIX на это забили хуй
https://pubs.opengroup.org/onlinepubs/9699919799/functions/dlsym.html
> Note that conversion from a void * pointer to a function pointer as in:
> is not defined by the ISO C standard. This standard requires this conversion to work correctly on conforming implementations.
Поэтому я за POSIX
Именно так и есть в 8-битных AVR
https://en.wikipedia.org/wiki/NX_bit#Architecture_support
Вот только хотел написать.
Имелось ввиду W^X, да?
i386 CS, DS
С пентиумов адресация стала 36-разрядная.
По-народному называется PAE.
В x86-64 намутили ещё в 2005.
>из обычной оперативной памяти копировать байтики в особую исполняемую оперативную память
Запахло DEP и NX bit.
З.Ы. Вечером проверю.
Гру́ппа в математике — множество, на котором определена ассоциативная бинарная операция, причём для этой операции имеется нейтральный элемент (аналог единицы для умножения), и каждый элемент множества имеет обратный.
Один из примеров группы — множество целых чисел, снабжённое операцией сложения: сумма любых двух целых чисел также даёт целое число, роль нейтрального элемента играет ноль, а число с противоположным знаком является обратным элементом.
Это скорее как точки на отрезке - я могу измерить расстояние между ними, могу прибавить или отнять от их координат число и получить новую точку, но сами точки я складывать не могу.
Т.е. это метрическое пространство, а не группа.
Но зачем-то в стандарт приделана функция fmod.
> for(far = 0; far <= a; ++++++++++++++++++++++++++++++++++++++++ far)
Все обсуждали обилие плюсов.
Но никого, как я понимаю, не смутил цикл по плавающим питухам.