LINUX.ORG.RU

исходный код Python


0

1
static PyObject *
join_list_unicode(PyObject *lst)
{
    /* return u''.join(lst) */
    static PyObject *sep = NULL;
    if (sep == NULL) {
        sep = PyUnicode_FromStringAndSize("", 0);
        if (sep == NULL)
            return NULL;
    }
    return PyUnicode_Join(sep, lst);
}

Зачем после присвоения NULL sep тут же проверять на равенство NULL?


static PyObject *sep = NULL; if (sep == NULL) {

RA ()

он же статик, т.е. при следующем вызове там может быть не NULL

dismal_faun ★★ ()

Я так понимаю для thread-safe.

hippi90 ★★★★ ()
Ответ на: комментарий от dismal_faun
#include <stdio.h>

void lol() {
    static int smth = 13;
    if (smth == 13) {
        printf("13/");
        smth = 666;
    } else {
        printf("666\n");
    }
}

int main() {
    lol();
    lol();
}

результат само собой:

13/666

dismal_faun ★★ ()
Ответ на: комментарий от dismal_faun

вызывают всю функцию или код после присвоения? хоть сто раз вызови функцию каждый раз ей присвоется NULL.

RA ()
Ответ на: комментарий от dismal_faun

а почему второй раз пропускается static int smth = 13;?

RA ()
Ответ на: комментарий от RA

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

hippi90 ★★★★ ()
Ответ на: комментарий от hippi90

Да. Кто редко пользуется статическими, или в первый раз их встречает,
вот как я, то эта строка вводит в недоумение. Таковы уж правила языка.

Позвольте пользуясь чужой темой задать вопрос.
Пусть имеется СИ-функция, содержащая константный массив чисел:


struct jpc {
    const int *arr;
    int       Larr;
};

void fun(struct jpc *jpc)

{
    const int arr[]={
        0x01, 0x02, 0x03, 0x00, 0x04, 0x11, 0x05, 0x12,
        0x21, 0x31, 0x41, 0x06, 0x13, 0x51, 0x61, 0x07,
        0x22, 0x71, 0x14, 0x32, 0x81, 0x91, 0xA1, 0x08,
        0x23, 0x42, 0xB1, 0xC1, 0x15, 0x52, 0xD1, 0xF0,
        0x24, 0x33, 0x62, 0x72, 0x82, 0x09, 0x0A, 0x16,
        0x17, 0x18, 0x19, 0x1A, 0x25, 0x26, 0x27, 0x28,
        0x29, 0x2A, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39,
        0x3A, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 0x49,
        0x4A, 0x53, 0x54, 0x55, 0x56, 0x57, 0x58, 0x59,
        0x5A, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68, 0x69,
        0x6A, 0x73, 0x74, 0x75, 0x76, 0x77, 0x78, 0x79,
        0x7A, 0x83, 0x84, 0x85, 0x86, 0x87, 0x88, 0x89,
        0x8A, 0x92, 0x93, 0x94, 0x95, 0x96, 0x97, 0x98,
        0x99, 0x9A, 0xA2, 0xA3, 0xA4, 0xA5, 0xA6, 0xA7,
        0xA8, 0xA9, 0xAA, 0xB2, 0xB3, 0xB4, 0xB5, 0xB6,
        0xB7, 0xB8, 0xB9, 0xBA, 0xC2, 0xC3, 0xC4, 0xC5,
        0xC6, 0xC7, 0xC8, 0xC9, 0xCA, 0xD2, 0xD3, 0xD4,
        0xD5, 0xD6, 0xD7, 0xD8, 0xD9, 0xDA, 0xE1, 0xE2,
        0xE3, 0xE4, 0xE5, 0xE6, 0xE7, 0xE8, 0xE9, 0xEA,
        0xF1, 0xF2, 0xF3, 0xF4, 0xF5, 0xF6, 0xF7, 0xF8,
        0xF9, 0xFA
    };

    jpc->arr = arr;
    jpc->Larr = 162;
    return;
}

При вызове этой функции копируется ли массив чисел в стек?
А если да, то как его правильно определить, чтоб не копировался,
а лежал бы где-нибудь в другом месте неподвижно? Если функция вызывается
многократно, а массив большой, то существенно.
Опять же указатель. У меня такая конструкция работает.
Не может же указатель «jpc->arr = arr;» показывать на стек?

oleg_2 ()
Ответ на: комментарий от oleg_2

массив не копируется, указатель ведёт на массив и равен (вот сюрприз-то!) arr

unC0Rr ★★★★★ ()
Ответ на: комментарий от oleg_2

>Не может же указатель «jpc->arr = arr;» показывать на стек?
почему это.

Bad_ptr ★★★ ()
Ответ на: комментарий от Bad_ptr

У меня такая конструкция работает.
И если бы массив находился в стеке, и туда же
показывал бы указатель, то весьма вероятно,
что массив был бы затерт другими функциями.
Однако работает. Это имел ввиду.

Спросил для развеяния сомнений.

oleg_2 ()

Более тру вэй код если надо точно такое поведение:

/* return u''.join(lst) */
static PyObject *
join_list_unicode(PyObject *lst)
{
    PyObject *sep = NULL;
    PyObject *ret = NULL;

    if (!(sep=pyUnicode_FromUnicode(NULL, 0)))
        goto end;

    ret = PyUnicode_Join(sep, lst);

end:
    Py_XDECREF(sep);

    return ret;
}
mmarkk ()
Ответ на: комментарий от mmarkk
/* return u''.join(lst) */
static PyObject *
join_list_unicode(PyObject *lst)
{
    PyObject *sep = NULL;
    PyObject *ret = NULL;

    if ((sep=pyUnicode_FromUnicode(NULL, 0))) {
        ret = PyUnicode_Join(sep, lst);
    }

    Py_XDECREF(sep);
    return ret;
}

Ну и зачем здесь goto?

anonymous ()
Ответ на: комментарий от anonymous

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

а такой вариант позволяет не делать вложенность кода больше одного, позволяет не забывать Py_DECREF.

а то что ты написал компилятор сделает сам.

четайте код едра линупс. что тут скажешь....

mmarkk ()
Ответ на: комментарий от mmarkk

> Представь, что по ходу функции нужно создать еще десяток питонных промежуточных объектов.
Тогда ладно, из твоего примера не очень понятно было.

четайте код едра линупс. что тут скажешь....

Нет уж, я слишком ленивый для того, чтобы писать на Си.

anonymous ()
Ответ на: комментарий от anonymous

Нет уж, я слишком ленивый для того, чтобы писать на Си.

тогда убей себя. не омрачай лор своим присутствием. или хотябы залогинься чтобы все знали кто ты есть.

mmarkk ()
Ответ на: комментарий от mmarkk

> тогда убей себя. не омрачай лор своим присутствием. или хотябы залогинься чтобы все знали кто ты есть.

Какая экспрессия! Но с чего ты решил, что лор оккупирован насильниками, и что всем остальным здесь не место?

anonymous ()
Ответ на: комментарий от anonymous

с чего ты решил, что лор оккупирован насильниками, и что всем остальным здесь не место?

да ты совсем не знаешь лор.

mmarkk ()
Ответ на: комментарий от mmarkk

> да ты совсем не знаешь лор.
Нет ты.

слишком толсто, я даже повёлся

/0
И это не было троллингом.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.