- 001
- 002
- 003
- 004
- 005
- 006
- 007
- 008
- 009
- 010
- 011
- 012
- 013
- 014
- 015
- 016
- 017
- 018
- 019
- 020
- 021
- 022
- 023
- 024
- 025
- 026
- 027
- 028
- 029
- 030
- 031
- 032
- 033
- 034
- 035
- 036
- 037
- 038
- 039
- 040
- 041
- 042
- 043
- 044
- 045
- 046
- 047
- 048
- 049
- 050
- 051
- 052
- 053
- 054
- 055
- 056
- 057
- 058
- 059
- 060
- 061
- 062
- 063
- 064
- 065
- 066
- 067
- 068
- 069
- 070
- 071
- 072
- 073
- 074
- 075
- 076
- 077
- 078
- 079
- 080
- 081
- 082
- 083
- 084
- 085
- 086
- 087
- 088
- 089
- 090
- 091
- 092
- 093
- 094
- 095
- 096
- 097
- 098
- 099
- 100
double end_line( char data[0][200]){
double x = 0 , y = 0, sum = 0,ml = 0 ;
char *point = strtok( &data[1][0] , " " );
while( point != '\0' ){
if(isdigit( *point ) ){
ml = atof( (char *) point ) ;
push_stack_2( &topPTR_2,ml);
}
else if ( isOperator ( *point ) == 1 ){
y = pop_2(&topPTR_2);
x = pop_2(&topPTR_2);
if( *point == '^' ){
sum = pow(x, y) ;
push_stack_2( &topPTR_2, sum );
}
if( *point == '*' ){
push_stack_2(&topPTR_2, x * y );
}
if( *point == '+' ){
push_stack_2(&topPTR_2, x + y );
}
if( *point == '/' ){
push_stack_2(&topPTR_2, x / y );
}
if( *point == '-' ){
push_stack_2(&topPTR_2, x - y );
}
}
point = strtok(NULL , " " ) ;
return pop_2(&topPTR_2);
}
int in_line(char data[][200] , int lng ){
double x = 0 , y = 0, sum = 0 ;
int j = 0 , k = 0 , d = 0;
data[0][lng ] = ')';
push_stack(&topPTR, '(');
for (k = 0; check_stack((void *) &topPTR) != 1 ; k++) {
if ( isdigit(data[0][k]) || data[0][k] == '.' ) {
data[1][j++] = data[0][k];
}
if (data[0][k] == '(') {
push_stack(&topPTR, infix[0][k]);
}
if (isOperator(data[0][k]) == 1) {
data[1][j++] = ' ';
for (; precedence(topPTR->alpha, data[0][k]) != -1 ; ) {
data[1][j++] = pop(&topPTR);
data[1][j++] = ' ';
}
push_stack(&topPTR, data[0][k]);
push_stack(&topPTR, ' ' );
}
if (data[0][k] == ')') {
d = pop(&topPTR);
for (; d != '(' ; d = pop(&topPTR)) {
data[1][j++] = d;
}
}
else if (isalpha(data[0][k] ) ) {
puts ("error");
return 0;
}
}
return 1;
}
Follow us!
лукавая какая конструкция, лол
sizeof(data)
стопудово сделает
надо вообше запретить этот говносвинтаксис
После сишки ты осилишь джаву. А после джавы у тебя такой брейн демдж, что ты не понимаешь что и как и куда передается
ну кстати нет
Сишнику легко будет понять, что массив в джаве это объект в куче, с которым работают через указатель
А вот джависту понять си будет куда сложнее
А есть вообще такие языки?
В том же паскале можно передать массив без var/const?
На самом деле в стек пушится не сам массив, а указатель на его копию. Вызывающий код снимает копию с массива и передаёт в функцию указатель, а после возврата освобождает память от этой копии.
С точки зрения же кода на «Паскале» всё выглядит так, как будто передали значение.
_______________________________________
*кроме запханных в структуры
Сейчас придёт KOPOHABuPYC и скажет, что ты с ним скоро встретишься.
неужели ёбаный рак всё еще жив?
а тут?
void func3(foo& massiv5)
(это плюсики)
В параметрах функции char data[100][200] эквивалентно char data[][200] и эквивалентно char (*data)[200]. Без скобочек, кстати, получится совершенно другая питушня. Попрошу не путать, а то могут и напутать.
Правда, легко запомнить?
Причем массив превращается в указатель только при вызове.
В струкутре или просто в памяти он в него не превращается.
za4em?za4em?
Да, при заворачивании массива в массив передастся указатель. Но второй уровень не развернётся, он останется массивом.
Правда, очевидно?
в стек мне скопируется все равно указатель, но указывать он ьудет не на другой указатель, а на массив
так?
1. массив передаётся как указатель на переменную типа его элемента
2. поэтому - указатель.
Но всё равно это, в сущности, говно. Потому, что
1. Для char a[7][7]; как переменной sizeof(a) равен 49. Почему тогда для char a[7][7] как аргумента - как указатель.
2. Функция всё равно знает размерности массива, запись младших размеров в типе жизненно важна для доступа к элементам, и потому используется.
Я, конечно, могу понять, почему если записать в аргументе char* и потом передать char[10] или char[20], sizeof скажет одно и то же. Потому, что запись "char*" ничего не говорит о точном количестве элементов. Аналогично - с "char[]".
Но когда я явно записал "char[7][11][13]", почему нельзя это запомнить и учесть? Ведь сишка умеет помнить N-1 размеров, когда это выгодно ей самой. А как программист попросил запомнить ещё одно сраное число - так всё - садись на указатель.
1. Для char a[7][11] sizeof(a) равен 77.
2. Для char a[][11] sizeof(a) вызывает ошибку компиляции.
3. Для char (*a)[11] sizeof(a) равен sizeof(void*)
P.S. вообще, типы вида char[] нужно выпилить как нелогичное говно, поскольку уже есть char[размер] и char*, которые покрывают все случаи и не имеют проблем с семантикой.
(char[7][11]).sizeof == 77
(char[][11]).sizeof == 176 // char[] - это встроенный динамический массив
(char*[11]).sizeof == 88 // массив из 11 указателей
Например, в C++ есть хотя бы std::shared_ptr<std::array<char, 11>> и std::array<std::shared_ptr<char>, 11>.
А для функций?
P.S. Бесит, когда имя типа надо читать по спирали и по словарю иероглифов, а также когда имя переменной вставляется куда-то в середину имени типа.
(char[11]*).sizeof == 8
Функции пишутся так:
int abc(int x) { return x + 1; }
int function(int) fp = &abc;
https://freepascal.org/docs-html/current/ref/refsu68.html
И ещё есть динамические массивы:
https://freepascal.org/docs-html/current/ref/refsu14.html
Т. е. Ди в чём-то похож на Object Pascal, только с сишным синтаксисом.
Нет. В C есть только модификаторы типа одного вида c говённым синтаксисом, а в C++ - двух видов - с говённым синтаксисом и с чуть получше.
Питушня со скобками - часть синтаксиса C++, которую нельзя использовать C
> Плюсовый вариант не равен сишному по функционалу.
Это мелочи. В некотором смысле там описываются массив указателей и указатель на массив.
С точки зрения использования, массив - это питушня, у которой можно взять длину и элементы, а указатель - небольшая питушня, которая может дать доступ к психозе в памяти.
В C++старьё и C++11+ можно использовать using template или иную питушню, чтобы скорректировать поведение.
std::array - это костыль, с помощью которого к указателю на массив добавляют длину, а это есть у всех массивов в Ди.
Сборка мусора не нужна, кстати.
Это самая большая глупость (после скриптовых языков)
Вот мне для программы надо хранить и доставять несколько значений одного типа, и я хочу узнать, в каком языке будет удобнее это делать.
Задач, где требуется именно "анскильная питушня, притворяющаяся указателем на блок в памяти, где лежит непонятное число элементов, к которой можно прибавлять числа, чтобы получить анскильную питушню, указыающаю на следующие элементы", исчезающе мало.
Поехавших, которым требуется для работы именно такая питушня, и которые скажут "не стоит это путать с std::array из C++ или Array из JS, это принципиально другое" уже развезли по дуркам и отобрали у них электронно-вычислительные устройства.
Но вот сравнивать вычислительные языки общего назначения, такие как C, C++, D, C#, Haskell, JS, между собой - вполне себе нормально.
Тем более, что мы начинали с хранения размера массива. Это вообще не относится к сборке мусора. В одном и том же C++ без сборки мусора есть и вариант массивов, которые хранят длину, и - которые не хранят.
Аналогично, в Java можно вполне себе реализовать Array2 с методами getElement и setElement, но без length, и он будет работать абсолютно так же, как и void* в C, но будет подвергаться сборке мусора.
> Это самая большая глупость (после скриптовых языков)
Какой багор )))
Вам что, хочется все переменные питушить руками?
Без сборки мусора даже два вектора сложить - отдельный пердолинг. Вместо c = a + b или c = f(a + b) нужно писать лишний бойлерплейт, чтобы явно сохранить временное значение суммы и удалить временное значение суммы и слагаемые.
Единственное, к сборке мусора необходимо прикручивать явное удаление объекта. Нечасто, но таки не никогда, требуется явно удалить большой объект и освободить память, либо закрыть файл. В языке с GC должно быть 3 оцпии:
*
* вызов деструктора
* вызов деструктора и удаление
В первом случае объект убивается и подчищается на этапе сборки мусора, во вторм - убивается на этапе вызова, очищается на этапе сборки мусора, в третьем - убивается и очищается на этапе вызова.
* Автоматизирует питушню
* Удаляет объекты, когда это удобно алгоритму, а не программисту
С ARC'ом такие данные очень неудобно обрабатывать, надо думать где будут сильные связи, а где слабые.
И ещё ГЦ иногда работает быстрее, если ты порождаешь тонны мелких объектов и тут же их удаляешь. Но это обычно можно тупо убрать на стек и не дрочить аллокатор.
На всём остальном ГЦ тупо сосёт.
Если же ты все равно его понимаешь, то что мешает тебе придлерживаца простого правила:
* у папы сильная ссылка на ребенка
* все остальные ссылки слабые
Это же физически так и устроено: папу убили -- и все дети самовыпилились.
Если у тебя много мелких объектов, то проще сделать арену, засрать её под завязку, и потом грохнуть.
Ну либо выудить место в стеке, как ты сказал, и потом тоже грохнуть круто крутанув SP.
ГЦ не нужен
Ку-ка-ре-ку! Скрип-туш-ня!
Кстати да, добавляю четвёртый пункт в предложение:
4. Для char *a[11] sizeof(a) равен (11 * sizeof(void*))
Легко, если знать, как запоминать.
Массив elem_t имеет тип elem_t[число] и эквивалентен указателям типа elem_t[] и elem_t*. На месте elem_t может быть произвольный тип, например double, int[10][20], int(*)(float[][200], time_t).
https://ideone.com/ep4v00
Самая ненужная функция в мире
Мы не можем использовать эту функцию для обработки более чем одной строки. Чтобы начать обрабатывать вторую строку, мы должны закончить обрабатывать первую.
Кстати, как это работает с многопоточностью?
Так делали функции в 1971 году, в 2020 юзать её не надо
ты видел сырцы первого юникса на си?
там царский код, и каждая утилита состоит из одного .c файла строк на двести. Это было еще до манифеста про структурное программирование, никто и не думал о реюзабильности
Нормально. Всё это говно сейчас с тредлокалами.
> зачем так делали
Дык тогда не было тредов, даже идеи такой не было. Вот и не парились про глобалки.
Если такси шарят кучу, то питухи называют их потоками.
Если не шарят -- то процесами.
Еще есть наверное pid у них, но то такое
А потоки это высокоуровневая абстракция библоиотиеки pthreads и ее друзей.
Но так как внутри ядра есть понятие кернел треды (ну которые как систем треды в винде) то шутка не удалась.
Я, в целом, согласен, что прыщеподход лучше виндового.
Кстати, а как сделано у яблока? Вроде, у mach тоже таски?
кстати, о прерыва таймр
знаешь про
https://en.wikipedia.org/wiki/Tickless_kernel ?
С копропротивной корпоративной многозадачностью всё ясно — там каждое приложение само отдаёт тики, вызывая соответствующий сисколл, когда оно свободно.
С вытесняющей по таймеру тоже ясно.
А tickless как работает?
Смысл в том, что операционка заводит таймер на далёкое будушее, и ложится спать.
Раньше многозадачность была именно такой. Приходилось пися код помнить, что ты не один на свете.
Потом изобрели вытесняющую многозадачность на таймере, и стало можно писать код так, словно бы ты один. Ну то-есть хуеть типа "while(1){}" конечно не надо, но можно не елдиться постоянно.
А потом питузы снова изобрели коопертивку посредством асинков. И опять стало надо писать код помня, что есть и другие питухи.
И все страшно радуются.
А, блядь.
Как харашо стало, Блядь.
Ёбаные милениалы переизобрели деревянное колесо, и записали это себе в заслуги.
Гомосапиенсы туповаты, конечно.
надо бы его удалить
„Его особенностью была возможность поиска людей, одновременно находящихся на любом сайте Интернета. Например, находясь на сайте Википедии, можно было включить «радар» и увидеть на нём всех людей, просматривающих этот сайт, после чего начать общаться с ними. Таким образом можно было найти единомышленников.“
Т. е., если бы он не закрылся в 2007-м году, можно было бы, например, в нём найти всех, кто просматривает «Говнокод»?
http://www.govnokod.ru/23400