- 1
http://www.work.ua/jobs/1286767/
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+6
http://www.work.ua/jobs/1286767/
Я, конечно, знал, что С++ плох, но чтобы настолько...
+6
#define SET_VTYPE_AND_VARREF(type, val) \
this->vt = VT_ ## type | VT_BYREF; \
V_ ## type ## REF (this) = val;
TVariantT& operator=(System::Currency* src)
{
Clear();
if(src)
SET_VTYPE_AND_VARREF(CY,
reinterpret_cast<tagCY*>(&(src->Val)));
return* this;
}
Быдлер такой быдлер
стырено отсюда http://habrahabr.ru/company/pvs-studio/blog/179615/
+6
template <typename T, size_t rows, size_t cols>
class Matrix {
public:
Matrix() :
m_matrix(reinterpret_cast<T*>(new char[sizeof(T) * rows * cols]))
{
memset(m_matrix, 0, sizeof(T) * rows * cols);
new (m_matrix) T[rows * cols];
if ( rows == cols ) {
for ( size_t i = 0; i < rows; i++ )
m_matrix[i * cols + i] = 1; // FIXME: this is hack
}
}
// ...
private:
T *m_matrix;
};
Из прошлого куска.
Инициализируем память нулями. А вдруг тип скалярный? :)
+6
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
У МЕНЯ БОЛЬШОЙ ХУЙ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+5
Итак, теперь, когда на говнокодике осталась одна смегма, можно сделать вывод, кто же был сливками.
И принцип от противного: можно понять. кто из сливок и несливок был смегмой.
1. Инканус, производивший впечатление опытного спеца не брезгает общаться с быдлом. Его нахождение здесь сводится к подтролливанию с многочисленных ~оригинальных~ как ему кажется, учеток, и стёб на темы, далекие от программирования. Стало быть, он и ранее находился тут только ради этого. Иной раз, чтобы привлечь горстку уцелевших участников к комментированию, он проходит по стоку, постя ответы на рандомные комментарии, начинающиеся обычно словами "ну как": "ну как, сделал?" Человек недалекого ума, явно.
2. Есть мнение, что Илья, известный как Борманд, также не прочь "помесить говнца", с гостевых учеток. Не палимся, ага.
3. Подзалупная перхоть, вроде гостей а также неизвестно кому принадлежащих учеток, вроде ISO, Desktop, AnimeGovno и прочих, деятельность которых тоже сводится к пустому трепу на отвлеченные темы.
4. Ну и разумеется, я - головка от часов "Заря". Я часто захожу сюда потроллить, но собственно, свою позицию я обозначил очень давно.
+5
Это очень забавно, скажу я Вам, установив очередной антивирус, втыкать в инонку в трее, представляя, как она защищает
твою систему от несуществующих угроз.
Задача любого антивирусника - ЛЮБОГО! - продержаться на компьютере как можно дольше чтобы он продлил лицензию ещё хоть пару раз. Лет 15-20 назад не иметь антивируса было вообще неприлично. Именно тогда вендоры научились наёбывать пользователей, внушив им, что системная защитная утилита, которой и интерфейс-то нахуй не нужен, должна быть напичкана свистоперделками и иметь приоритет Проводника. Внешний вид - половина успеха. И похуй, что кроме мигания значком в трее софтина в принципе ничего не делает.
...Тем более странно, что на фоне набитых скинами софтин паучок Данилова выглядит "голяком". Может, метод от противново?
Кстати, почему все так текут от 360? Говно говном.
+5
// Heap memory allocate function (must not be used!)
caddr_t _sbrk(int incr) {
<...>
void some_bastard_called_sbrk();
some_bastard_called_sbrk(); // Produce linker error in case it is used
}
_ATTRIBUTE ((__format__ (__printf__, 1, 2)))
int printf (const char *__restrict format, ...)
{
<маленький трехколесный велосипед>
}
int putchar(int c)
{
<...>
}
int puts(const char *s)
{
<...>
}
_ATTRIBUTE ((__format__ (__printf__, 2, 3)))
int sprintf (char *__restrict s, const char *__restrict format, ...)
{
<...>
}
STM32. Я просто хочу использовать printf для вывода в последовательный порт и не течь. Ведь для этого нужно только реализовать int _write(int file, char *data, int len) и всё. Ой, а почему иногда программа падает где-то в кишках рантайма?
Может, стек переполняется? Да нет, проверил, значения в норме...
Просто стандартная библиотека от ST - это не курсовая ардуинщика, тут все системно, хендлы потоков, дескрипторы устройств и управляющие структуры. При первом обращении printf (и sprintf тоже!) выделяет себе в куче около 400 байт. Замечательное решение, помогающее сэкономить память, если мы не используем стандартный вывод! А куча тут - это просто последовательно заполняемая область памяти, размеры которой задаются в linker script (я вообще 0 указал, я ведь не использую malloc). Проверять выход за пределы кучи мы, конечно, не будем - зачем, когда рядом такая замечательная, никому не нужная область стека.
Да, и если забыть отключить буферизацию setvbuf(stdin/stdout/stderr, NULL, _IONBF, 0); , то он выделит не 400 байт, а килобайт (на контроллере с 8K RAM).
В общем, ах, оставьте меня, сам все напишу.
Только надо еще putchar и puts реализовать, а то компилятор любит printf'ы оптимизировать. И не забыть, что puts добавляет перевод строки. Уф, вроде все.
+5
// http://cmustdie.com/ - баттхерт анскильных лалок, неосиливших сишку
// Возьмём следующий фрагмент кода на языке Си:
int x = 1;
x = x << sizeof(int) * 8;
// Попробуем предположить, какой результат у нас получится. Допустим, мы скомпилировали этот
// код для процессоров архитектуры ARM. Инструкция битового сдвига в рамках этой аппаратной
// платформы определена так, что итоговым значением переменной "x" должен быть "0". С другой
// стороны, мы можем транслировать нашу программу в машинный код архитектуры x86. И уже там
// битовый сдвиг реализован таким образом, что значение "x" не изменится и останется равным
// "1". Мы могли бы сделать вывод, что результат работы данного фрагмента кода зависит от
// того, для какой аппаратной платформы мы его скомпилировали. Но на самом деле это не так.
// В действительности данный фрагмент кода может быть обработан компилятором любым возможным
// и невозможным образом. Причина в следующем: согласно тексту стандарта языка Си битовый
// сдвиг на величину, большую или равную размеру выражения в битах, является неопределённым
// поведением. Получается, нет никакой гарантии, что этот кусок кода вообще будет работать.
Охуеть конечно
+5
// And then I replaced the idiomatic Rust code for working with block like
for (dline, (sline0, sline1)) in dst.chunks_mut(dstride).zip(tmp.chunks(TMP_BUF_STRIDE).zip(tmp2.chunks(TMP_BUF_STRIDE))).take(h) {
for (pix, (&a, &b)) in dline.iter_mut().zip(sline0.iter().zip(sline1.iter())).take(w) {
*pix = ((u16::from(a) + u16::from(b) + 1) >> 1) as u8;
}
}
// with raw pointers:
unsafe {
let mut src1 = tmp.as_ptr();
let mut src2 = tmp2.as_ptr();
let mut dst = dst.as_mut_ptr();
for _ in 0..h {
for x in 0..w {
let a = *src1.add(x);
let b = *src2.add(x);
*dst.add(x) = ((u16::from(a) + u16::from(b) + 1) >> 1) as u8;
}
dst = dst.add(dstride);
src1 = src1.add(TMP_BUF_STRIDE);
src2 = src2.add(TMP_BUF_STRIDE);
}
}
What do you know, the total decoding time for the test clip I used shrank from 6.6 seconds to 4.9 seconds. That’s just three quarters of the original time!
And here is the problem. In theory if Rust compiler knew that the input satisfies certain parameters i.e. that there’s always enough data
to perform full block operation in this case, it would be able to optimise code as good as the one I wrote using pointers or even better.
But unfortunately there is no way to tell the compiler that input slices are large enough to perform the operation required amount of times.
Even if I added mathematically correct check in the beginning it would not eliminate most of the checks.
https://codecs.multimedia.cx/2021/05/missing-optimisation-opportunity-in-rust/
+5
function call_func_1(
f: () => void
) {
f();
}
function call_func(
f: (o: object) => void,
user: { firstName: string }
) {
f(user);
}
function main() {
const user = {
firstName: "World",
sayHi() {
print(`Hello ${this.firstName}`);
},
};
user.sayHi();
const hi = user.sayHi;
hi();
let hi2 = user.sayHi;
hi2();
call_func_1(() => {
hi2();
});
call_func(user.sayHi, user);
print("done.");
}
как тебе такой говно-пиздец Илон Маск?