- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
#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/
3.14159265 08.03.2020 19:46 # +4
inkanusinho 08.03.2020 23:21 # +3
IIIuMnAH3E 09.03.2020 00:08 # 0
gostinho 09.03.2020 00:14 # 0
eukaryote 09.03.2020 03:08 # +3
Тут проблема в том, что он пытался писать на «C», но компилировал «Dev-C++». В итоге получилось говно, которое могут сожрать только кресты. Поэтому «C++».
IIIuMnAH3E 09.03.2020 04:35 # +3
Сишка не может проглотить ++++++++++++++++++++++++++++++++++++++++ far:
error: lvalue required as increment operand
eukaryote 09.03.2020 04:57 # +1
Именно поэтому я за.
IIIuMnAH3E 09.03.2020 05:39 # 0
IIIuMnAH3E 09.03.2020 04:47 # +3
https://ideone.com/1KMvNh
К сожалению, ничего изящнее в рамках чистой сишки придумать не могу.
3.14159265 13.03.2020 16:48 # 0
Попробуй #define.
Взрослые говорят что он вреден, но это ложь.
Ты сможешь отказаться #define в любой момент.
#define делает жизнь интереснее и ярче.
Если использовать препроцессор редко, то зависимость не возникает.
guest8 09.03.2020 09:25 # −999
guest8 09.03.2020 09:30 # −999
Fike 08.03.2020 23:43 # +1
IIIuMnAH3E 09.03.2020 00:06 # 0
IIIuMnAH3E 09.03.2020 00:35 # +4
https://ideone.com/IKPf7X
IIIuMnAH3E 09.03.2020 05:35 # 0
В «Паскале» есть отдельный символьный тип данных, там можно написать Inc(bukva); или bukva = Succ(bukva); а вот bukva := bukva + 1; написать нельзя.
В «C++» можно создать класс с перегрузкой операторов, у которого перегрузить операторы ++ и --, а про арифметические операторы «забыть».
А вот в сишке что-то подобное бывает?
gost 09.03.2020 05:39 # +1
§ 6.5.3.1/2 (N2346)
Так что нет, не бывает.
IIIuMnAH3E 09.03.2020 05:51 # +1
gost 09.03.2020 06:09 # +1
Кстати, в крестах есть https://en.cppreference.com/w/cpp/types/byte, для которого определены только битовые операции.
IIIuMnAH3E 09.03.2020 06:17 # 0
Компилятор сам догадывается вызвать у x оператор int(), хотя я его об этом не просил. В более реальных примерах это может привести к непредсказуемой питушне.
Вероятно, именно поэтому у std::byte не стали перегружать операторы каста, а просто сделали метод to_integer.
gost 09.03.2020 06:29 # +3
IIIuMnAH3E 09.03.2020 07:30 # 0
https://en.cppreference.com/w/cpp/language/explicit
guest8 09.03.2020 11:13 # −999
IIIuMnAH3E 09.03.2020 11:26 # +1
В языке Ада строгая типизация, предикаты, контракты. В нём нельзя просто так скопировать символ в число. Нужно указать, что именно ты хочешь получить.
Крестостандартизаторы захотели сделать что-то, как у взрослых дяденек, не переделывая сам язык. Для этого они наговнокодили класс из соломы и банановых листьев с нужными перегрузками и с директивой explicit.
bormand 09.03.2020 15:18 # 0
IIIuMnAH3E 10.03.2020 19:20 # 0
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, раньше его не было?
3.14159265 13.03.2020 17:20 # 0
Питушня там, а не «строгость и явность».
В кресты завозят не настолько сырые концепты.
gost 09.03.2020 11:33 # +2
IIIuMnAH3E 09.03.2020 11:49 # 0
https://govnokod.ru/26318#comment519640
https://govnokod.ru/26389#comment523404
1024-- 09.03.2020 15:04 # 0
Это питушня. Там можно сломать математику и писать в константную питушню. Написать любой питухкод.
Реальный пример - std::list<pituz>::iterator.
j123123 10.03.2020 10:17 # +2
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
При этом ++ -- вполне работает
IIIuMnAH3E 10.03.2020 10:29 # 0
1. ++p, --p
2. p = p + 1, p = p - 1
3. p += 1, p -= 1
Более того, они эквивалентны.
Тут всё хорошо.
Значит, примера, когда в сишке нужно применять именно ++p, потому что другие операции отсутствуют или неэквивалентны, нет?
guest8 10.03.2020 10:54 # −999
1024-- 10.03.2020 11:20 # 0
guest8 10.03.2020 11:24 # −999
gost 10.03.2020 11:36 # +1
В принципе, container.end() может быть чем угодно, главное, чтобы инкремент итератора, указывающего на последний элемент, возвращал этот самый container.end().
На практике же для какого-нибудь std::vector итератор — это просто (обёрнутый) указатель на соответствующий элемент во внутреннем массиве. В результате vec.end() — это указатель на элемент, следующий за последним (т.е. «arr + arr_size»).
Такой подход позволяет делать итераторы и их инкременты максимально быстрыми.
1024-- 10.03.2020 12:27 # 0
Мне понятно, почему плохие указатели не нужно разыменовывать, но вот абсолютно неясно, чем может насолить хранение плохого указателя. Под какой платформой начинается питушня, если кто-то сохранил указатель не туда, вычисление которого не вызвало переполнение и влезло в максимум для size_t, что это включили в стандарт?
P.S. Ну я вообще ещё не сильно понимаю, почему ещё диапазон size_t ограничен чем-то, кроме размеров size_t, и это ограничение не связано с конкретным типом (если бы у меня были питухи по 1 инту и по 100000 интов, я бы не удивился, если std::array<int, 1>::size_max был бы больше std::array<int, 100000>::size_max, и это бы вызывало компиляцию в более короткий size_t для второго случая), а стоит для всего языка.
gost 10.03.2020 12:44 # +1
Видимо, дальше они решили, что хранить покоцанные указатели никому нинужно, а раз нинужно — значит, можно просто забить хуй и не определять поведение этого говна.
Вообще, у меня складывается впечатление, что когда Комитету лень что-то делать — он это что-то объявляет UB и течёт.
Да, а что не так с size_t?
По Стандарту,
§ 17.2.4/3 (N4842)
То есть каких-то исхуйственных ограничений не ставится, это просто беззначный инт, в который влезет размер самого большого объекта, который на целевой машине можно в теории создать.
1024-- 10.03.2020 13:36 # +1
О, вот тогда мотив ясен, спасибо!
> Да, а что не так с 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 или ещё какой питушнёй.
gost 10.03.2020 13:55 # +2
Ко-ко-кокая-то залупа там с «rsize_t»:
§ K.3.5/2 (N2346)
§ K.3.5/4 (N2346)
1024-- 10.03.2020 14:10 # +2
bormand 10.03.2020 17:27 # 0
3.14159265 13.03.2020 15:22 # 0
Недавно я приводил хак, для вычисления размера массива/структуры.
bormand 10.03.2020 17:06 # +3
А ещё нельзя кастовать указатели на функции в обычные и наоборот - к примеру, на ARM'е указатель на функцию может быть нечётным (+1 от настоящего адреса).
guest8 10.03.2020 17:10 # −999
bormand 10.03.2020 17:25 # 0
guest8 10.03.2020 17:26 # −999
bormand 10.03.2020 17:28 # 0
3.14159265 13.03.2020 15:23 # 0
Кстати в последних итерациях штеуда и фьв unaligned access тормозит уже гораздо меньше.
guest8 10.03.2020 17:20 # −999
bormand 10.03.2020 17:22 # +1
guest8 10.03.2020 17:23 # −999
j123123 10.03.2020 17:43 # 0
В стандарте 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
guest8 10.03.2020 17:43 # −999
bormand 10.03.2020 17:44 # 0
j123123 10.03.2020 17:46 # 0
bormand 10.03.2020 17:47 # +1
j123123 10.03.2020 17:50 # +1
Именно так и есть в 8-битных AVR
bormand 10.03.2020 17:56 # +1
1024-- 10.03.2020 19:07 # +1
3.14159265 13.03.2020 17:30 # 0
https://en.wikipedia.org/wiki/NX_bit#Architecture_support
guest8 10.03.2020 17:48 # −999
3.14159265 13.03.2020 17:42 # 0
Вот только хотел написать.
Имелось ввиду W^X, да?
guest8 13.03.2020 17:56 # −999
3.14159265 13.03.2020 18:01 # 0
i386 CS, DS
С пентиумов адресация стала 36-разрядная.
По-народному называется PAE.
guest8 13.03.2020 18:03 # −999
3.14159265 13.03.2020 17:26 # 0
В x86-64 намутили ещё в 2005.
>из обычной оперативной памяти копировать байтики в особую исполняемую оперативную память
Запахло DEP и NX bit.
guest8 10.03.2020 17:46 # −999
bormand 10.03.2020 17:52 # +1
bormand 10.03.2020 17:45 # 0
З.Ы. Вечером проверю.
IIIuMnAH3E 10.03.2020 17:49 # 0
bormand 10.03.2020 17:53 # +1
IIIuMnAH3E 10.03.2020 17:56 # 0
guest8 10.03.2020 18:08 # −999
IIIuMnAH3E 10.03.2020 18:31 # 0
guest8 10.03.2020 18:36 # −999
IIIuMnAH3E 10.03.2020 18:38 # 0
bormand 10.03.2020 18:15 # 0
3.14159265 13.03.2020 15:17 # 0
Гру́ппа в математике — множество, на котором определена ассоциативная бинарная операция, причём для этой операции имеется нейтральный элемент (аналог единицы для умножения), и каждый элемент множества имеет обратный.
Один из примеров группы — множество целых чисел, снабжённое операцией сложения: сумма любых двух целых чисел также даёт целое число, роль нейтрального элемента играет ноль, а число с противоположным знаком является обратным элементом.
bormand 13.03.2020 17:58 # 0
Это скорее как точки на отрезке - я могу измерить расстояние между ними, могу прибавить или отнять от их координат число и получить новую точку, но сами точки я складывать не могу.
Т.е. это метрическое пространство, а не группа.
j123123 10.03.2020 10:25 # 0
3.14159265 13.03.2020 17:50 # 0
Но зачем-то в стандарт приделана функция fmod.
3.14159265 13.03.2020 16:50 # 0
> for(far = 0; far <= a; ++++++++++++++++++++++++++++++++++++++++ far)
Все обсуждали обилие плюсов.
Но никого, как я понимаю, не смутил цикл по плавающим питухам.
guest8 13.03.2020 16:59 # −999
3.14159265 13.03.2020 17:16 # 0