О "специалистах" - Компьютерные священные войны

Здравствуйте, Kemm, Вы писали:

K>>>Ой, не надо про питон... 8)) Язык редкой "читаемости".
П>>А ты его точно ни с чем не путаешь? По моему мнению питон как раз наоборот — один из самых читабельных языков.

K>За одно только определение блока уровнем индентации убивать надо.

Это как-то влияет на читабельность? ИМХО только в лучшую сторону.

Здравствуйте, Пацак, Вы писали:

K>>>>Ой, не надо про питон... 8)) Язык редкой "читаемости".
П>>>А ты его точно ни с чем не путаешь? По моему мнению питон как раз наоборот — один из самых читабельных языков.
K>>За одно только определение блока уровнем индентации убивать надо.
П>Это как-то влияет на читабельность? ИМХО только в лучшую сторону.

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

Здравствуйте, Kemm, Вы писали:

K>Влияет. В худшую. Например, определить, в конце какого именно блока я сейчас нахожусь -- тихий ужас.

Не понял. В чем проблема-то? Глазами вверх шасть — вот оно и начало блока. Как раз очень удобно ИМХО, в отличие от "}" с кривыми отступами в C/C++/Java или END в Pascal/Delphi/Oberon

Здравствуйте, Пацак, Вы писали:

K>>Влияет. В худшую. Например, определить, в конце какого именно блока я сейчас нахожусь -- тихий ужас.
П>Не понял. В чем проблема-то? Глазами вверх шасть — вот оно и начало блока.

Это смотря насколько далеко надо глазами шастать. 8)) А прыжки по скобкам никто не отменял.

П>Как раз очень удобно ИМХО, в отличие от "}" с кривыми отступами в C/C++/Java или END в Pascal/Delphi/Oberon

Нет, ну тогда к недостаткам сишника можно приписать и "Obfuscated C". 8)) Что, за "синтаксический оверхед"(с) поговорим? 8)))

Здравствуйте, Kemm, Вы писали:

П>>Не понял. В чем проблема-то? Глазами вверх шасть — вот оно и начало блока.
K>Это смотря насколько далеко надо глазами шастать. 8)) А прыжки по скобкам никто не отменял.

Ух, какой ты! Прыжки по скобкам — фича редактора. С тем же успехом у меня vim фолдинг по отступам сделает и я в начало фолда прыгну.

А вообще ИМХО что в си, что в питоне сверхдлинные блоки обычно считаются плохой практикой и встречаются не особенно часто.

П>>Как раз очень удобно ИМХО, в отличие от "}" с кривыми отступами в C/C++/Java или END в Pascal/Delphi/Oberon

K>Нет, ну тогда к недостаткам сишника можно приписать и "Obfuscated C".

Это не недостаток сишника, это просто фича питона. Он принуждает делать отступы правильно, и [само по себе] это хорошо. С другой стороны в C/Java это решается сторонними тулзами типа indent'а или средствами IDE, что в общем-то тоже неплохо.

K>8)) Что, за "синтаксический оверхед"(с) поговорим? 8)))

Давай, в линуксовом топике-то! А походу помянем дурным словом ФЯ и .NET — для пущей веселухи!

Все дело привычки. Я вон еле отвык от PHP'го $ перед именами переменных. А ведь поработал в ем пока полгода всего...

[RSDN@Home][1.2.0][alpha][619]
[Абсолютная честность в изложении помогает максимальной ясности. [П. Чалмош]]

Здравствуйте, Пацак, Вы писали:

П>>>Не понял. В чем проблема-то? Глазами вверх шасть — вот оно и начало блока.
K>>Это смотря насколько далеко надо глазами шастать. 8)) А прыжки по скобкам никто не отменял.
П>Ух, какой ты! Прыжки по скобкам — фича редактора. С тем же успехом у меня vim фолдинг по отступам сделает и я в начало фолда прыгну.

Кстати, а разбить длинную строку в питоне можно? Т.е. вот как-нибудь примерно так:

    some_function(argument1, argument2, argument3,
                  argument4, argument5, argument6);

П>А вообще ИМХО что в си, что в питоне сверхдлинные блоки обычно считаются плохой практикой и встречаются не особенно часто.

Бывает, что без них никуда... 8((

П>>>Как раз очень удобно ИМХО, в отличие от "}" с кривыми отступами в C/C++/Java или END в Pascal/Delphi/Oberon

K>>Нет, ну тогда к недостаткам сишника можно приписать и "Obfuscated C".
П>Это не недостаток сишника, это просто фича питона. Он принуждает делать отступы правильно, и [само по себе] это хорошо. С другой стороны в C/Java это решается сторонними тулзами типа indent'а или средствами IDE, что в общем-то тоже неплохо.

Правильно -- это то, что таб = пробелу, и не дай бог у меня 8 пробелов подряд с начала строки на таб заменяются (как оно у меня и есть)? 8)) Нафиг-нафиг такое принуждение. 8))

K>>8)) Что, за "синтаксический оверхед"(с) поговорим? 8)))
П>Давай, в линуксовом топике-то! А походу помянем дурным словом ФЯ и .NET — для пущей веселухи!

А пофиг. Все равно в этом форуме конструктив не предполагается по определению.

Здравствуйте, Sheridan, Вы писали:

S>Все дело привычки. Я вон еле отвык от PHP'го $ перед именами переменных. А ведь поработал в ем пока полгода всего...

Ну оно так же и перле, и в шелле.

Здравствуйте, Kemm, Вы писали:

K>Кстати, а разбить длинную строку в питоне можно? Т.е. вот как-нибудь примерно так:
K>

K>    some_function(argument1, argument2, argument3,
K>                  argument4, argument5, argument6);
K>

Можно. Общий случай — слэш в конце:

    some_function(argument1, argument2, argument3, \
                  argument4, argument5, argument6);

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

K>Правильно -- это то, что таб = пробелу, и не дай бог у меня 8 пробелов подряд с начала строки на таб заменяются (как оно у меня и есть)? 8)) Нафиг-нафиг такое принуждение. 8))

Это-да, самому не нравится. Но автор языка об это честно предупреждает, да и к читабельности это вроде не особо относится.

Здравствуйте, Пацак, Вы писали:

П>Можно. Общий случай — слэш в конце:
П>

П>    some_function(argument1, argument2, argument3, \
П>                  argument4, argument5, argument6);
П>

П>Но если есть открывающая и закрывающая скобки (как в этом случае), то можно и без слэшей с какой-то версии, просто переносить.

Ну хоть что-то. Впрочем, то, что с бэкслешем работает, очевидно. Неудобно только несколько.

K>>Правильно -- это то, что таб = пробелу, и не дай бог у меня 8 пробелов подряд с начала строки на таб заменяются (как оно у меня и есть)? 8)) Нафиг-нафиг такое принуждение. 8))
П>Это-да, самому не нравится. Но автор языка об это честно предупреждает, да и к читабельности это вроде не особо относится.

Зато очень увлекательно искать баги, если expandtab забыл включить.

Лучше было выбрать какой-нибудь видимый символ для индентации.

Здравствуйте, Kemm, Вы писали:

K>Зато очень увлекательно искать баги, если expandtab забыл включить.

(+)

K>Лучше было выбрать какой-нибудь видимый символ для индентации.

Еще лучше — сделали бы принудительную индентацию табами (т.е. символом tab), благо настроить ее отображаемую ширину позволяет любой нормальный редактор.

Здравствуйте, Kemm, Вы писали:

S>>Все дело привычки. Я вон еле отвык от PHP'го $ перед именами переменных. А ведь поработал в ем пока полгода всего...

K>Ну оно так же и перле, и в шелле.

В пхп я это просто раньше увидел.
Ассоциации знаетели

[RSDN@Home][1.2.0][alpha][619]
[Каков же итог жизни? Ужасно мало смысла. [В.В. Розанов]]

Здравствуйте, BratGanjubas, Вы писали:

Для удаления со стороны нужен FILE_SHARE_DELETE...

Здравствуйте, SergeCpp, Вы писали:

SC>Для удаления со стороны нужен FILE_SHARE_DELETE...

О! А в таком случае что write() вернет?

Здравствуйте, Kemm, Вы писали:

K>Здравствуйте, SergeCpp, Вы писали:

SC>>Для удаления со стороны нужен FILE_SHARE_DELETE...

K>О! А в таком случае что write() вернет?

Я пишу на уровне WriteFile() API

Вроде, он НЕ удалится при SHARE_WRITE без SHARE_DELETE

Я это ТОЧНО писал, но не помню деталей

    g_NT         = GetVersion() < 0x80000000;

    g_ShareAll  |= g_NT ? FILE_SHARE_DELETE : 0;
    g_ShareRead |= g_NT ? FILE_SHARE_DELETE : 0;


............

    g_hDst = CreateFile(
        g_pDstFile,
        GENERIC_READ, // Dst can be Read-Only
        g_ShareRead,  // probably be deleted in SyncStart()
        NULL,
        OPEN_EXISTING,
        FILE_FLAG_BACKUP_SEMANTICS,
        NULL );

не помню деталей, но БЕЗ SHARE_DELETE у меня файл НЕ удалялся

Это точно (я поэтому флаг и добавил для NT-based)

Здравствуйте, SergeCpp, Вы писали:

SC>>>Для удаления со стороны нужен FILE_SHARE_DELETE...
K>>О! А в таком случае что write() вернет?
SC>Я пишу на уровне WriteFile() API

Ну WriteFile()...

SC>Вроде, он НЕ удалится при SHARE_WRITE без SHARE_DELETE

Файл открыт с SHARE_DELETE, предположим.

Здравствуйте, Kemm, Вы писали:

SC>>>>Для удаления со стороны нужен FILE_SHARE_DELETE...
K>>>О! А в таком случае что write() вернет?
SC>>Я пишу на уровне WriteFile() API

K>Ну WriteFile()...

SC>>Вроде, он НЕ удалится при SHARE_WRITE без SHARE_DELETE

K>Файл открыт с SHARE_DELETE, предположим.

Честно говоря, FILE_SHARE_DELETE я не пробовал использовать.
В MSDN о нем написано следующее:

[msdn]Enables subsequent open operations on an object to request delete access.
Otherwise, other processes cannot open the object if they request delete access.

If this flag is not specified, but the object has been opened for delete access, the function fails.[/msdn]

Предполагаю, что ошибки в таком случае не будет с обеих сторон (как со стороны пишушего приложения, так и со стороны удаляющего). Что естественно, ибо разрешен delete access.

Я правда не могу предположить, в каких ситуациях этот флаг имеет смысл использовать...Хотя... Можно например для лог-файлов. Чтобы их могло удалить другое приложение, если это необходимо, без закрытия файла пишущим лог приложением. Кстати да, хорошая идея, надо будет так сделать.

Здравствуйте, BratGanjubas, Вы писали:

K>>Файл открыт с SHARE_DELETE, предположим.

BG>Честно говоря, FILE_SHARE_DELETE я не пробовал использовать.
BG>В MSDN о нем написано следующее:

BG>[msdn]Enables subsequent open operations on an object to request delete access.
BG>Otherwise, other processes cannot open the object if they request delete access.

BG>If this flag is not specified, but the object has been opened for delete access, the function fails.[/msdn]

BG>Предполагаю, что ошибки в таком случае не будет с обеих сторон (как со стороны пишушего приложения, так и со стороны удаляющего). Что естественно, ибо разрешен delete access.

А с файлом что будет?

BG>Я правда не могу предположить, в каких ситуациях этот флаг имеет смысл использовать...Хотя... Можно например для лог-файлов. Чтобы их могло удалить другое приложение, если это необходимо, без закрытия файла пишущим лог приложением. Кстати да, хорошая идея, надо будет так сделать.

В юниксах стандартный способ открытия внутренних временных файлов. Грубо говоря:
open() — создали файл
unlink() — удалили 8)). Файла в директории уже нет, но реально он присутствует, т.к. ссылка на него еще есть (в ядре)
write()/read()
close() — файл действительно удаляется, так как удаляется последняя ссылка на него

Соответственно, в случае падения софта/оси не оставляем после себя груд мусора.

Здравствуйте, Kemm, Вы писали:

Всё будет нормально с Write — система просто отложит удаление до момента, когда когда последний HANDLE для файла будет закрыт.

... << RSDN@Home 1.2.0 alpha rev. 605>>

Kemm wrote:

> В юниксах стандартный способ открытия внутренних временных файлов.
> Грубо говоря:
> open() — создали файл
> unlink() — удалили 8)). Файла в директории уже нет, но реально он
> присутствует, т.к. ссылка на него еще есть (в ядре)
> write()/read()
> close() — файл действительно удаляется, так как удаляется последняя
> ссылка на него
> Соответственно, в случае падения софта/оси не оставляем после себя
> груд мусора.

Ламеры

, Винда еще и оптимизировать под временные файлы умеет.

FILE_ATTRIBUTE_TEMPORARY

The file is being used for temporary storage. File systems avoid writing
data back to mass storage if sufficient cache memory is available,
because often the application deletes the temporary file shortly after
the handle is closed. In that case, the system can entirely avoid
writing the data. Otherwise, the data will be written after the handle
is closed.

FILE_FLAG_DELETE_ON_CLOSE

The system is to delete the file immediately after all of its handles
have been closed, not just the specified handle but also any other open
or duplicated handles.

If there are existing open handles to the file, the call fails unless
they were all opened with the FILE_SHARE_DELETE share mode.

Subsequent open requests for the file will fail, unless they specify the
FILE_SHARE_DELETE share mode.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

	От:	Пацак
	Дата:	15.11.05 06:35
	Оценка:

	От:	Kemm
	Дата:	15.11.05 07:03
	Оценка:

	От:	Пацак
	Дата:	15.11.05 07:12
	Оценка:

	От:	Kemm
	Дата:	15.11.05 07:21
	Оценка:

	От:	Пацак
	Дата:	15.11.05 08:16
	Оценка:

От:	SergeCpp	http://zoozahita.ru
Дата:	16.11.05 10:47
Оценка: