DjangoBB LoFi version

Полная версия: Прошу помощи. Супер сложное задание!

Начало » Python для новичков » Прошу помощи. Супер сложное задание!

1 2 3 4 5 6 7 8

py.user.next

Май 1, 2017 09:08:16

Shaman
Там же и знать особо нечего. :)

Очень часто встречаются эти, которые знают язык “C/C++”. Потом пишут какую-нибудь быдлятину, профессора вузов.
Там надо ориентироваться в стандартах, иначе используешь какую-нибудь фишку, а она либо слишком новая, либо слишком старая. А что это значит? А работает не так, как ожидается. Нужно знать, как проводятся неявные преобразования типов, иначе напишешь что-нибудь вроде правильно, а баг потом на этом вылезет где-нибудь гораздо позже. Знаешь, вот бывает ошибка, когда операцию правого сдвига применяют к знаковому значению? Распространённая ошибка. А там раз потом и отрицательное число появляется и начинает сдвигаться. Он-то думал, там знак сохраняется (ему казалось), а там надо точно знать, что знак непредсказуемый. Нюансов там много есть подобных. Поэтому там надо знать историю языка, где какой диалект.

Вот определение функции с двумя ошибками

const char *f(a) char a; {return 0;}

Вот ты напишешь его, он тебе ничего не скажет.

Вот так нормально

char *f(a) int a; {return 0;}

А как ты это узнаешь? Тут надо стандарт помнить.

То есть если тебе кажется, что ты знаешь C потому, что оно ничего не пишет, то это ещё ничего не значит. Оно и на неправильный код может не писать ничего. Есть сейчас штука такая, которую усиленно рекламируют, - статический анализатор, вот он умеет подобные моменты отлавливать, потому что пытается более умно осмыслить то, что написано, и учитывает стандарты и распространённые ошибки. А компилятор - нет, он пропустит спокойно и ты будешь запускать неправильный код просто.

Shaman

Май 1, 2017 09:40:33

Я всего лишь подразумевал большую простоту чистого С в сравнении с Питоном, у которого тот же самострел определяется только по факту.
Кстати, почему нужно считать ошибкой то, что компилятор пропускает?

doza_and

Май 1, 2017 09:49:49

Shaman
Кстати, почему нужно считать ошибкой то, что компилятор пропускает?

Ошибкой оно становится тогда когда вы в документации одно написали а оно делает другое.
А так оно может и синтаксически неверный код не ошибка. Для этого например pragma error сделали.
Ну и компиляторы разные бывают… на одном соберется а на другом нет.

Shaman

Май 1, 2017 09:51:58

doza_and
Ошибкой оно становится тогда когда вы в документации одно написали а оно делает другое.

Вот именно! Но не раньше.

py.user.next

Май 1, 2017 09:58:25

Shaman
Я всего лишь подразумевал большую простоту чистого С в сравнении с Питоном

Это если ты стандарт прочитал. Он довольно-таки математически написан, то есть очень точно. Но стандарт надо читать, а на это нужно время. Никто не читает, а потому делает ошибки, не зная, например, что длинные числа в константах могут просто обрезаться. То есть ты пишешь, например “int a = 123451234512345;” а попадает туда “56789”. Откуда? То есть компилятор тебе всё скомпилировал, никаких ошибок нет. Вот я такую фигню как-то разгребал на форуме на одном. Не было понятно, откуда-то ошибка и всё. Вот оказалось, что обрезается эта фигня, если не помещается. То есть это нужно знать, какого размера в битах допустимы числовые константы. Иначе она тихонько будет фигню какую-то выполнять.

Shaman
Кстати, почему нужно считать ошибкой то, что компилятор пропускает?

Сам компилятор может быть не очень хорошо реализован и просто не знать всех этих нюансов. Поэтому есть вот эти анализаторы, которыми прогоняешь код и они отлавливают такие вещи. Я вот нашёл баг тогда в gcc, в функции printf() или scanf() по-моему, и написал в багтрекер им, и где-то через года два они мне написали туда, что баг исправлен теперь в связке с таким-то другим багом. То есть сам компилятор тоже может упускать что-то. Это было именно копание в стандарте, какой-то редкий нюанс, который я, изучая стандарт, сразу же проверял на практике.

А в питоне у тебя всё контролируется само, тебе там исключение на каждом шагу посылают и так далее. Если ты в питоне, откроешь, например, файл, то он выпадет, если не сможет прочитать его. А в сишнике такого нет, просто будет читать мусор и выдавать тебе, будто ты и просил мусор, в виде вот каких-то таких чисел. В питоне можно ещё по наитию что-то понять, в сишнике такого нет - либо знаешь, либо не знаешь.

Shaman

Май 1, 2017 10:15:12

py.user.next
обрезается эта фигня, если не помещается

Ну так не нужно же впихивать невпихуемое.
Если оставить за рамками баги компиляторов, для каждого есть документация с информацией о поддержке стандартов. Дальше достаточно просто сопоставить потребности с возможностями.

py.user.next
А в сишнике такого нет, просто будет читать мусор и выдавать тебе

Там есть статус завершения операции.
С Питоном наблюдается постоянная возня около типов значений, кодировок, точности операций над дробями и мутабельных объектов.

py.user.next

Май 1, 2017 11:55:37

Shaman
Там есть статус завершения операции.

Вот пример

#include <stdio.h>

int main(void)
{
    FILE *fp;
    int c;
    int ret;

    fp = fopen("file.txt", "r");

    ret = putc('x', fp);
    printf("putc(): %d\n", ret);

    while ((c = getc(fp)) != EOF) {
        printf("read %d\n", c);
    }
    printf("ferror(): %d\n", ferror(fp));

    fclose(fp);
    return 0;
}

[guest@localhost c]$ cat file.txt 
abc
[guest@localhost c]$ .ansi t.c -o t
[guest@localhost c]$ ./t
putc(): -1
read 97
read 98
read 99
read 10
ferror(): 1
[guest@localhost c]$

Если там вообще ничего не проверять, программа работает, будто ничего не происходит. Если же проверять не там, то непонятно, где возникла ошибка в файловом потоке - при чтении или не при чтении. То есть нельзя сказать, что при чтении не было ошибки. То есть перед чтением нужно знать про флажок ошибки внутри потока, иначе может получиться так, что безошибочное чтение будет выглядеть как ошибочное. Это здесь видно, что ошибка выставлена до чтения, а где-то оно будет далеко и глубоко просходить, что будет незаметно вообще, что на ошибку потока что-то влияет.

А вот питон

#!/usr/bin/env python3

f = open('file.txt')
f.write('x')
f.read()
f.close()

[guest@localhost c]$ ./t.py 
Traceback (most recent call last):
  File "./t.py", line 4, in <module>
    f.write('x')
io.UnsupportedOperation: not writable
[guest@localhost c]$

Тут оно сразу выпадет и всё, и даже чтения никакого не будет выполняться.

Shaman

Май 1, 2017 22:39:01

Окей.
А если сравнить объёмы стандартных библиотек и количество поддерживаемых парадигм? Или хотя бы количество типов потоковых объектов?

py.user.next

Май 2, 2017 01:08:05

Shaman
А если сравнить объёмы стандартных библиотек и количество поддерживаемых парадигм? Или хотя бы количество типов потоковых объектов?

Ну, в питоне ничего знать не надо особо. То есть я сам, бывает, учусь прямо из питона каким-то сложным вещам, потому что и в документации всё разжёвано (не сравнить с RFC, их тоже читаю иногда), и само устройство этих средств довольно просто, ими легко пользоваться, и исходники есть (я как-то смотрел алгоритм base64 прямо в них (сам его написал, а потом сравнивал с питонячьим - удобно учиться так)). А в сишнике, например, чтобы сделать потоки, надо много чего прочитать и нужны какие-то примеры, и не один пример. А в питоне документация приводит примеры и они все простые - через пять минут у тебя уже пул потоков работает какой-нибудь там. Я вот регулярки учил в питоне, а до этого они казались сложными (там ведь несколько видов, где-то есть средства, где-то нет средств). Поэтому хорошо с питона начинать программировать, так как в нём знать ничего не надо.

А в сишнике хоть и меньше всего, но вот за счёт этих неявных вещей, которые возлагаются на программиста, нужно знать больше про каждую операцию, иначе сделаешь ошибку и даже не поймёшь этого.

В питоне я вот документацию не читаю, потому что времени нет на это, хотя хочется. А не читаю, потому что прямо в интерпретаторе всё выясняю обычно, проверяю, если ошибку не выдаёт, значит правильно всё понял. И для питона это работает, потому что везде там исключения, если что неправильно.

Так что вот этот парадокс, что C хоть и меньше, но сложнее, а питон хоть и больше, но проще, существует за счёт неявного. Но и плюс C в том, что он ближе к дикому миру (к системному программированию), потому что он сам такой. Он - как дикий жеребец, которого сложно оседлать, но если ты его оседлаешь, то он выносливее и хитрее обычной домашней лошади, поэтому даёт больше плюсов при производстве программ, так как реальные программы имеют дело с диким миром, это не какие-то там учебные программки, в которых всё удобно изначально.

Shaman

Май 3, 2017 07:14:26

C С приходится знать не про язык, а про операционку и предметную область. Так это нормальная ситуация ведь.