Говнокод ли?

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

Каждый SmlWindowIconSet() превращается в один reset() и от одного до двух append'ов. Вопрос только в сайдэффектах от этого, т.е. не приведёт ли это к визуальным деффектам.

И вообще, как ресеттить, если есть только Replace и Append.

reset() это replace с нулевым буфером.

Встречный вопрос, а что будешь делать, если будет больше двух размеров иконок? Наверняка же 32x32 это совсем не предел в наше время.

Каждый SmlWindowIconSet() превращается в один reset() и от одного до двух append'ов.

т.е. вы предлагаете: Создать два флага для каждого окна - icon16set и icon32set. Ставить их когда соответствующая иконка для окна установлена. Для того, чтобы избежать append(16) + append(16), ибо может сорвать башню.

Встречный вопрос, а что будешь делать, если будет больше двух размеров иконок? Наверняка же 32x32 это совсем не предел в наше время.

На своей юнити я пробовал следующие размеры: 16х16, 32х32, 64х64, 128х128. Сработали только 16 и 32.

т.е. вы предлагаете: Создать два флага для каждого окна - icon16set и icon32set. Ставить их когда соответствующая иконка для окна установлена. Для того, чтобы избежать append(16) + append(16), ибо может сорвать башню.

нет же, предлагаю перед каждым выставлением иконок делать reset(), никаких флагов не нужно.

нет же, предлагаю перед каждым выставлением иконок делать reset(), никаких флагов не нужно.

reset append(32)

reset append(16)

Результат - потеряли 32х32

нужно так

SmlWindowIconSet(mywin1, icon16x16, icon32x32);

reset();
append(icon16x16, 16);
append(icon32x32, 32);

SmlWindowIconSet(mywin1, icon16x16, icon32x32);

Дзынь-дзынь-дзынь-дзынь. Смотрим первый пост.

говнокод! у функции должен быть один вход и один выход! sizeof надо любить и жаловать. А вот магические константы нет. Также не должно быть стыдно использовать макросы.

луговский не иначе

Не будет, если ты заведешь RET_ERR_CODE, поприсваиваешь ее, а потом вернешь в одном месте. Хотя, по-моему, это вопрос стиля.

И да, присоединяюсь к советчикам навыносить все в функции. Тогда код будет примерно таким:

if (!is_window_valid) {
  return ERROR_BLAH_BLAH_0
}
if (!img_assigned) {
  return ERROR_BLAH_BLAH_1
}
// ...

Это щитаецца глаже?

int func()
{
   int err_code;

   err_code = do();
   if (err_code != error)
   {
      err_code = do2();
      if (err_code != error)
      {
         err_code = do3();
         if (err_code != error)
         {
            err_code = do4();
            if (err_code != error)
            {
               err_code = do5();
            }
         }
      }
   }

   return err_code;
}

int func();
{
   int err_code;
   if (err_code = do()  == error) return error;
   if (err_code = do2() == error) return error;
   if (err_code = do3() == error) return error;
   if (err_code = do4() == error) return error;
   if (err_code = do5() == error) return error;
}

Давайте, продолжайте дрочить на один выход из функции.

rha это тоже касается

if ((image16 == SML_NOTASSIGNED) &&
(image32 == SML_NOTASSIGNED))
return SML_ERR_BADIMAGE;

Замени на

if ((image16 & image32) == SML_NOTASSIGNED) return SML_ERR_BADIMAGE;

Замени на

if ((image16 & image32) == SML_NOTASSIGNED) return SML_ERR_BADIMAGE;

Почему же битовые хаки тут должны сработать?

~> cat sml.c
#include <stdio.h>

enum {
	SML_NOTASSIGNED = 0, // Why not?
	SML_BAD_IMAGE = -1,
	SML_ERR_SUCCESS = 0
};

int test1(int image16, int image32)
{
	if ((image16 == SML_NOTASSIGNED) 
			&& (image32 == SML_NOTASSIGNED))
		return SML_BAD_IMAGE;

	return SML_ERR_SUCCESS;
}

int test2(int image16, int image32)
{
	if ((image16 & image32) == SML_NOTASSIGNED)
		return SML_BAD_IMAGE;

	return SML_ERR_SUCCESS;
}


int main()
{
	int image16 = 1;
	int image32 = SML_NOTASSIGNED;

	printf("test1: %s\n", test1(image16, image32) == SML_BAD_IMAGE 
			? "failed" : "passed");	
	printf("test2: %s\n", test2(image16, image32) == SML_BAD_IMAGE 
			? "failed" : "passed");	
}

~> ./sml
test1: passed
test2: failed

Я же сказал, что это дело вкуса, выдыхай, лапочка.

анонимный индус детектед

typedef int (*func_ptr_t)();

int func()
{
    static func_ptr_t func_ptr[] = {do1, do2, do3, do4, NULL};
    func_ptr_t *fptr;
    int err_code = NOERROR;

    fptr = func_ptr;
    while ((*fptr != NULL) && ((err_code = (*fptr)()) != ERROR))
    {
        fptr++;
    }

    return err_code;
}

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

Не анонимный индус в треде - надо делать илитно, удобно, антииндусно очень сильно и стильно.

#include <stdio.h>

typedef int(*func_ptr_t)(void);//осильте уж наконец-то

#define __vec_type_t(T) \
typedef struct {\
  typeof(T) * begin, * end;\
} vec_##T##_t

#define vector(T) vec_##T##_t
#define vec_foreach_old(vec, body) do { typeof(vec) _l_vec = vec; typeof(_l_vec.begin) it = _l_vec.begin; do body while(++it != _l_vec.end); }while(0);


__vec_type_t(func_ptr_t);
__vec_type_t(void);

#define c_constructor(...) (typeof(__VA_ARGS__) []){ __VA_ARGS__ }

#define _vector_multiconstructor(...) ({\
  void * _t = c_constructor(__VA_ARGS__);\
  &(vector(void)){_t, (_t + sizeof(c_constructor( __VA_ARGS__)))};\
})

int base(char * str) {
  return fprintf(stderr, "%s\n", str);
}

int f0(void) {
  return base("f0");
}

int f1(void) {
  return base("f1");
}

int f2(void) {
  return !base("f2");
}

int multi_check(vector(func_ptr_t) vec) {
  int ret = 0;
  vec_foreach_old(vec, {if((ret = (*it)()) == 0) goto end;});
  end: return ret;
}
#define multi_check(...) multi_check(*(vector(func_ptr_t) *)_vector_multiconstructor(__VA_ARGS__))

int main(void) {
  fprintf(stderr, "%u\n", multi_check(f0, f1, f2));
}

Стильно, модно - молодёжно 110%.

Осиль нормальный си-диалект, либо хотябы осиль минимально нужные фичи ЯП.

Юзай нормальные захватывалки ресурсов. Хот я даже не знаю что вы под ресурсами подразумеваете - «память»? Дак юзай норм аллокатор.

Все твои проблемы вызванны банальным неумением писать код, либо нежелаем юзать какие-то фичи.

Выносишь все зависимые от «ресурсов» вызовы в одтельную группу - сохраняй состояние до этой групы - и если произошла ошибка - сбрасывай его дот ого состояния, которое было до ошибки.

Яйцо тоже, только скорлупок много. Дебаггер обрадуется, когда такой код увидит. Ну а так да, модненько, стильненько.

Ай, маладца! Паймал на невнимательности :) Возьми с печки пирожок.

Ай, маладца! Паймал на невнимательности :) Возьми с печки пирожок.

Я всякие варианты рассматривал, но где-то тут моя фантазия кончилась:

[~]$ cat sml.c 
#include <stdio.h>

enum {
	SML_NOTASSIGNED = 0, // Why not?
	SML_BAD_IMAGE = -1,
	SML_ERR_SUCCESS = 0
};

int test1(int image16, int image32)
{
	if ((image16 == SML_NOTASSIGNED) 
			&& (image32 == SML_NOTASSIGNED))
		return SML_BAD_IMAGE;

	return SML_ERR_SUCCESS;
}

int test2(int image16, int image32)
{
	if ((image16 & image32) == SML_NOTASSIGNED)
		return SML_BAD_IMAGE;

	return SML_ERR_SUCCESS;
}

int test3(int image16, int image32)
{
	if ((image16 && image32) == SML_NOTASSIGNED)
		return SML_BAD_IMAGE;

	return SML_ERR_SUCCESS;
}

int main()
{
	int image16 = 1;
	int image32 = SML_NOTASSIGNED;

	printf("test1: %s\n", test1(image16, image32) == SML_BAD_IMAGE 
			? "failed" : "passed");	
	printf("test2: %s\n", test2(image16, image32) == SML_BAD_IMAGE 
			? "failed" : "passed");	
	printf("test3: %s\n", test3(image16, image32) == SML_BAD_IMAGE 
			? "failed" : "passed");	
}

[~]$ ./sml 
test1: passed
test2: failed
test3: failed

Извините, не телепат.

AptGet

Да ладно, ничего страшного. Пирожок заслужили все равно. Моя невнимательность заключается в том, что предложенное мной решение не предусматривает универсальности. В предложенном вами коде используется enum с определенными значениями, которого нет в исходном коде. Снимаю шляпу.

Яйцо тоже, только скорлупок много.

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

Дебаггер обрадуется, когда такой код увидит.

Кто увидит, какой код? Чему обрадуется?

В чём собственно принципиальная разница по отношению к оригинальному коду, ставшему поводом для дискуссий? В том что нашпиговали препроцессорными вставками? Конечно нет. Важнее то, что функции вызываются через указатели. Что собственно происходит и в моём коде, который является наглядным представлением, как можно сделать иначе. То, что месье любит и умеет макро магию это похвально. Но следует учесть и то, что код стал менее читабельным и его сложнее дебажить. Те, кто работал над большими проектами в больших командах, знает о чём идёт речь. А строчка

if((ret = (*it)()) == 0) goto end;

В данном контексте дебаггер - это тот кто дебажит (в смысле человек). Есть и такая профессия. Про обрадуется это была ирония.

В чём собственно принципиальная разница по отношению к оригинальному коду, ставшему поводом для дискуссий?

В том, что вместо тысяч портянок - можно юзать if(check(любое кол-во функций));

Но следует учесть и то, что код стал менее читабельным и его сложнее дебажить.

С чего он менее читабельный? Это ты только что придумал? Т.е. дебажить 100500 циклов проще, чем примитивный макрос? Кулстрори и не иначе.

Тут примитивный c_constructor() - который делает из 123, 123, 123 - (typeof(123)){123, 123, 123} - это обычный гнусишный конструктор/список инициализации.

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

vector() - это тоже банальная фигня.

Форич тоже.

Дак что тут дебажить? Конечно постстудент еле-еле «осиливший» с89 на уровне детсада это не осилит, но любой более-менее вменяемый человек это поймёт, причем это намного проще, чем твоя портянка.

Те, кто работал над большими проектами в больших командах, знает о чём идёт речь.

Обычно комманда на 95% состоит из бездарей. Если уровень твоей комманды этого не позволяет - не юзай, но это не мои проблемы.

ай-яй-яй какая нехорошая. И дело даже не в операторе goto.

Ты мне конечно же расскажешь - чем же она нехорошая? Никто тебе не запещает юзать ERROR NOERROR и любые любимые тобою кастыли.

Никто не запрещает юзать typeof(*(vec.begin)) f = *it, либо перепилить форич, либо выпилить его - если тебе непонятно откуда взялось it.

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

В данном контексте дебаггер - это тот кто дебажит (в смысле человек). Есть и такая профессия. Про обрадуется это была ирония.

Ну если твой «Дебагер» привык к лапше - это не мои проблемы. Объективно моя портянка ничем не сложнее для «дебагера». Всё это оправдания - лижбы не писать нормально.

То, что месье любит и умеет макро магию это похвально.

Это не макромагия - это примитивные гнусишные банальности. Магия - это совершенно другое. Это когда юзаются особенности и кривости самого препроцессора. Сдесь же он юзается как функция для обхода типов - это то, для чего макросы в 70% случаев и юзаются.

if((ret = (*it)()) == 0) goto end;

Ах ну и да, сюда можешь впилить continue, если так бомбит от гото.

...
#define __vec_type_t(T) \
typedef struct {\
  typeof(T) * begin, * end;\
} vec_##T##_t

#define vector(T) vec_##T##_t
...

может лучше так?

#define vector(T) vec_##T##_t

#define __vec_type_t(T) \
typedef struct {\
  typeof(T) * begin, * end;\
} vector(T)

В том, что вместо тысяч портянок - можно юзать if(check(любое кол-во функций));

если в том объёме, как сейчас имплементировано, то можно просто написать

if (do1() && do2() && do3() && do4())
{
    //do something...
}
else
{
    // do something else
}

Конечно постстудент еле-еле «осиливший» с89 на уровне детсада это не осилит, но любой более-менее вменяемый человек это поймёт, причем это намного проще, чем твоя портянка.

Удивишься, но твой код не компилится под ARM нативным компилятором, так как он поддерживает только с90, то бишь c89 и не поддерживает гнушных расширений. Можно всех послать использовать gcc, но боюсь к тебе не прислушаются.

С чего он менее читабельный? Это ты только что придумал? Т.е. дебажить 100500 циклов проще, чем примитивный макрос?

У меня всего один цикл был, у тебя два в один макрос засунуты и всё в одной строке. Тем и не читабельный.

наверное ты имел ввиду break.

если в том объёме, как сейчас имплементировано, то можно просто написать

Это не обьём - там реальный объём можно засунуть в 3-4строчки - они просто норм написанны.

А теперь получи возврат последней функции и сравни с NOERROR - 100строк, да даже так на моей портянке меньше писать.

Это также просто как твой if (check(do1, do2, do3, do4)) только без выпендрежа и работает быстрее.

Ну не такой же - мой фичастей и умнее - выдаёт последнюю ашибку, может вообще со всех ашибки собрать, можно сравнивать с чем угодно. Не быстрее - единственная проблема - это тупёж гцц на функции + цикл/массив, ибо он нихерна не может отследить даже примитивный вызов через указатель. В 10% конст спасает.

Если тебе надо добавить дополнительную функциональность, то есть увеличить тело твого ужасного форича, то внезапно корявый форич становится ещё корявее.

У меня есть форич, который тыкает функцию на итерацию и прочее. Ты просто не привык к лямбдам - допфункциональность != тысячи строк лапши. Реально у меня больше строчки никогда в фориче кода не бывает, а если бывает - я выношу это в функцию.

Собственно твой форич и есть предмет моих нареканий. Если он тебе так нужен, допили и сделай красивым.

Он красивый по моему, что в твоём понимании «красивый» я не знаю.

По мне лучше непечатать два символа больше и видеть нормальный цикл while , чем макрос, который берёт на вход одну переменную, а в теле использует другую, непонятно откуда растущую.

Яж тебе не зря написал - ты можешь добавить в него аргумент(foreach(vec, (type или без) it, {}). Ты можешь тело вынести за макрос.

Точнее понятно откуда, но за такое надо по рукам бить.

С чего? Никаких объективных причин на это нет.

Дебажить сложнее.

Миф. В этом фориче сложнее зафейлить, чем не в фориче. Если ты зафейлишь - он в 95% отвалится - для остальных ты можешь сделать рантайм проверки, если ты адепт псевдобезопасности.

Тыж не говоришь - extern - фу, фу. Дебажить сложнее - еррно мы не юзаем. Выкинуть extern из ЯП - откуда взялась переменная не понятно. Это лишь придирки.

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

Я пишу циклы только так: type * it = begin; do { } while(++it != end);(это плюсовое прошлое, но конструкция мне нравится) - на другие конструкции я смотреть даже не могу, поэтмоу мне это удобнее и проще, ибо в противном случае для компактности мне надо будет юзать for() - который я ненавижу.

Вектор-конструкция действительно интересна. Здесь должен отдать должное. Но я таких целей не преследовал. В своём коде я лишь хотел сделать акцент на использование функциональных указателей. Однако есть ньюанс и в отношении вектора.

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

Удивишься, но твой код не компилится под ARM нативным компилятором, так как он поддерживает только с90, то бишь c89 и не поддерживает гнушных расширений. Можно всех послать использовать gcc, но боюсь к тебе не прислушаются.

А твой конпелятор имеет какие-то плюсы над гцц? У гцц арм-бэкенд фуфло? Я сомневаюсь, поэтому очередная придирка. Я не вижу смысла юзать какой-то недоконпелятор, если он не лучше гцц.

Мне с89 не хватает - я юзаю gnuc - мне хорошо.

У меня всего один цикл был, у тебя два в один макрос засунуты и всё в одной строке. Тем и не читабельный.

У меня один цикл, который находится НЕ В МАКРОСЕ, А В ФУНКЦИИ, в которой разворачивается форич. Форич - это вайл в макросе, который абсалютно читаем.

Почему-то даже ваятели на жабаскрипте этот синтаксис осилили, а твой «дебагер» не может? Я тебе не заставляю писать так же - я просто показал как может «сишка» и всё. Естественно, если ты пишешь на c89 - для тебя всякие f((type){a, (type){b, c}}) - нечитаемы и прочее.

typedef struct {
  uint64_t a, b;
} ab_t;

typedef struct {
  ab_t ab;
  uint64_t c;
} abc_t;

inline abc_t inc(abc_t t) {
  return (abc_t){(ab_t){++(t.ab.a), ++(t.ab.b)}, ++(t.c)};
}

abc_t a = inc((abc_t){(ab_t){1, 2}, 3});

И ты мне будешь так же говорить, что можно подругому и типа это не читаемо. Для меня - чем более компактен код - тем он более читаем.

Я пишу 100500 функций-однострочников и из них составляю программу - ты мне можешь сказать, что можно написать портянку на 200строк - ок, но я не пишут так и тебя не заставляю.

Наверное.

Не быстрее - единственная проблема - это тупёж гцц на функции + цикл/массив

противоречишь сам себе.

Реально у меня больше строчки никогда в фориче кода не бывает, а если бывает - я выношу это в функцию.

Это нормальный подход. Ничего нового в этом нет.

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

И ты мне будешь так же говорить, что можно подругому и типа это не читаемо.

Не буду. Здесь всё очень читаемо и красиво, потому что всё на своих местах.

противоречишь сам себе.

Не противоречу - работать медленней не будет, но гцц от этого тупить не перестанет.

Это нормальный подход. Ничего нового в этом нет.

Причем тут новое - зачем ты придрался к форичу? Со своим функционалом?

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

Т.е. вменяемых ответов от тебя нет? Т.е. ты пишешь под говно на говне не пытаясь это исправить, либо какие-то профиты всёже есть, а если их нет - неосиляторство по любой причине не агрумент.

противоречишь сам себе.

Не противоречу - работать медленней не будет, но гцц от этого тупить не перестанет.

Это нормальный подход. Ничего нового в этом нет.

Причем тут новое - зачем ты придрался к форичу? Со своим функционалом?

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

Т.е. вменяемых ответов от тебя нет? Т.е. ты пишешь под говно на говне не пытаясь это исправить, либо какие-то профиты всёже есть, а если их нет - неосиляторство по любой причине не агрумент.

Не противоречу - работать медленней не будет, но гцц от этого тупить не перестанет.

а цикл с инкрементами и чеком у тебя за нулевое время выпролняется?

Причем тут новое - зачем ты придрался к форичу?

потому что он кривой. К тому же ты первый придрался к моему функционалу. Напиши мой вайл в одну строчку, он будет лучше чем твой форич, если ты любишь «всё компактно». Кстати, да, у меня нет строчек длинее 80 символов. Выкинь NOERROR. Он не нужен, если сделать предположения о значениях возвратов функций. Я не выкинул, так как у топик стартера что-то похожее было и чтоб ему было ближе. Но по всей ему это не интересно.

Т.е. вменяемых ответов от тебя нет?

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

Т.е. ты пишешь под говно на говне не пытаясь это исправить, либо какие-то профиты всёже есть

Если для тебя ARM говно, то мне тебя жаль. И компилятор у них продвинутый, пусть даже только с89. Профиты, конечно, есть. И от них отказываться ради пары плюшек от gcc никто не собирается.

а цикл с инкрементами и чеком у тебя за нулевое время выпролняется?

Где ты там цикл увидел? чеком - он у тебя там тоже есть.

потому что он кривой. К тому же ты первый придрался к моему функционалу. Напиши мой вайл в одну строчку, он будет лучше чем твой форич, если ты любишь «всё компактно».

Чем он кривой - удиви. Придираться начал ты. С чего он будет лучше?

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

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

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

Дак эти требования должны быть на чем-то основанны - приведи мне основание, я не вижу смысла где-то юзать не гцц. Только неосиляторство.

Пример смыслов - встудию.

Если для тебя ARM говно, то мне тебя жаль.

Говно не арм, а c89, а под говно - это под говенный конпелятор. arm твой тут непричем.

И компилятор у них продвинутый, пусть даже только с89.

Чем продвинутый?

Профиты, конечно, есть. И от них отказываться ради пары плюшек от gcc никто не собирается.

Какие профиты? Хоть один назови.

Дак эти требования должны быть на чем-то основанны - приведи мне основание, я не вижу смысла где-то юзать не гцц. Только неосиляторство.

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

Где ты там цикл увидел? чеком - он у тебя там тоже есть.

do body while(++it != _l_vec.end); И я сравнивал с if do1() && do2() && .... Ты просто забыл.

Чем он кривой - удиви.

Я понял, что я тебя не удивлю. Если тебе нравится использовать локальные переменные определённые на Марсе в макросе, но упавшие в твою функцию, то пожалуйста.

С чего он будет лучше?

тем что он прямой

последний код возврата в студию, либо стек возвратов - твой иф нихрена даже близко не аналог моему чеку.

Последний код возврата и так выдаётся. ОК, у меня просто тупая функция, которая оперирует со статическим массивом. Если надо можно передовать его как входящий параметр. Стека возвратов и у тебя нет. Но это делается и в моём коде быстро. Вообще, спор ни о чём. Твой код по сути тот же как и у меня, только с кривым форичем и прикольным вектором, который к сожалению работает только в gcc.

Дак эти требования должны быть на чем-то основанны - приведи мне основание, я не вижу смысла где-то юзать не гцц. Только неосиляторство.

Например, суппорт от ARM. Можно кричать про неоссиляторство читать ман'ы, но это будет пустым звуком в сортире. Когда речь о важных заказах и благополучии клиента, то суппорт очень нужен. ARM компилятор выдаёт очень компактный код, что откликается в бюджете на память. Кроме того важен не только сам компилятор, но и весь тулчейн с линкером, компактной libc и т.д.

Говно не арм, а c89, а под говно - это под говенный конпелятор. arm твой тут непричем.

ARM это не только проц, но и компания, которая в том числе выпускает и тулчейн к нему, в том числе компилятор c89. Ты опять противоречишь.

Чем продвинутый? Какие профиты?

Читай выше

Тыж когда к хихургу на лоботомию пойдёшь не будешь права качать - чем ему и как работать или ты там же будешь кукарекать, что надо ржавым гвоздём вскрывать, ибо так заказчик выбрал?

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

do body while(++it != _l_vec.end); И я сравнивал с if do1() && do2() && .... Ты просто забыл.

Что ты сравниваешь.

Я понял, что я тебя не удивлю. Если тебе нравится использовать локальные переменные определённые на Марсе в макросе, но упавшие в твою функцию, то пожалуйста.

Это глупая придирка, которая не имеет смысла. Мне не интересны твои субъективные придирки, которые релизуются так же просто, как мой форич. Вот если бы то, о чем тыг оворил было бы нереализумо - тогда да, а так «бла-бла».

тем что он прямой

Т.е. ты мне не скажешь почему мой код кривой, а твой прямой? Кроме глупых «непонятно откуда и как работает» - оставь это.

Последний код возврата и так выдаётся.

Нет, if( f() && f1()) тебе никакого кода вовзрата без кастылей не выдаст. Я уж не говорю о моя запись удобней.

ОК, у меня просто тупая функция, которая оперирует со статическим массивом.

Не имеет значения с чем там оперирует твоя функция внутри.

Если надо можно передовать его как входящий параметр.

А как ты запишешь свои функции в этот массив? Зачем ты юлишь? Именно в составлении массива из аргументов и есть смысл 90% моей портянки.

Стека возвратов и у тебя нет.

Это делает одно строчкой и не меняет ни синтаксиса вызова, ни семантики функции.

Но это делается и в моём коде быстро.

Не быстро, а превращает иф в лапшу. И в твоём коде надо делать 100500 функции на каждый набор функции, либо делать что-то типа моего конструктора. В конечном итоге ты будешь делать тоже самое, что и уменя, но через жопу на с89.

Вообще, спор ни о чём. Твой код по сути тот же как и у меня, только с кривым форичем и прикольным вектором, который к сожалению работает только в gcc.

Я не знаю зачем ты начинаешь судить о коде словами «кривым», хотя ты мне никогда не докажешь, что он кривой - ибо он не кривой. И на попытках доказательства ты лябо сядишь в лужу, либо будешь говорить шаблонным субъективными догматами из подднного мира. Не только в гцц, да и не забывай - конпеляторы кроме ГГЦ ОБЪЕКТИВНО не нужны, ибо не лучше гцц. Да и все вменяемые конпеляторы просто обязаны поддерживать хотябы базовые ггцизмы.

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

Это будет лишь твоя пытка снять с себя ответственность. Объективной причиной это не является. Это пустой звук в сортире с твоей стороны.

Когда речь о важных заказах и благополучии клиента, то суппорт очень нужен.

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

ARM компилятор выдаёт очень компактный код, что откликается в бюджете на память.

Естественно нормальный конпелятор не выдаёт компактный код - он выдаёт синергию между компактностью и качеством кода. Одна компактность - это примитивщина. Неосилил гцц и нормальном написание компактного кода. То, что твоей недоконпелятор выдаёт говнокод, который типа компактный - от этого мне не холодно и не жарко. Затюнить гцц ты можешь до такого же состояния.

Про бюджете на память ты мне не рассказывай - это банальная байка со дна авр"а. Ты это будешь свои клиенам рассказывать.

Кроме того важен не только сам компилятор, но и весь тулчейн с линкером, компактной libc и т.д.

Гнутый линкер самый фичастый - можешь затюнить как хочешь. Компактная либц - таких не бывает. 90% функций в либц по определению не могут быть компактными, а если тебе нужна компактность - запили, либо возьми готовое. Там делов-то 2минуты на функцию, темболее тебе похрен на то, как она работает, а зпилить «компактно» может любой идиот.

Темболее экономия памяти и либц както мало с собой вяжутся.

ARM это не только проц, но и компания, которая в том числе выпускает и тулчейн к нему, в том числе компилятор c89. Ты опять противоречишь.

И что? Против архитектуры я ничего не имею. Тулчейн - говно, а с89 недоконпелятор - такое же говно.

Я не противоречу. Ты пытаешься спорить - хотя уже давно пора понять, что твоё нежелание юзать гцц - это не какая-та общая проблема, а проблема конкретно тебя, которая никаких объективных причин и аргументов не имеет.

Тыж когда к хихургу на лоботомию пойдёшь не будешь права качать - чем ему и как работать или ты там же будешь кукарекать, что надо ржавым гвоздём вскрывать, ибо так заказчик выбрал?

Ты что-то попутал, бизнесмен тупоголовый. Заказчик здесь тот, кому лоботомию делать будут. Он выбирает того, кто это будет делать и, соответственно, инструмент, которым пользуется исполнитель. Но ты не в состоянии это понять. Тебе лоботомию уже сделали, и, похоже, через заднепроходное отверстие. Потому что кроме питушков ты ни о чём думать не в состоянии. Видать актуальная для тебя тема. Видать, твоё дупло так часто долбят, что весь мозг выдолбили. С говном перемешали, которое ты разбрызгиваешь вокруг. Потому что мозг у тебя в жопе. Иди, дрочи на гцц и не кукарекай о том, что осознать не в состоянии.

Вот вы смеетесь над суперхакиром, а не все так просто.

Только недавно благодаря перебежчику Э.Сноудену открылась некоторая информация.

Еще в 70-е годы в США заметили что программисты на С сильно отличаются даже от программистов на Коболе и Фортране. Не говоря уже об обычных людях.

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

Результаты экспериментов сразу же засекретили. На самом высоком уровне были проведены консультации и приняты решения.

Во-первых начали массово внедрять FPU и пропагандировать отказ от целочисленных рассчетов.

Во-вторых было решено начать операцию «С++». Ее возглавил полковник Фредерик Розенкранц, взяв псевдоним Б.Страуструп. ФБР-овцам не откажешь в чувстве юмора, ведь Страуструп - это аббревиатура: STROng US, Training Retards Urgent Program (Сильные Штаты, срочная программа тренировки ритардов).

Чтобы не вызвать подозрений, школьников участвовавших в экспериментах было решено направить финансовыми аналитиками в ФРС, крупные банки и инвесткомпании. Часть направили в Microsoft и в Red Hat

Сноуден вообще привез много интересного. Например, вы слышали о том что Пол Грэм писал страстные стихотворения Гвидо ван Россуму? Что Алан Кокс носит накладную бороду? А то что на Торвальдса было 3 покушения? Спецслужбы были вынуждены приставить к нему каратистку для безопасности и это оформили как свадьбу

Аноны жгут не по детски.

мать, мать, мать... Пошёл хаскиль учить...

Дальнейшая дискуссия теряет смысл. Ты берёшь разные факты из разных постов мешаешь их вместе и получаешь бред, который тебя делает уверенней.

Речь идёт о снятии ответственности - это основа юза вами всякого ненужного говна.

О каком снятии ответственности идёт речь? Клиент покупает продукт, который должен работать. Если он не работает, то клиент не платит денег. Если ты используешь в своём продукте сторонние IP, то ответственность не переносится на собственника IP, а остаётся не тебе, так как ты продаёшь продукт. Если что-то не работает в стороннем, сожно конечно дебажить до потери пульса, а можно обратится в суппорт. Так как клиенту нужно решение всегда быстро, то суппорт нужен.

Естественно нормальный конпелятор не выдаёт компактный код - он выдаёт синергию между компактностью и качеством кода.

Нормальный компилятор выдаёт такой код, который ты попросишь. Для этого есть куча ключей. Кроме трейдоффа скорость/размер есть ещё куча других факторов, как-то стоимость, выбор подходящего HW, энергопотребление и т.д.

Затюнить гцц ты можешь до такого же состояния.

Невсегда и невезде. Иначе люди во всём мире стали бы использовать только gcc.

Про бюджете на память ты мне не рассказывай - это банальная байка со дна авр"а.

Если твои приложения бегают на седьмом уровне OSI, то про память можно вообще не думать.

Гнутый линкер самый фичастый

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