Можно и так: исходить из контекста предложения, где предполагается «большевизм» как явление (которое привёло к изменению языка), а не «большевик» как конкретная личность.
Всё так же падает на страничке www.rightjs.org/fx-demo. Лень разбираться какой именно код тому виной. Но сейчас хотя бы краш-репорт показывает (до этого просто тихо умирала). Баг-репортов мной ужо отправлено было неисчеслимое количество. Мне эта страничка не очень то и нужна, но «осадок остаётся» (в 10.5х тоже самое было).
Особенно приятно, что в тегах PDF стоит Adobe InDesign CS4, а онлайн версия либо на AdobeFlash, либо .jpg скрины страниц (если флеш отключен). Прям засилье FOSS в редакции =)
Подобные эффекты можно получить (в зависимости от ABI, конечно), если передавать больше или меньше параметров, чем требует функция, независимо от возвращаемого значения (а в ранних реализациях C так и было, декларация функции описывала только возвращаемый тип). Думается, что ожидание какого-либо определённого поведения для вызова функции с неизвестным прототипом порочная практика =).
Microsoft ® 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86
v.a = 1, v.b = 2
a = 1, b = 2
Microsoft ® C/C++ Optimizing Compiler Version 16.00.30319.01 for x64
«Программа выполнила недопустимую недопустимость» =)
Неправильно извлекаются параметры со стека.
Если мне не изменяет мой склероз, когда возвращаемый тип не указан компилятор считает что функция возвращает 'int', что явно отличается от реализации функции 'struct S'. И в зависимости от ABI может быть любое поведение, вплоть до порчи стека и невозврата из этой функции (например исключительная ситуация обращения по несуществующему адресу).
А если ещё отличается и механизм вызова (__attribute((__stdcall)) в GCC или __stdcall, __fastcall и т.п. в MSC)? Правда name mangling минимизирует вероятность таких ошибок, но при желании можно получить «результат».
Мораль проста и очевидна — прототипы функций необходимы. =)
А причём тут С++? Это ж WinAPI практически в чистом виде. Правильней было бы озаглавить «Доступ к памяти стороннего процесса в Windows. Реализация на C++».
Носить с собой тюнер и устанавливать программу — это сильно разные вещи. Для домашнего использования он-лайн версия подойдёт.
По опыту всяких концертов могу сказать, что компьютер, да ещё с интернетом, да ещё с нужной версией флеша (хотя это мелочь), да ещё к которому разрешат воткнуться гитарой (а ещё не забыть с собой переходник «джек->мини-джек») вещь практически нереальная. А вот найти тюнер/камертон гораздо проще. Да и вообще, что это за музыкант, без тюнера/камертона на выступлении?!
Этак проще записать на мобильник эталонные сигналы нужной частоты — карманный камертон за минимальные усилия.
Вот было бы чудесно приложение для мобильника, которое может имитировать камертон. А ещё чудесней — тюнер. Чтобы измеряло сигнал с микрофона (не знаю, есть ли нужный API) — воткнул гитару в комбик, положил рядом телефон и настраивай. =)
Да и вообще не очень понятно причём здесь PHP, apache, nginx (и, как справедливо замечено, Nagle's algorithm).
Неумеренность в буферах может привести к меньшей устойчивости к DDoS'y (условно). Впрочем, это требует исследования, на конкретных «попугаях» — куда будет быстрей расходоваться память — на создание новой копии интерпретатора или на буферизацию. Точнее отношение этих объёмов. Может быть создание копии интерпретатора потребляет памяти значительно больше, чем выделяется под буферы. Поэтому эффект от увеличения буфера может быть, в целом, положительным.
Соглашусь, exec() не подходит в данном случае. Больше подходи proc_open() и аналоги. Мысль была, что прослойка в виде web-сервера излишня (конкретика реализации альтернативы не представлялась для меня важной во время написания).
Слишком громкий заголовок, но, увы, выбрана не слишком подходящая терминология.
Собственно это вряд ли эмуляция и PHP здесь совсем не причём. Подобные запросы к серверу выполняющему задачи параллельно можно генерировать любым удобным способом (то есть PHP можно смело удалить из заголовка). Затем, многопоточность — это несколько иное понятие, относящееся к множеству «потоков исполнения» в контексте одного процесса (характерный признак — разделяемые ресурсы, доступные потокам в рамках процесса).
Можно было использовать асинхронные (неблокирующие) сокеты PHP (реализовав протокол SMTP средствами PHP), это можно было бы назвать «эмуляцией» многопоточности (понадобился бы «планировщик» обслуживающий события на сокетах).
Статья скорее об организации многозадачности посредством подходящего web-сервера, нежли о многопоточности в PHP. Да собственно, можно было воспользоваться средствами ОС используя какое-нибудь приложение для отправки почти (например запуская через exec() программу sendmail), что уменьшило бы накладные расходы.
Владимир Владимирович (чуть не добавил Путин =), вот вроде бы хорошие, умные вещи пишите, правильные. Но посмотрите какая подача материала!
Зачем дешёвый рекламный ход в первой строчке?! Какой злой дяденька врач Вас в детстве так обидел? Боялись ходить к зубному, дядя с дрелью делал бо-бо? Ну да ладно, что это я уподобляюсь-то...
Обратите внимание на местную аудиторию неужели ей нужны пустые цветастые фразы? Неужели Вы так низко оцениваете интеллект сообщества, что позволяете себе фразы в стиле быдлоагиток (и дело даже не в реальном уровне этого эфемерного "интеллекта", а в позиционировании сообщества)? Профессиональный журналист и допускаете такие ляпы. Не хватает ещё "ути-пути, маленький, возьми с полки пирожок" и сопельки вытереть. И вроде бы грамотное противопоставления "выберешь а) будешь в шоколаде, выберешь б) будешь с геморроем", навроде на****евшей рекламы "сравним обычный стиральный порошок и новый супер-пупер". Честное слово, неприятно, когда считают читателей за идиотов.
Пытаетесь донести что-то полезное до сообщества говорите с ней на одном языке. Впрочем, вряд ли я могу Вас чему-то научить, Вы всё сами прекрасно понимаете (поэтому мне вдвойне непонятен стиль и построение сообщения).
В таком случае все языки программирования очень похожи. Все используются для формализованной записи алгоритмов. То есть минимально каждый язык содержит функции оперирования данными (любые вычисления, присвоения, индексация массивов и т.п.) и принятия решений (сравнения, условные переходы и т.п.). Синтаксис Perl и JavaScript синтаксически близок к C/C++. Но важно не синтаксичское сходство, а скорей идеологическое. Идеология Perl (и методика программирования, если она для Perl вообще существует =)) далека от JavaScript.
С не меньшим успехом можно склепать "JavaScript и PHP очень похожи" или "JavaScript и C++ очень похожи" (нужно только поправить соответсвующие примеры) и т.п. Можно подумать, что проблемы разработки упираются только в вопрос синтаксиса используемого языка. Ассоциативные массивы, функции, регулярные выражения, ООП и прочий "ширпотреб" в том или ином виде есть практически в любом более-менее развитом и востребованном языке программирования. Тут напрашивается пример с естественными языками: если дословно переводить русские слова на английский ничего хорошего не получится, менталитет не тот =).
v.a = 1, v.b = 2
a = 1, b = 2
Microsoft ® C/C++ Optimizing Compiler Version 16.00.30319.01 for x64
«Программа выполнила недопустимую недопустимость» =)
Неправильно извлекаются параметры со стека.
А если ещё отличается и механизм вызова (__attribute((__stdcall)) в GCC или __stdcall, __fastcall и т.п. в MSC)? Правда name mangling минимизирует вероятность таких ошибок, но при желании можно получить «результат».
Мораль проста и очевидна — прототипы функций необходимы. =)
2010: В чём измеряется сила тока?
а) в амперах
б) в вольтах
в) в омах
2020: Уж не в амперах ли измеряется сила тока?
а) да
б) нет
в) не знаю
2030: Сила тока измеряется в амперах.
а) да
б) есть
в) так точно
По опыту всяких концертов могу сказать, что компьютер, да ещё с интернетом, да ещё с нужной версией флеша (хотя это мелочь), да ещё к которому разрешат воткнуться гитарой (а ещё не забыть с собой переходник «джек->мини-джек») вещь практически нереальная. А вот найти тюнер/камертон гораздо проще. Да и вообще, что это за музыкант, без тюнера/камертона на выступлении?!
Этак проще записать на мобильник эталонные сигналы нужной частоты — карманный камертон за минимальные усилия.
Вот было бы чудесно приложение для мобильника, которое может имитировать камертон. А ещё чудесней — тюнер. Чтобы измеряло сигнал с микрофона (не знаю, есть ли нужный API) — воткнул гитару в комбик, положил рядом телефон и настраивай. =)
Неумеренность в буферах может привести к меньшей устойчивости к DDoS'y (условно). Впрочем, это требует исследования, на конкретных «попугаях» — куда будет быстрей расходоваться память — на создание новой копии интерпретатора или на буферизацию. Точнее отношение этих объёмов. Может быть создание копии интерпретатора потребляет памяти значительно больше, чем выделяется под буферы. Поэтому эффект от увеличения буфера может быть, в целом, положительным.
Собственно это вряд ли эмуляция и PHP здесь совсем не причём. Подобные запросы к серверу выполняющему задачи параллельно можно генерировать любым удобным способом (то есть PHP можно смело удалить из заголовка). Затем, многопоточность — это несколько иное понятие, относящееся к множеству «потоков исполнения» в контексте одного процесса (характерный признак — разделяемые ресурсы, доступные потокам в рамках процесса).
Можно было использовать асинхронные (неблокирующие) сокеты PHP (реализовав протокол SMTP средствами PHP), это можно было бы назвать «эмуляцией» многопоточности (понадобился бы «планировщик» обслуживающий события на сокетах).
Статья скорее об организации многозадачности посредством подходящего web-сервера, нежли о многопоточности в PHP. Да собственно, можно было воспользоваться средствами ОС используя какое-нибудь приложение для отправки почти (например запуская через exec() программу sendmail), что уменьшило бы накладные расходы.
Зачем дешёвый рекламный ход в первой строчке?! Какой злой дяденька врач Вас в детстве так обидел? Боялись ходить к зубному, дядя с дрелью делал бо-бо? Ну да ладно, что это я уподобляюсь-то...
Обратите внимание на местную аудиторию неужели ей нужны пустые цветастые фразы? Неужели Вы так низко оцениваете интеллект сообщества, что позволяете себе фразы в стиле быдлоагиток (и дело даже не в реальном уровне этого эфемерного "интеллекта", а в позиционировании сообщества)? Профессиональный журналист и допускаете такие ляпы. Не хватает ещё "ути-пути, маленький, возьми с полки пирожок" и сопельки вытереть. И вроде бы грамотное противопоставления "выберешь а) будешь в шоколаде, выберешь б) будешь с геморроем", навроде на****евшей рекламы "сравним обычный стиральный порошок и новый супер-пупер". Честное слово, неприятно, когда считают читателей за идиотов.
Пытаетесь донести что-то полезное до сообщества говорите с ней на одном языке. Впрочем, вряд ли я могу Вас чему-то научить, Вы всё сами прекрасно понимаете (поэтому мне вдвойне непонятен стиль и построение сообщения).
С не меньшим успехом можно склепать "JavaScript и PHP очень похожи" или "JavaScript и C++ очень похожи" (нужно только поправить соответсвующие примеры) и т.п. Можно подумать, что проблемы разработки упираются только в вопрос синтаксиса используемого языка. Ассоциативные массивы, функции, регулярные выражения, ООП и прочий "ширпотреб" в том или ином виде есть практически в любом более-менее развитом и востребованном языке программирования. Тут напрашивается пример с естественными языками: если дословно переводить русские слова на английский ничего хорошего не получится, менталитет не тот =).