LINUX.ORG.RU

Правильно ли я организовал выделение памяти?

 


3

2

Здравствуйте! «Правильно» ли я выделяю код для для текстовых строк (*s)? Является ли такой способ «экономичным» для хранения массива текстовых данных?

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
struct str_t {
	char     *s;
        double    e;
	int   a,b,c;
	long int  f;
} *pstr;
const int N=5;
char string_buf[80];

int main(){
pstr=(struct str_t*)malloc(N*sizeof(struct str_t));              
int i;
for(i=0;i<N;i++){
  scanf("%s",string_buf);		                                 
  pstr[i].s=(char *)malloc(strlen(string_buf)*sizeof(char));   
  strcpy(pstr[i].s,string_buf); 	                             
};

for(i=0;i<N;i++) free(pstr[i].s);
free(pstr);

return 0;
}
Все проверки опущены.

★★★★★

Последнее исправление: cetjs2 (всего исправлений: 3)

Ничему не учишься.

const int N=5;

const не имеет семантики в сишке, поэтому бесполезен.

int main(){

Мильёны бомжей никак не осилят тот факт, что main() == main(...), а правильно main(void), в отличии от плюсов.

pstr=(struct str_t*)malloc(N*sizeof(struct str_t));

О5 говнокнижки про С/С++? Воид в сишке существует и создан специально для того, чтобы ОН ЛЕГАЛЬНО КАСИТЛСЯ ВО ВСЁ - это семантика воида.

int i;

Это типа с89? Не нужно.

for(i=0;i<N;i++){

Цикл на счётке? Юзают только идиоты, в крайне случае в с89:

do { } while(++i != 5);

i<N

У тебя цикло до N, возрастающий и убывающие ан инкри/декримент циклы логичей писать через !=.

scanf(«%s»,string_buf);

libc убожество.

pstr.s=(char *)malloc(strlen(string_buf)*sizeof(char));

В норм коде это делается так:

typedef uint8_t string128_t __attribute__((__vector_size__(128)));
string128_t * strp = malloc(sizeof(string128_t) * 5);//конечно же в нормальном коде маллок не юзается, да собственно как и твои буфферы.

};

Зачем?

for(i=0;i<N;i++) free(pstr.s);
free(pstr);

free(strp);

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

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

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

Предположим тебе надо 100500 твоих буферов, при этом буферы должны быть кратны двойке, а не 80(десятичных) как у тебя. Ты берёшь кусок «памяти» на 1000500*128

Ты хреначишь что-то типа:

typedef uint8_t string128_t __attribute__((__vector_size__(128)));

string128_t * begin, * last, * end;

void stringbuf_alloc(uintmax_t count) {
  begin = last = malloc(sizeof(typeof(*begin)) * count);
  end = begin + 5;
}

string_t stringbuf_get(void) {
  return (last < end) ? last++ : NULL;
}

string_t stringbuf_dup(string_t str) {
  return strcpy(stringbuf_get(), str);//можешь захреначит strncpy() и тысячи других проверок, если лениво запилить нормально.
}

void stringbuf_free(void) {
  free(begin);
}

И твоя портянка меняется на:

int main(void) {
  stringbuf_alloc(5);
  string_t str;
  while((str = stringbuf_get())) scanf("%s", str);
  stringbuf_free();
}
Логика работает на читерстве, да и работает раз в 10быстрее твоей байды. Ты можешь запихнуть туда свой цикл на счётчике, но обычно это не нужно. Ты либо читаешь пока идёт, либо читаешь пока не зафейлится, либо получишь комманду на остановку - она может быть откуда угодно. Это всё делается в вайле.

В данном случае остановка - «окончание» «буфферов».

anonymous
()
Ответ на: комментарий от emulek

массив указателей на самом деле занимает 3.5%, потому не трогай его.

Рили? Массив указателей для константной длинны кусков? Куллстори.

Много места занимают хвосты строк, которые пихает аллокатор.

Какбэ не в строк дело - аллокатор параша.

Т.к. он не знает, будешь-ли ты двигать/уничтожать строки, или нет.

Какбэ не надо оправдывать парашу.

Если НЕ будешь, то выдели Over9000 памяти

Молодец.

и выделяй строки вплотную одна к другой.

Хреначь строки.

Будет быстрее в разы и в разы экономнее.

Нихрена не быстрее.

anonymous
()
Ответ на: комментарий от anonymous

Рили? Массив указателей для константной длинны кусков? Куллстори.

а почему нет? Так удобнее будет искать строку №n.

Какбэ не в строк дело - аллокатор параша.

кагбэ я и не говорил, что нужно обязательно юзать malloc(3)

Какбэ не надо оправдывать парашу.

за то он экономно жрёт память. Твоя правда: для текстовых строк это было актуально в 80х (:

Будет быстрее в разы и в разы экономнее.

Нихрена не быстрее.

см. рис 1 про массив указателей (:

emulek
()
Ответ на: комментарий от emulek

а почему нет? Так удобнее будет искать строку №n.

Чем? (str + 1), str[1], getn(1); Чем среднее лучше других 2-х?

Патамучто это параша - чтобы запонмить тебе этот массив тебе надо сделать больше движений, чем в моём варианта, а вот получить №n в моём варианте объективно проще, понятней и профитней. Это даже в обходе строк удобней, а он нужен часто, причем чаше, чем str[n]. К томуже дожопы оверхеда.

Объективно - говно.

кагбэ я и не говорил, что нужно обязательно юзать malloc(3)

Что ты там имел ввиду под хвастами которые пихает аллокатор я не знаю, да и ладно.

за то он экономно жрёт память. Твоя правда: для текстовых строк это было актуально в 80х (:

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

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

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

см. рис 1 про массив указателей (:

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

Вообщем ладно - это разговор ниочем, я просто к тебе придрался - прости.

anonymous
()
Ответ на: комментарий от anonymous

Чем? (str + 1), str[1], getn(1); Чем среднее лучше других 2-х?

ну просто с массивом указателей не обязательно делать все строки одинаковыми. Это позволит выиграть где-то до 33% памяти.

Что ты там имел ввиду под хвастами которые пихает аллокатор я не знаю, да и ладно.

любой аллокатор с удалением пихает хвосты.

Если строки нужны как отдельные сущности - их 100% нужно как-то менять, убирать и прочее - тут твой вариант не подходит

подходит. Если мне нужно заменить строку №17 в файле из 9000 строк, я просто выделяю 9001ю строку, и направляю туда указатель №17. Если замен немного, это работает и без уплотнения.

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

выравнивание можно делать во время выделения памяти под строки.

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

с этого есть профит: не нужно ничего удалять, пусть болтается. И расширять строки просто — просто выделяем нужную строку в другом месте. Ну а «пилить» — ты кодер, или где?

Вообщем ладно - это разговор ниочем, я просто к тебе придрался - прости.

тащем-то да, я просто один из вариантов дал. Нужно/не нужно — виднее ТСу.

emulek
()
Ответ на: комментарий от anonymous

О, здравствуйте! Спасибо за подсказки. Анализирую все комментарии и стараюсь делать выводы. У меня к Вам пару вопросов. В вышеуказанном листинге программа является исключительно «учебной».
1.Да, glibc «раздут», но что использовать?
2.Чем плохо использование const?
2.Чем плох цикл на счетчиках? дополнительной операцией (счетчик) и ячейкой памяти?
3. Почему «плохо» объявлять (int i) переменную?

int13h ★★★★★
() автор топика
Ответ на: комментарий от anonymous

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

длина строки от 0 байт до 80 символов.

int13h ★★★★★
() автор топика
Ответ на: комментарий от emulek

ну просто с массивом указателей не обязательно делать все строки одинаковыми. Это позволит выиграть где-то до 33% памяти.

Давай ты мне не будешь своё фуфло задвигать про 33%? Я знаю что и как, а балаболить не очень ты можешь в другом месте.

подходит. Если мне нужно заменить строку №17 в файле из 9000 строк, я просто выделяю 9001ю строку, и направляю туда указатель №17. Если замен немного, это работает и без уплотнения.

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

выравнивание можно делать во время выделения памяти под строки.

Выравнивание чего? Ты вообще понимаешь о чем я говорю? Судя по твоему выхлопу ты сложнее while(*str != needl) ++str; не писал.

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

с этого есть профит: не нужно ничего удалять, пусть болтается. И расширять строки просто — просто выделяем нужную строку в другом месте. Ну а «пилить» — ты кодер, или где?

Никто ничего не удаляет, это слово чтобы вы что-то понимали из моей речи. А сливать? А обходить?

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

тащем-то да, я просто один из вариантов дал. Нужно/не нужно — виднее ТСу.

Не виднее ему. Ты можешь что-то видеть лишь после определённого порога скилла - в противном случае будет такое же балабольство как у тебя. Мы даём ТС"у пищу для размышления, не сбивая его с пути и не прильщая его каким-нибудь узколобым псевдорешением.

anonymous
()

Для начинающего норм. Только вместо scanf заюзай хотя бы fgets, которой можно указывать максимальный размер строки.

anonymous
()
Ответ на: комментарий от tailgunner

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

anonymous
()
Ответ на: комментарий от int13h

Чем плох цикл на счетчиках?

да не слушай-ты его. Gcc уже лет десять сам лучше знает, как циклы делать. Не надо ему мешать. Пиши как пишешь.

Чем плохо использование const?

ничем. Чем-то даже хорошо.

Почему «плохо» объявлять (int i) переменную?

хорошо и Ъ. K&R так делают, а анон просто упорот.

emulek
()
Ответ на: комментарий от anonymous

я не «кодер» - я Царь, и я не пилю ненужного говна.

так бы сразу и сказал. Я думал ты кодер.

Ну извините, ваше высочество, или как у вас там принято...

emulek
()
Ответ на: комментарий от anonymous

И от моих подходов бомбит у 98% бомжей

я хоть и не бомж, но твои посты скрашивают мои серые будни, спасибо.

emulek
()
Ответ на: комментарий от anonymous

Прям в 2004 только научился?

начиная с 2004го(примерно) уже нет никакого смысла, КАК записывать цикл — gcc всё равно делает один и тот же асмовый выхлоп. Потому писать нужно понятно. А вот loop vs jpnz — это проблема компилятора, а не кодера.

emulek
()
Ответ на: комментарий от int13h

Почему «плохо» объявлять (int i) переменную?

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

anonymous
()
Ответ на: комментарий от int13h

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

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

Не надо искать себе снисхождений, оправданий, упрощений - это тупиковый путь.

1.Да, glibc «раздут», но что использовать?

Глибц нормальный - дело не в этом. Мне просто не нравится либцишные реализации работы с фалайми - эти стримы ужасны, эти сканф"ы. По мне так самопал+сискол лучшее решение.

2.Чем плохо использование const?

Оно не плохо - оно не имеет смысла. В сишке нет констант как в С++, т.е. написал глобально const int N = 5; - она не станет константой. Ты не можешь заюзать её дальше, допустим как int mas[N]; int D = N + 2;

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

2.Чем плох цикл на счетчиках? дополнительной операцией (счетчик) и ячейкой памяти?

Он выглядит как говно и он не нужен. Я вон выше писал:

char * strcpy_(char * from, char * to) {
  char * ret = to;
  while((from && to) && (*to++ = *from++));
  return ret;
}
Напиши мне это на счётчике. Привыкая писал на счётчиках ты обрекаешь себя писать говно в 95% случаев. Я тебе там раасказал, что в реальном мире у тебя будет не счётчик, а какие-то какой-то флаг конца - будь-то ошибка памяти, конец месаги, прерывание работы чем-то или кем-то.

Ну и да, счётчики тормазят.

3. Почему «плохо» объявлять (int i) переменную?

Ничем не плохо, просто в с99 есть сипипи-стайл for(int i = 0;;); Ну и да, счётчики на интах тоже не ок, как и сами счётчики.

Это лишнии строчки, а если тебе надо будет 2 цикла? Неудобно. Юзай фичи, которые делают код лучше.

anonymous
()
Ответ на: комментарий от anonymous

1.Да, glibc «раздут», но что использовать?

Глибц нормальный - дело не в этом. Мне просто не нравится либцишные реализации работы с фалайми - эти стримы ужасны, эти сканф"ы. По мне так самопал+сискол лучшее решение.

Этим решением мы привязываемся к платформе, не?

int13h ★★★★★
() автор топика
Ответ на: комментарий от emulek

да не слушай-ты его. Gcc уже лет десять сам лучше знает, как циклы делать. Не надо ему мешать. Пиши как пишешь.

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

Уничтожаем в хлам:

gcc-4.8.1 -Ofast -match=native -std=c99 -lgomp

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <omp.h>
#include <stdint.h>

char * strchr_shitstyle(char * begin, int len, char heedl) {
  for(int i = 0; i != len; ++i)
    if(begin[i] == heedl) return &begin[i];
  return NULL;
}

char * strchr_normstyle(char * begin, char * end, char heedl) {
  while(*begin != heedl && ++begin != end);
  return (begin == end) ? NULL : begin;
}


int main(void) {
  uintmax_t len = 1024ul*1024*32, count = 100;
  char * str = calloc(len, 1);
  memset(str, 'a', len - 1);
  {
  double start = omp_get_wtime();
  int i = count; uintptr_t acc = 0;
  do {
    acc += (uintptr_t)strchr_shitstyle(str, len, '\0');
  } while(--i);
  double end = omp_get_wtime();
  fprintf(stderr, "%llx, %fGB/s\n", acc, (((double)len/1024/1024/1024) * count)/(end - start));
  }
  
  
  {
  double start = omp_get_wtime();
  int i = count; uintptr_t acc = 0;
  do {
    acc += (uintptr_t)strchr_normstyle(str, (str + len), '\0');
  } while(--i);
  double end = omp_get_wtime();
  fprintf(stderr, "%llx, %fGB/s\n", acc, (((double)len/1024/1024/1024) * count)/(end - start));
  }
  
  
  {
  double start = omp_get_wtime();
  int i = count; uintptr_t acc = 0;
  do {
    acc += (uintptr_t)strchr(str, '\0');
  } while(--i);
  double end = omp_get_wtime();
  fprintf(stderr, "%llx, %fGB/s\n", acc, (((double)len/1024/1024/1024) * count)/(end - start));
  }
}

Пишу с говнотанка на 32битной бубунте. http://pastebin.com/nSRr0J4A

ничем. Чем-то даже хорошо.

Чем хорош, поясни мне, фекалоид.

хорошо и Ъ. K&R так делают, а анон просто упорот.

Ахаха, ну инфа 100. Я смотрю ты слишком много себе кукарекать позволяешь.

anonymous
()
Ответ на: комментарий от int13h

Этим решением мы привязываемся к платформе, не?

К софтварной платформе. Запомни одну вещь - сишка это труЪ язык для илитных вещей, если ты хочешь ваять прикладуху, чтобы она работала на маздайке и не замарачиватся - тебе к С++ и иже с ним.

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

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

anonymous
()
Ответ на: комментарий от emulek

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

Просто макаки типа тебя решили оправдать свою анскильность тем, что типа конпеляторы что-то умеют - на самом деле нет и ты просто балабол.

anonymous
()
Ответ на: комментарий от emulek

я хоть и не бомж

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

Мне жалко мою сишку, как вообще эта гниль может каким-то образом являтся частью её комьюнити. Уничтожся пж, и не позорь сишку - уйди к пхппистам.

Я вообще не понимаю с какого хрена ты, бомж, позволяешь себе так вести себя со мною? Ты реально не понимаешь где твоё место?

anonymous
()
Ответ на: комментарий от anonymous
>while((from && to) && (*to++ = *from++));
  return ret;
}


Напиши мне это на счётчике.

ты мудак. Glibc это сделает в разы быстрее.

Ну и да, счётчики тормазят.

ты 146% мудак.

Ничем не плохо, просто в с99 есть сипипи-стайл

и что, что оно «есть»? Оно замусоривает код, и снижает читаемость. Не очень ясна и очевидна область видимости int j. И даже если сверится со стандартом, то она не слишком удобна.

Это лишнии строчки

бери оплату построчно, дурачок (:

emulek
()
Ответ на: комментарий от int13h

По мне так самопал+сискол лучшее решение.

Этим решением мы привязываемся к платформе, не?

хуже. К конкретному варианту платформы — завтра оно поломается на новом RHEL. Хотя на старом УМВР.

emulek
()
Ответ на: комментарий от anonymous

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

Просто макаки типа тебя решили оправдать свою анскильность тем, что типа конпеляторы что-то умеют - на самом деле нет и ты просто балабол.

ты не просто мудак, ты феерический мудак...

emulek
()
Ответ на: комментарий от anonymous

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

Мне жалко мою сишку, как вообще эта гниль может каким-то образом являтся частью её комьюнити. Уничтожся пж, и не позорь сишку - уйди к пхппистам.

Я вообще не понимаю с какого хрена ты, бомж, позволяешь себе так вести себя со мною? Ты реально не понимаешь где твоё место?

придурок: ты себя смешал только-что с говном. Никого не интересует ПМЖ емулека. Давай ближе к теме, это у тебя получается действительно смешно.

emulek
()
Ответ на: комментарий от emulek

ты мудак. Glibc это сделает в разы быстрее.

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

Ах да, я делаю это быстрее глибц.

ты 146% мудак.

Выше по треду ты слит в говно.

и что, что оно «есть»? Оно замусоривает код, и снижает читаемость. Не очень ясна и очевидна область видимости int j. И даже если сверится со стандартом, то она не слишком удобна.

Область видимости int i for(тут){и тут} - это по определению. Замусоривает код только твои кривые рученки.

бери оплату построчно, дурачок (:

Тыж балаболил в прошлой цитатке про «замусоривание», а уже построчно - жалкая балаболка. Слита в говно, точека.

anonymous
()
Ответ на: комментарий от emulek

хуже. К конкретному варианту платформы — завтра оно поломается на новом RHEL. Хотя на старом УМВР.

Ахахах, ахахах. Какой же ты обсосок, какое отношение linux syscall api имеет к RHEL? Правильно - никакого. С таким же успехом сломается и glibc.

Только ты же балаболишь.

anonymous
()
Ответ на: комментарий от emulek

придурок: ты себя смешал только-что с говном. Никого не интересует ПМЖ емулека. Давай ближе к теме, это у тебя получается действительно смешно.

Ближе делу я тебя там выше поделил в говно. Ответь что-то поделу про своё балабольство.

anonymous
()
Ответ на: комментарий от emulek

Т.е. ответеть по существу тебе нечего? Т.е. ты слился в говно? И да, в отличии от тебя, ушлёпка нулёвого, я знаю что и когда юзать.

А теперь уже признай, что ты говно и мы разойдёмся на этом.

anonymous
()
Ответ на: комментарий от int13h

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

фантазёр...

Ах да, я делаю это быстрее глибц.

гы... Какие же всё дебилы. Кроме нашего Царя.

Выше по треду ты слит в говно.

в твоих фантазиях?

Тыж балаболил в прошлой цитатке про «замусоривание», а уже построчно - жалкая балаболка. Слита в говно, точека.

пробел и пустая строка — самый лучший комментарий. И в коротких строчках нет ничего плохого. Плохо, когда у тебя лапша вместо кода по типу base64.

emulek
()
Ответ на: комментарий от anonymous

Ахахах, ахахах. Какой же ты обсосок, какое отношение linux syscall api имеет к RHEL? Правильно - никакого. С таким же успехом сломается и glibc.

glibc «ломается» только у таких мудаков как ты. Которые не читают манов.

emulek
()
Ответ на: комментарий от anonymous

Т.е. ответеть по существу тебе нечего?

А что можно ответить мудаку, который доказывает отсутствие оптимизации выключив оптимизацию?

emulek
()
Ответ на: комментарий от anonymous

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

хочешь стать почётным клоуном ЛОРа? Учись. Пока наш Царь совсем с катушек не съехал...

emulek
()
Ответ на: комментарий от emulek

фантазёр...

Тебя ещё раз мокнуть в говно пастой?

гы... Какие же всё дебилы. Кроме нашего Царя.

Да, в частности ты - ты нихрена не понимаешь в теме, но позволяешь себе балаболить. Тебе напомнить эпичный фейл strstr(), который на i3-7 работал в 10раз медленней чем на коре2? До сих пор возможно не поправили.

И да, либц сливается в говно.

в твоих фантазиях?

В суровых реалиях.

пробел и пустая строка — самый лучший комментарий. И в коротких строчках нет ничего плохого. Плохо, когда у тебя лапша вместо кода по типу base64.

Причем короткие строчки? Это не короткие - это лишние строчки, много лишних строчек. Но ты обсосок юлишь.

anonymous
()
Ответ на: комментарий от emulek

glibc «ломается» только у таких мудаков как ты. Которые не читают манов.

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

Тебе это ясно? Ты мне так и не ответил как связанно Linux syscall api и RHEL?

anonymous
()
Ответ на: комментарий от emulek

А что можно ответить мудаку, который доказывает отсутствие оптимизации выключив оптимизацию?

Ну это эпичность, это просто эпичность.

-Ofast
Disregard strict standards compliance. -Ofast enables all -O3 optimizations. It also enables optimizations that are not valid for all standard-compliant programs. It turns on -ffast-math and the Fortran-specific -fno-protect-parens and -fstack-arrays.
-O3
Optimize yet more. -O3 turns on all optimizations specified by -O2

Т.е. по логике ущербана -Ofast это вырубленная оптимизация, когда как -O2 врубленная, хотя -O2 входит -O3, а -O3 входит в -Ofast.

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

anonymous
()
Ответ на: комментарий от anonymous

Тебе это ясно? Ты мне так и не ответил как связанно Linux syscall api и RHEL?

задолбал ты со своим мудачеством. Если в RHEL поменяют сисколы, то поменяют и glibc, потому она не ляжет. А вот твой говнокод — ляжет. Потому-что аффтор у него такой.

emulek
()
Ответ на: комментарий от anonymous

причем даже этот простой случай гцц не заменя

вот раз не заменяет, значит он быстрее так как есть. А твой код — медленнее. А если твой код быстрее, значит ты не тот процессор поставил, или ещё как-то намудачил. Как именно — мне в лом разбираться.

emulek
()
Ответ на: комментарий от emulek

задолбал ты со своим мудачеством.

100%.

Если в RHEL поменяют сисколы

В RHEL не менют сисколы, это так для справки. Если они поменяют сисколы - отвалится всё. Начиная от кореутился, заканчивая твоим говновебом.

Сисколы - это прираготива линукс-ядра, причем почти все они стандартные SVr4, 4.3BSD, POSIX.1-2001. Никто в здравом уме их не буедт менять, так же как и либц - это твоя жалкая фантазия.

то поменяют и glibc, потому она не ляжет.

А так же пропатчат половину пакетов - инфа сотка. Ты такая тупая, это просто жуть.

Потому-что аффтор у него такой.

Ты реально идиот. Т.е. в RHEL поменяют стандартное для бзд, линукса, посикса syscall file api на что-то ещё? Ну да, да. Уйди пожалуста, ты несёшь такую херню - это просто жуть.

anonymous
()
Ответ на: комментарий от emulek

вот раз не заменяет, значит он быстрее так как есть.

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

А твой код — медленнее.

Быстрее по определению, да и реально.

А если твой код быстрее

Итак быстрее.

значит ты не тот процессор поставил

-march=native и да, это не влияет ниначто.

или ещё как-то намудачил

Как? Ну собери нормально - покажи как будет «нормально» - я поржу.

Как именно — мне в лом разбираться.

Ты слился, ты не можешь объяснить, ты не можешь аргументировать. Тебе не влом - ты не можешь.

Пробалаболил.

anonymous
()
Ответ на: комментарий от anonymous

Тебе не влом - ты не можешь.

согласен. Болезнь Дауна неизлечимо. Дефект хромосом не выправить ликбезом на ЛОРе, потому — засчитывай слив.

emulek
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.