Коллега, а по рукам? ... ... Пример косячный. Передача по значению это крайне поганый стиль. Рекомендую ознакомиться с тем, как передаются параметры ф-ий, при вызове. И тем, что у Вас будет происходить со стеком.

коллега, а вам по голове?

Знакомимся:

00000000004004b0 <main>:
  4004b0:   48 83 ec 68             sub    rsp,0x68
  4004b4:   48 b8 00 00 00 00 01    movabs rax,0x100000000
  4004bb:   00 00 00 
  4004be:   48 ba 04 00 00 00 05    movabs rdx,0x500000004
  4004c5:   00 00 00 
  4004c8:   66 0f 6f 05 00 04 00    movdqa xmm0,XMMWORD PTR [rip+0x400]        # 4008d0 <_IO_stdin_used+0x10>
  4004cf:   00 
  4004d0:   31 f6                   xor    esi,esi
  4004d2:   48 89 44 24 30          mov    QWORD PTR [rsp+0x30],rax
  4004d7:   c7 44 24 20 08 00 00    mov    DWORD PTR [rsp+0x20],0x8
  4004de:   00 
  4004df:   bf c4 08 40 00          mov    edi,0x4008c4
  4004e4:   66 0f 7f 04 24          movdqa XMMWORD PTR [rsp],xmm0
  4004e9:   48 8b 44 24 08          mov    rax,QWORD PTR [rsp+0x8]
  4004ee:   c7 44 24 24 09 00 00    mov    DWORD PTR [rsp+0x24],0x9
  4004f5:   00 
  4004f6:   66 0f 6f 05 e2 03 00    movdqa xmm0,XMMWORD PTR [rip+0x3e2]        # 4008e0 <_IO_stdin_used+0x20>
  4004fd:   00 
  4004fe:   48 89 44 24 38          mov    QWORD PTR [rsp+0x38],rax
  400503:   48 89 54 24 40          mov    QWORD PTR [rsp+0x40],rdx
  400508:   66 0f 7f 44 24 10       movdqa XMMWORD PTR [rsp+0x10],xmm0
  40050e:   48 8b 44 24 18          mov    rax,QWORD PTR [rsp+0x18]
  400513:   48 89 44 24 48          mov    QWORD PTR [rsp+0x48],rax
  400518:   48 8b 44 24 20          mov    rax,QWORD PTR [rsp+0x20]
  40051d:   48 89 44 24 50          mov    QWORD PTR [rsp+0x50],rax
  400522:   31 c0                   xor    eax,eax
  400524:   e8 67 ff ff ff          call   400490 <printf@plt>
  400529:   8b 74 24 34             mov    esi,DWORD PTR [rsp+0x34]
  40052d:   bf c4 08 40 00          mov    edi,0x4008c4
  400532:   31 c0                   xor    eax,eax
  400534:   e8 57 ff ff ff          call   400490 <printf@plt>
  400539:   8b 74 24 38             mov    esi,DWORD PTR [rsp+0x38]
  40053d:   bf c4 08 40 00          mov    edi,0x4008c4
  400542:   31 c0                   xor    eax,eax
  400544:   e8 47 ff ff ff          call   400490 <printf@plt>
  400549:   8b 74 24 3c             mov    esi,DWORD PTR [rsp+0x3c]
  40054d:   bf c4 08 40 00          mov    edi,0x4008c4
  400552:   31 c0                   xor    eax,eax
  400554:   e8 37 ff ff ff          call   400490 <printf@plt>
  400559:   8b 74 24 40             mov    esi,DWORD PTR [rsp+0x40]
  40055d:   bf c4 08 40 00          mov    edi,0x4008c4
  400562:   31 c0                   xor    eax,eax
  400564:   e8 27 ff ff ff          call   400490 <printf@plt>
  400569:   8b 74 24 44             mov    esi,DWORD PTR [rsp+0x44]
  40056d:   bf c4 08 40 00          mov    edi,0x4008c4
  400572:   31 c0                   xor    eax,eax
  400574:   e8 17 ff ff ff          call   400490 <printf@plt>
  400579:   8b 74 24 48             mov    esi,DWORD PTR [rsp+0x48]
  40057d:   bf c4 08 40 00          mov    edi,0x4008c4
  400582:   31 c0                   xor    eax,eax
  400584:   e8 07 ff ff ff          call   400490 <printf@plt>
  400589:   8b 74 24 4c             mov    esi,DWORD PTR [rsp+0x4c]
  40058d:   bf c4 08 40 00          mov    edi,0x4008c4
  400592:   31 c0                   xor    eax,eax
  400594:   e8 f7 fe ff ff          call   400490 <printf@plt>
  400599:   8b 74 24 50             mov    esi,DWORD PTR [rsp+0x50]
  40059d:   bf c4 08 40 00          mov    edi,0x4008c4
  4005a2:   31 c0                   xor    eax,eax
  4005a4:   e8 e7 fe ff ff          call   400490 <printf@plt>
  4005a9:   8b 74 24 54             mov    esi,DWORD PTR [rsp+0x54]
  4005ad:   bf c4 08 40 00          mov    edi,0x4008c4
  4005b2:   31 c0                   xor    eax,eax
  4005b4:   e8 d7 fe ff ff          call   400490 <printf@plt>
  4005b9:   31 c0                   xor    eax,eax
  4005bb:   48 83 c4 68             add    rsp,0x68
  4005bf:   c3                      ret

неплохим наобором полезных библиотек

При совершенно убогой стандартной иначе и быть не может. Да, я сам поразился CPAN-у в своё время.

А зачем раздувать стандартную библиотеку до размеров вселенной, если тебе из нее больше 25% никогда не понадобится? Чтоб было? А у других нет?

PS. Не являюсь фанатом ни питона, ни какого-либо другого ЯП, просто считаю, что нужно подбирать инструмент под задачу, а не пытаться строить вебсервисы на языке обработки текста.

А чем по вашему занимается Web-сервер?

а ещё у меня есть команда reset.

Спасибо! — Забыл про неё. Точнее, помнил, что есть такая, но название забыл.

^L

то есть как это не было... а awk? да и tcl примерно тогда же появился.

Два тома вам под руки.

А. Ну, тогда да...

... почти согласен. В частности с тем, что массивов в понимании других языков в С нет.

В С это просто некая область памяти и всё. Этот кусок может резервироваться статически (и будет в секции .data, куда его запихнёт компилятор). Здесь да, компилятор знает размер массива. Например, это будет как-то так — char some_array[some_size];

Или динамически (и будет в секции .bss), но при этом его размер будет определяться на этапе исполнения (зачудительное место, где можно поискать простор для срыва кучи, т.к. именно в куче он и резервируется). Это (_не_ срыв кучи, конечно! :D) было стандартизировано в С99 под названием VLA (Variable-Length Array см. ISO 9899:2011 Programming Languages - C 6.7.6.2 4). А это будет вот так — char *some_array = (char *)malloc(some_size * sizeof(char) + 1); some_size здесь может вычисляться на этапе исполнения где-то там в коде, на этапе компиляции о его конкретном значении ни чего не известно. Проверять возвращаемое malloc значение — _ОБЯЗАТЕЛЬНО_. Ну и инициализировать (после выделения памяти) то же нужно корректно. Чтение из неинициализированной памяти это одна из нубских ошибок. Как вариант можно использовать memset для инициализации или вообще делать так — char *some_array = (char *)calloc(some_size + 1, sizeof(char)); /* Тут и резервирование и сразу инициализация в 0. */

Есть ещё gcc extension, позволяющее создавать массивы нулевой длины — http://gcc.gnu.org/onlinedocs/gcc-3.0.2/gcc_5.html#SEC80, но они в данном случае к делу не относятся.

Кроме того, для локального (в пределах ф-ии) контекста и _НЕБОЛЬШОМ_ выделяемом объёме памяти, я бы рекомендовал использование alloca. Дело в том, что память выделяется в данном случае — char *some_array = (char *)alloca(some_size * sizeof(char) + 1); в стеке, а не в куче. Но тут надо приглядывать за тем, чтобы не сорвать самому себе стек, но зато можно не освобождать память через free(some_array); some_array = NULL; после возврата из ф-ии, память сама зачистится.

Как-то так, в общем.

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

На питоне программа выглядит как будто программист бился голой о клавиатуру и при этом выставлял отступы. На этом отличия заканчиваются. Python-быдло-программисты пишут быдло код с отступами! Какой замечательный язык! Он безусловно очистит ряды программистов от быдлокодеров.

это можно сделать на любом тьюринг-полном ЯП

будучи программистом..

ну да, а вот перловодами рождаются. Поверь, освоить пайтон в разы легче перловки, и 100500 пионеров это только подтверждают. Впрочем, если для тебя очевидна эквивалентность хвостовой рекурсии и итерации, то тебе не нужно упарываться, что-бы юзать хоть перл, хоть BF. Однако и в этом случае, даже CL и то логичнее и прогрессивнее перловки.

то есть как это не было... а awk? да и tcl примерно тогда же появился.

ты ещё про sed вспомни...

Ура!!! Поздравляю всех последователей уважаемого Ларри Уолла с юбилеем языка! Отдадим ему должное: Perl сильно повлиял на PHP, Python, Ruby, ... Ознакомиться с Перлом весьма полезно для развития программиста.

(Мой давно любимый язык: я не только писал на Perl, но даже преподавал Perl в ВУЗе и написал учебник по нему. 8-)

Этот кусок может резервироваться статически (и будет в секции .data, куда его запихнёт компилятор). Здесь да, компилятор знает размер массива.

знает. Только у него перманентная амнезия: хотя есть форма int f(array[]), которая в принципе должна отдавать массив в функцию, она НЕ работает. Указатель передаётся, а размер - забыли...

VLA (Variable-Length Array см. ISO 9899:2011 Programming Languages - C 6.7.6.2 4).

не нужно.

Чтение из неинициализированной памяти это одна из нубских ошибок.

это кривые руки K&R. Ну их можно понять - это давно было, в 21ом веке просто быть таким умным...

alloca

после возврата из ф-ии, память сама зачистится.

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

в упор не наблюдаю тут никаких вызовов подпрограмм, кроме printf(). Может у вас паскаль головного i8086?

В вашем случае функция print_a10 «проинланена». Выключите inline (и unroll loop тоже) и повторите эксперимент.

всегда Ваш, K.O.

На питоне программа выглядит как будто программист бился голой о клавиатуру и при этом выставлял отступы. На этом отличия заканчиваются. Python-быдло-программисты пишут быдло код с отступами! Какой замечательный язык! Он безусловно очистит ряды программистов от быдлокодеров.

ты не прав. Для получения пруфа, попробуй биться о клаву головой, и одновременно _аккуратно_ расставлять отступы. Уверен, что на хэлловорлд тебе понадобится не менее суток. Вот оттого-то такой лютый баттхет у быдлокодеров. У быдлокодера только два варианта, что-бы написать программу на пайтоне:

1. лососнуть тунцов.

2. не быть быдлокодером.

третьего не дано. А вот на сабже - вполне себе быдлокодят...

вот вы тут спорите, python, ruby etc

а можно посмотреть на рынок труда. а его состояние таково, что наиболее крупные игроки на нем (яндекс, мейл, рамблер, куча всяких seo'шников итп) выбрали с этого рынка всех Perl'овиков. в связи с этим зарплаты программеров на Perl очень хорошие.

вот в Mail.RU устроиться на зарплату 160К Perl программистом (если конечно вы действительно Perl-программист) не представляет никакой сложности, а вот питонщики и прочие жабоводы стоят в районе 100, если повезет - 120.

ну в общем ругайте Perl дальше. удачи :)

Ты сравниваешь с питоном, а фраза «тьюринг-полный ЯП» в первую очередь ассоциируется с собственно машиной Тьюринга, потом ассемблером, потом Си.

Будешь спорить что у Asm и Perl разный порог вхождения и требования к квалификации?

А какие подпрограммы ДОЛЖНЫ быть? ...

... их тут и быть не должно. В Вашем случае. :D Об этом чуть ниже. А вот про cdecl и реализацию вызовов функции, мне писать _сейчас_ (в данный момент) некогда, да и лень, если честно (на сегодня я список добрых дел выполнил :D), по этой причине я бы предложил полистать что-нибудь типа Using GNU Compiler Collection или вот несколько ссылок — dev64.wordpress.com/2012/01/23/gcc-calling-conventions-investigation/ и http://www.opennet.ru/base/dev/stack_intro.txt.html ну и — http://en.wikipedia.org/wiki/X86_calling_conventions

По поводу Вашего асмовского выхлопа могу только сказать — «ай-яй-яй-яй». :D Посмотрите внимательнее. Вас gcc спасает. И то, что это оптимизирующий компилятор, точнее то, что при компиляции, если он может что-то вычислить, то вычисляет и использует по мере возможности как константу. Могу предположить, что у Вас выставлен параметр -О2, который и заставляет gcc делать всю эту грязную работу. Вы бы выключили -O2 и показали код с -g? Было бы честнее... :D

Ну дык! ...

... по поводу амнезии, не знаю. Я для «верочки-контрольки» не гнушаюсь интересоваться через sizeof(something). А то, иной раз... Короче, проверяться лучше.

VLA весьма удобны. Просто надо понимать когда их использовать, а когда воздержаться. Если например, размерность входных данных колеблется (от пары мегабайт до пары гигабайт, например), то лучше бы через них работать. Если данные фиксированной длины, то сойдёт и фиксированный размер.

Про K&R. Ну да... Всё бы на ошибки проектировщика списать (поговорку про дурака со стеклянным хером напомнить?). :D Нет. Если нубу не под силу С, то лучше бы ему заняться чем-то типа похапе. С позволяет работать «от положения» (в том числе и убивать систему), а не делать всё, что угодно одним самым лучшим способом, т.к. для такого подхода есть питон. Но остаётся вопрос — а для какого случая _этот_ способ самый лучший? Для моего? Не факт, совсем не факт. Иначе не было бы чего-то типа — http://docs.python.org/2/extending/extending.html Т.е., питон хорош, но когда нужна скорость, всё-таки используйте С. А зачем? Я и так на С пишу. Мне питон не нужен.

alloca нужен просто потому, что в ряде случаев он несколько быстрее (но менее безопасен и имеет ряд ограничений). Про advantages — http://www.gnu.org/software/libc/manual/html_mono/libc.html#Advantages-of-Alloca, про disadvantages там же, чуть ниже.

У быдлокодера только два варианта, что-бы написать программу на пайтоне:

ну-ну... когда закончишь распутывать это хитрое переплетение - скажи. Заметь все отступы расставлены правильно!

	def getHtml(self, data):

		tableAttributes = None
		headers = None
		tableData = None

		if data:
			xml = etree.fromstring(self.__widgetObject.xml_settings)

			tableAttributes = xml.xpath('/xml/table')[0].attrib

			fieldsSettings = {}
			for xmlField in xml.xpath('/xml/fields/field'):
				attrib = dict(xmlField.attrib.items())
				fieldName = attrib['name'].upper()
				if attrib.has_key('lnk'):
					attrib['lnkTemplateToRender'] = Template(force_unicode(attrib['lnk']))
				fieldsSettings[fieldName] = attrib

			headers = []
			allFieldNames = []
			for index, (fieldName, fieldValueFirstRow) in enumerate(data[0]):
				fieldName = fieldName.upper()
				allFieldNames.append(fieldName)
				fieldSettings = fieldsSettings.get(fieldName, {})
				if not fieldSettings.has_key('display') or fieldSettings['display'] != '0':
					headers.append((index, fieldName, fieldSettings))

			tableData = []
			for row in data:
				rowSettingsToRender = {}
				fieldsToRender = []
				rowDict =  dict(row)

				if tableAttributes.has_key('field_row_style'):
					rowSettingsToRender['row_style'] = rowDict[tableAttributes['field_row_style']]
				
				for fieldIndex, fieldName, settings in headers:
					if settings.has_key('display') and fieldSettings['display'] == '0':
						continue;

					field = {'value':row[fieldIndex][1]}
					
					if settings.has_key('lnkTemplateToRender'):
						c = Context(rowDict)
						c['POST'] = self.__request.POST
						field['lnk'] = settings['lnkTemplateToRender'].render(c)

					field['settings'] = settings
					fieldsToRender.append(field)
				tableData.append((rowSettingsToRender, fieldsToRender))

		return render_to_string('reports_widget_table.html', {'tableAttributes':tableAttributes, 'headers':headers,
                                                              'html_header':self.__widgetObject.table_header ,'tableData':tableData})

А вот в американских банках пишут на java и зарплаты там куда больше, чем у убогих перловиков. Да и нет там их практически, весь веб пишется на той же яве или на технологиях Микрософт. Это у нас ИТ индустрия соотвествует западной середины 90 годов.

Для рантайма 6 мег (это python-static 2.7, если что) функционал стандартной библиотеки более чем обширен. Неплохой такой бастион защиты от велосипедостроения.

А чем по вашему занимается Web-сервер?

Прежде всего сетевым взаимодействием. Ну и сколько строк будет занимать хотя бы статический web-сервер на Perl? На Python - одну:

python -m SimpleHTTPServer 8000

Неплохой такой бастион защиты от велосипедостроения.

Скорее наоборот.

На Python - одну

Так вот где разработчики systemd черпают свои идеи!

В вашем случае функция print_a10 «проинланена».

да. Я знаю. Это для меня не новость, я об этом знал ещё при написании данного кода. Странно, что вы заметили какую-то «передачу по значению», которого в этом коде нет.

Выключите inline (и unroll loop тоже) и повторите эксперимент.

это не эксперимент, а пример.

Фу как много символов отстой, на си и то короче, уж про быстроту и говорить небуду.

nginx -c f

Ну конечно же, каждый пЁрл-хэккер считает себя умнее разработчиков питона и systemd вместе взятых, а потому думает, что стандартная библиотека полна велосипедов и «уж я-то напишу оптимальнее!»

Упырьте мел.

Когда nginx включат в stdlib (вообще, давно пора :D), тогда это будет считаться.

не работает, ваш сервер )) zsh: command not found: python

Ты сравниваешь с питоном, а фраза «тьюринг-полный ЯП» в первую очередь ассоциируется с собственно машиной Тьюринга, потом ассемблером, потом Си.

ну это у тебя такие ассоциации и такие приоритеты. Для меня и LISP и перловка являются одинаково «тьюринг-полными». Разница в том, что код на лиспе - простой и прозрачный, а код на перле - вырвиглазный и мозговзрывающий. Пайтон ИМХО куда как ближе к лиспу.

Ну а си и тем более асм - это вообще из другой серии, т.к. больше базируются на реальной, а не придуманной архитектуре. Нечитаемость си и асма происходит от разницы в задачах проектирования CPU и ЯП. Если уж придумывать ЯП, то его надо придумывать так, что-бы его было удобно в первую очередь _читать_. А писать - не проблема. Закорючки тоже. В сишечке вообще нет никаких закорючек, и ничего, работает.

Будешь спорить что у Asm и Perl разный порог вхождения и требования к квалификации?

это всё равно, что спорить, «что тяжелее, солёное или мягкое?».

Так это zsh не работает. bash: zsh: command not found...

Так это ваш bash не работает

zsh: command not found:bash

Okay. Ждём уп0р0тых с выводом cmd.exe.

Зы. Веб-сервер в одну строку на баше

Ну конечно же, каждый пЁрл-хэккер считает себя умнее разработчиков питона и systemd вместе взятых, а потому думает, что стандартная библиотека полна велосипедов и «уж я-то напишу оптимальнее!»

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

... их тут и быть не должно. В Вашем случае.

на 64х битной железке не должно. На 32х битной компилятор решил - пусть будет, ибо умеет перебрасывать 40 байтов одной командой (REPNZ MOVSD. Для SSE2 такой команды нет очевидно).

А вот про cdecl и реализацию вызовов функции, мне писать _сейчас_ (в данный момент) некогда, да и лень, если честно

Не утруждайтесь. Я вполне знаком с этой темой. Будет время, распишите для нубов, может моя помощь даже будет полезна.

По поводу Вашего асмовского выхлопа могу только сказать — «ай-яй-яй-яй». :D Посмотрите внимательнее. Вас gcc спасает.

не спасает он меня, у меня просто много лет опыта работы именно с gcc, что позволяет мне писать код так, что этот gcc меня «спасает».

И то, что это оптимизирующий компилятор, точнее то, что при компиляции, если он может что-то вычислить, то вычисляет и использует по мере возможности как константу.

это фишка C/C++ - массивы имеют исключительно константную длину, известную при компиляции. В других ЯП этот номер не проходит. Именно потому можно иногда передавать массивы по значению(в других ЯП компилятор будет вынужден порождать код копирования, ибо размер неизвестен). И да, тут ещё и константное значение - функция print_a10() не меняет аргумент. Если-бы меняла, то пришлось-бы тоже создать копию.

Могу предположить, что у Вас выставлен параметр -О2, который и заставляет gcc делать всю эту грязную работу. Вы бы выключили -O2 и показали код с -g? Было бы честнее... :D

почему «честнее»? ИМХО так и _надо_ писать код, что-бы компилятор смог его распарсить, и адекватно положить на данную архитектуру. А вот навязывать _свою_ точку зрения как раз не нужно. Например ваша догма «плохо передавать по значению массивы» не всегда верна. Например на x86-64 она в данном конкретном случае и не верна. И если-бы я навязал-бы свою т.з. компилятору, результат был-бы хуже. Ну уж не лучше - точно.

ЗЫЖ да, там -O3 было (:

Сегодня языку Perl исполнилось 25 лет!

Прочитал как «Сегодня языку Perl исполнилось _БЫ_ 25 лет!», подумал, что некролог. Привет.

drBatty... :) Вы другого ананимуса комментируете...

... мой ответ ниже. :D У Вас там нет инлайнинга. Есть работа gcc, но приводить её не корректно. Просто потому, что в случае, если gcc не сможет оптимизировать код (причина почему именно не сможет не важна — либо отключите -O2 и включите -g, либо он не сможет во время компиляции посчитать значение и подставить его — не важно, повторю), он будет действовать как должен. Нельзя всегда надеяться на оптимизатор.

ну это у тебя такие ассоциации и такие приоритеты.

А у тебя такие комментарии - в духе «asm, perl и lisp одинаково подходят для непрограммистов». Чтобы не увильнул, цитирую твой комментарий:

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

это можно сделать на любом тьюринг-полном ЯП. Хоть на brainfuck'е

Сами вы поротый, увас работает, а унас не работает.
гавно ваш питон.
cmd.exe тоже не работает, хоть ченить работающие можете в пример привести.

Чтоб код на питоне/перле заработал, нужно этот питон/перл поставить, не?

на вот это точно работает

perl -e '$??s:;s:s;;$?::s;;=]=>%-{<-|}<&|`{;;y; -/:-@[-`{-};`-{/" -;;s;;$_;see'

Лол. А 42.zip или f0rk3r.html не хочешь?

Да, это то, что доктор прописал каждому перлоиду раз в сутки запускать.

А! Ну теперь понятно почему фикс. длина... :D

Я понял. :)

Касаемо gcc, так с ним всё очень весело. У него оптимизатор крайне хороший (лучше только у icc, но там много Intel-specific вещей, на AMD не всегда это полезно). И в принципе gcc может распарсить и переложить на нужную платформу много чего. :) Но иной раз, при анализе кода, даёт о себе знать разница архитектур. Кстати да, так и получилось. :)

-O3? Ну, я не сильно ошибся. Я, правда, по привычке -O2 ставлю, т.к. для С эта опция даёт вполне достаточный уровень оптимизации, а -O3 иногда даёт несколько больший по размеру код (хотя и позволяет некоторые вещи лучше обработать). И, по-моему, -O3 это в большей степени для С++ подходит. Впрочем, возможно это дело привычки.

По поводу константной длины не всегда это возможно к сожалению, хотя и было бы лучше. Иногда приходится в цикле читать куски данных для анализа, они могут иметь фиксированную структуру, но не иметь фиксированной длины. В этом случае крайне заманчивый вариант с массивами фикс. длины лучше не использовать — не экономично может получиться. Лучше резервировать память по реалиям. Хотя, наверное, можно было бы отхватить кусок памяти «на вырост» и с ним постоянно работать, регулярно его перезаписывая, но этот подход тоже не всегда возможен к сожалению. Иногда бывают такие куски данных, что система за малым делом в своп не уходит. Зарезервировать такой кусок памяти «навсегда» можно, но есть риск увалить систему.

Ну дык! ... .. по поводу амнезии, не знаю. Я для «верочки-контрольки» не гнушаюсь интересоваться через sizeof(something).

а вот зря. Можно и на грабли наступить:

#include <stdio.h>

void f(int a[])
{
·   printf("size(a[11]) %lu\n",
·   ·   ·   sizeof(a)/sizeof(a[0]));
}

int main()
{
·   int a[11] = {0};
·   printf("size(a[11]) %lu\n",
·   ·   ·   sizeof(a)/sizeof(a[0]));
·   f(a);
·   return 0;
}

size(a[11]) 11
size(a[11]) 2

И это притом, что я ЯВНО указал, что аргумент - это массив, а не указатель!

VLA весьма удобны. Просто надо понимать когда их использовать, а когда воздержаться. Если например, размерность входных данных колеблется (от пары мегабайт до пары гигабайт, например), то лучше бы через них работать.

а что, malloc(2) сломался?

Про K&R. Ну да... Всё бы на ошибки проектировщика списать (поговорку про дурака со стеклянным хером напомнить?).

не надо. В данном случае это ИМХО вправду fail K&R. Массивы сделали, а вот их передачу оставили «на потом». Даже форму передачи запилили, только вместо реализации поставили затычку - оно реализовано тем же кодом, что и передача указателя. А потом менять что-то было уже поздно - нашлись идиоты, для которых прозрачный хер жизненно необходим...

Если нубу не под силу С, то лучше бы ему заняться чем-то типа похапе.

NoWay. Если в сишечке совсем немного таких фэйлов, то пхп наполнен ими чуть более, чем полностью. И их периодически исправляют(кроме шуток). И тонны быдлокода вылетают в помойку.

С позволяет работать «от положения» (в том числе и убивать систему), а не делать всё, что угодно одним самым лучшим способом, т.к. для такого подхода есть питон. Но остаётся вопрос — а для какого случая _этот_ способ самый лучший? Для моего?

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

1. курим шишки и мечтаем: чего я хочу? Хочу массивы? Легко! Хочу хеши? ОК! Как список в скаляр преобразуется? Щаз... Пыхну... А! Твак и преобразуется, один косяк пыхнул, второй косяк пыхнул... Какой я косяк только-что пыхнул? БЛЖАД! Последний! Очевидно же? Так сколько я косяков пыхнул? Дура чёли? 28! Но это уже если рассматривать косяки как массив!

2. Курим ещё шышек, и придумываем закорючки

3. профит.

Т.е., питон хорош, но когда нужна скорость, всё-таки используйте С. А зачем? Я и так на С пишу. Мне питон не нужен.

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

alloca нужен просто потому, что в ряде случаев он несколько быстрее

быстрее чего? Локального массива? Если мне нужен массив на 10 int'ов, то я так и напишу int[10], всё равно его не отдать никому. А если я не знаю, и может мне нужно int[100500], то мне alloca() не помощник.

Про advantages — http://www.gnu.org/software/libc/manual/html_mono/libc.html#Advantages-of-Alloca, про disadvantages там же, чуть ниже.

ну это для embedded разве что интересно, если тебе нужен массив в 20..30 эл-тов, и ты хочешь каждый байт сэкономить (я просто напишу int[32]).

ну-ну... когда закончишь распутывать это хитрое переплетение - скажи.

а можно вариант того же на перле или другом ЯП? Тогда всем станет ясно, какое-же говно пайтон.

Для рантайма 6 мег (это python-static 2.7, если что) функционал стандартной библиотеки более чем обширен. Неплохой такой бастион защиты от велосипедостроения.

PHP доказывает, что огромная стандартная либа на Over9000 функций от велосипедостроения никак НЕ помогает.

Прежде всего сетевым взаимодействием. Ну и сколько строк будет занимать хотя бы статический web-сервер на Perl? На Python - одну:

апач на перле тоже одну, достаточно вызвать httpd.

если gcc не сможет оптимизировать код (причина почему именно не сможет не важна — либо отключите -O2 и включите -g, либо он не сможет во время компиляции посчитать значение и подставить его — не важно, повторю),

повторю - в данном случае (пример массивов в си) причина очень важна. В штатном режиме gcc оптимизирует, и классические массивы в си имеют размер известный при компиляции. Именно потому и такой код.

Нельзя всегда надеяться на оптимизатор.

можно и нужно. Если конечно понимаешь, как он работает, что он может и обязан делать, а чего не может, и/или не обязан. Ну а если ты считаешь себя умнее компилятора - ассемблер ждёт тебя. Только помни, что каждую функцию придётся писать Over9000 раз, для каждого компьютера свою.

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

Вах какая красота. Обожаю ASCII-Art. Спасибо.

Вот только не надо делать вид, что ты не понял разницы между классом SimpleHTTPServer и внешними вызовами. Для поднятия сервака достаточно двух бинарников - линухового ведра и python-static - и одного скрипта на питоне. Безо всяких апачей и болгинксов.