The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Оптимизация кода компилятором может привести к появлению про..., opennews (?), 30-Окт-13, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


16. "Оптимизация кода компилятором может привести к появлению про..."  +2 +/–
Сообщение от Xasd (ok), 30-Окт-13, 13:14 
> Если в стандарте языка указано, что результат операции переполнения не определен, то нет ничего криминального в том, что компиляторы этим пользуются.

верно..

какого чёрта -- программист такой "умный" что уже ПОСЛЕ того как СОВЕРШИТ переполнение проверяет "а не случилось ли переполнение?"..

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

нет чтобы проверить каждое из гипотетических слогаемых -- ПЕРЕД всякими операциями..


#include <climits>
... ...
if (buf >= INT_MAX/2 || len >= INT_MAX/2) {
    return; // overflow
}
... ...

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

18. "Оптимизация кода компилятором может привести к появлению про..."  +4 +/–
Сообщение от Аноним (-), 30-Окт-13, 13:23 
> buf >= INT_MAX/2 || len >= INT_MAX/2

По-моему, это еще более страшный быдлoкод.

Ответить | Правка | Наверх | Cообщить модератору

21. "Оптимизация кода компилятором может привести к появлению про..."  –1 +/–
Сообщение от Xasd (ok), 30-Окт-13, 13:28 
>> buf >= INT_MAX/2 || len >= INT_MAX/2
> По-моему, это еще более страшный быдлoкод.

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

Ответить | Правка | Наверх | Cообщить модератору

29. "Оптимизация кода компилятором может привести к появлению про..."  –2 +/–
Сообщение от Аноним (-), 30-Окт-13, 13:40 
> где ты тут код увидил? тут лишь одно выражение, которое проверяет что
> каждое из слагаемых меньше чем половина от максимального значения обычного целочесленного
> типа..

Да-да, скажи ещё что кот по клавиатуре прошёл и оно само напечаталось.

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

Ответить | Правка | Наверх | Cообщить модератору

31. "Оптимизация кода компилятором может привести к появлению про..."  –1 +/–
Сообщение от Аноним (-), 30-Окт-13, 13:41 
> Плюс хамская манера общения

Хамская манера общения тут только у тебя (хотя я и использовал слово "быдлoкод" парой сообщений выше).

Ответить | Правка | Наверх | Cообщить модератору

37. "Оптимизация кода компилятором может привести к появлению про..."  +1 +/–
Сообщение от Аноним (-), 30-Окт-13, 13:45 
> Хамская манера общения тут только у тебя (хотя я и использовал слово
> "быдлoкод" парой сообщений выше).

Залогинься, Xasd. Щас прям, поверю что пришёл компетентный Аноним тебя защищать.

Ответить | Правка | Наверх | Cообщить модератору

50. "Оптимизация кода компилятором может привести к появлению про..."  –1 +/–
Сообщение от Аноним (-), 30-Окт-13, 14:15 
Ну ты же знаешь, что комент про быдлoкод писал не ты? :)
Ответить | Правка | Наверх | Cообщить модератору

20. "Оптимизация кода компилятором может привести к появлению про..."  +2 +/–
Сообщение от Аноним (-), 30-Окт-13, 13:25 
За такой код надо тебе по пальцам молотком для мяса пройтись.
Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

23. "Оптимизация кода компилятором может привести к появлению про..."  –2 +/–
Сообщение от Xasd (ok), 30-Окт-13, 13:28 
> За такой код надо тебе по пальцам молотком для мяса пройтись.

ну напиши как надо. балобол.

так как ты писать ни чего не будешь -- то разговор я думаю на этом будет закрыт.

> молотком для мяса

тоже мне, любитель мяса..

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

Ответить | Правка | Наверх | Cообщить модератору

25. "Оптимизация кода компилятором может привести к появлению про..."  +1 +/–
Сообщение от Аноним (-), 30-Окт-13, 13:35 
Лол, как тебя зацепило. Нет уж - давай ты свои ошибки сам исправишь. Подскажу: во-первых, buf это указатель, а указатель с INT ничего общего не имеет. Во-вторых, указатель может располагаться в любой половине адресного пространства (в userspace будет в одной, в ядре - в другой), так что в одном случае твой код гарантированно не будет работать.
Ответить | Правка | Наверх | Cообщить модератору

33. "Оптимизация кода компилятором может привести к появлению про..."  –4 +/–
Сообщение от Xasd (ok), 30-Окт-13, 13:43 
> buf это указатель

да -- я привёл код который просто проверяет переполнение при сложении.

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

(и вообще я считаю что нет смысла складывать указатели и работать с указателями -- как с целыми числами)

вот именно в этом смысле я принимаю критику.

Ответить | Правка | Наверх | Cообщить модератору

41. "Оптимизация кода компилятором может привести к появлению про..."  +2 +/–
Сообщение от Аноним (-), 30-Окт-13, 13:49 
Оправдываться уже поздно, молодой человек. С вами всё понятно.
Ответить | Правка | Наверх | Cообщить модератору

45. "Оптимизация кода компилятором может привести к появлению про..."  –3 +/–
Сообщение от Xasd (ok), 30-Окт-13, 13:57 
> Оправдываться уже поздно, молодой человек. С вами всё понятно.

ну слово не воробей. если уж я написал свою точку зрения -- назад взять слова не могу :-) ..

да -- я считаю что работать с указателями как с числами -- это плохо. и что это источник ошибок..

что уж тут теперь :-) -- что есть то есть

Ответить | Правка | Наверх | Cообщить модератору

177. "Оптимизация кода компилятором может привести к появлению про..."  +/–
Сообщение от Аноним (-), 30-Окт-13, 22:32 
> да -- я считаю что работать с указателями как с числами --
> это плохо. и что это источник ошибок..

Это совершенно нормально. По другому запускать код находящийся в known локации или парсить структуры в новой локации иначе было бы зело геморно. Не менее геморно было бы работать с mmaped устройсвами и прочая.

Ответить | Правка | Наверх | Cообщить модератору

69. "Оптимизация кода компилятором может привести к появлению про..."  +/–
Сообщение от ананим (?), 30-Окт-13, 14:51 
>Лол, как тебя зацепило.

Именно что ЛОЛ. Обозвал человека, докажи что заслуженно. А пока только эти эпитеты — xам и провокация флэйма.
зыж
2Xasd:
1.|| не подходит вообще, т.к. по стандарту (даже без оптимизации) если значения первого операнда достаточно, чтобы определить результат операции, то второй операнд не вычисляется. Вот с && другая история.
2. ситуация, когда указатель чуть меньше INT_MAX(? понятно, что в контексте имеется ввиду максимальное значение для указателя, см. ниже), а длина маленькая (или наоборот) вполне валидны.
3.$ cat 111.c
#include <stdio.h>
main() {
    printf("pointer - %li\nunsigned int - %li\nint - %li\nchar - %li\nlong - %li\n",
    sizeof(char *),sizeof(unsigned int),sizeof(int),sizeof(char),sizeof(long));
}
$ gcc 111.c
$ ./a.out
pointer - 8
unsigned int - 4
int - 4
char - 1
long - 8
(логично, что на 64-битной платформе указатель равен 64 бита, не так ли?)
4. Очевидно вычитание вам поможет. Примерно так (ULONG_MAX - buf) > len, т.к. это условие должно выполнятся.

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

78. "Оптимизация кода компилятором может привести к появлению про..."  –1 +/–
Сообщение от Xasd (ok), 30-Окт-13, 15:10 
да да, разумеется ``(ULONG_MAX - buf) > len`` здесь конечно явно уместнее) .. говоря про указатели -- точно уж не то что я привёл выше :-D

кстате мы тут исходим из того что размер size_t и long -- одинаковые... ведь не существует константы SIZE_T_MAX .. верно?

Ответить | Правка | Наверх | Cообщить модератору

83. "Оптимизация кода компилятором может привести к появлению про..."  +/–
Сообщение от ананим (?), 30-Окт-13, 15:33 
$ cat 222.c
#include <stdio.h>
main() {
    size_t l = ~0; // можно с модификаторами, тоже работает size_t l = ~0ull;
    printf ("%lx\n", l);
}
$ gcc 222.c
$ ./a.out
ffffffffffffffff
> ведь не существует константы SIZE_T_MAX .. верно?

ну… оно менятся от платформе к платформе, но… имеется :D
<stdint.h>
/* Limit of `size_t' type.  */
# if __WORDSIZE == 64
#  define SIZE_MAX              (18446744073709551615UL)
# else
#  define SIZE_MAX              (4294967295U)
# endif

Ответить | Правка | Наверх | Cообщить модератору

91. "Оптимизация кода компилятором может привести к появлению про..."  +2 +/–
Сообщение от pavlinux (ok), 30-Окт-13, 16:01 
> /* Limit of `size_t' type.  */

Так не интересно, это читерство. :-P

Ответить | Правка | Наверх | Cообщить модератору

95. "Оптимизация кода компилятором может привести к появлению про..."  +/–
Сообщение от ананим (?), 30-Окт-13, 16:07 
Кстати согласен.
Такие вещи должны определятся на целевой платформе... но константа не требует вычислений! :D

Зыж
А хреневознает, может этот файл генерится при установке? ;)

Ответить | Правка | Наверх | Cообщить модератору

173. "Оптимизация кода компилятором может привести к появлению про..."  +/–
Сообщение от pavlinux (ok), 30-Окт-13, 22:17 
> А хреневознает, может этот файл генерится при установке? ;)

Какой, <stdint.h> ?  Не, он феншуйный - ISO/IEEE ля-ля-ля:1999

Ответить | Правка | Наверх | Cообщить модератору

89. "Оптимизация кода компилятором может привести к появлению про..."  +/–
Сообщение от pavlinux (ok), 30-Окт-13, 15:57 
> ведь не существует константы SIZE_T_MAX .. верно?

#define SIZE_T_MAX  ((2UL << (sizeof(size_t) * 8) - 1) - 1)

как вариант

#define SIZE_T_MAX  ((2UL << __WORDSIZE - 1) - 1)
#define SIZE_T_MAX  ((2UL << __BITS_PER_LONG - 1) - 1) // эта круче, звучит красиво : 2уль вжить-вжить битсперлонг :)  

Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

30. "Оптимизация кода компилятором может привести к появлению про..."  +1 +/–
Сообщение от Аноним (-), 30-Окт-13, 13:40 
> слогаемых

По русскому у тебя то-же что и по информатике?

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

39. "Оптимизация кода компилятором может привести к появлению про..."  +/–
Сообщение от Xasd (ok), 30-Окт-13, 13:47 
>> слогаемых
> По русскому у тебя то-же что и по информатике?

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

может про физкультуру ещё интересно узнать? :-)

по физкультуре было обычно 4

Ответить | Правка | Наверх | Cообщить модератору

46. "Оптимизация кода компилятором может привести к появлению про..."  +2 +/–
Сообщение от тоже Анонимemail (ok), 30-Окт-13, 14:03 
А информатики еще не было вовсе, мы поняли.
Бросьте позориться. Вы написали безграмотное программистское решение с безграмотными русскими комментариями, да еще и раздуваете личностный срач.
Увы, "никогда не выдается второго случая создать первое впечатление".
Ответить | Правка | Наверх | Cообщить модератору

49. "Оптимизация кода компилятором может привести к появлению про..."  –2 +/–
Сообщение от Xasd (ok), 30-Окт-13, 14:12 
> А информатики еще не было вовсе, мы поняли.

была.

у нас даже были там в классе -- немножко компьютеров :) ..

но при чём тут вообще школа-то?

> Бросьте позориться. Вы написали безграмотное программистское решение с безграмотными
> русскими комментариями,

безграмотное -- только лишь для случая с указателями.

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

> да еще и раздуваете личностный срач.

ну тыг возьми да и поудаляй его!

ой.. я забыл -- ты ведь всего-лишь аноним, без каких-либо прав :-D ..

> Увы, "никогда не выдается второго случая создать первое впечатление".

проблема века :-D

ну давай, пиши ещё.. опазорь как-нибудь меня совсем уж! всем же так интересно :-) ...все бросили свою работу, и бегом бегут на ОпенНет читать как один аноним троллит другого анонима... :-)

Ответить | Правка | Наверх | Cообщить модератору

55. "Оптимизация кода компилятором может привести к появлению про..."  +/–
Сообщение от тоже Анонимemail (ok), 30-Окт-13, 14:22 
То, что вы невнимательны, было заметно и до этого комментария.
Работать с числами, большими половины максимума, вы тоже не видите смысла?
Ответить | Правка | Наверх | Cообщить модератору

60. "Оптимизация кода компилятором может привести к появлению про..."  –2 +/–
Сообщение от Xasd (ok), 30-Окт-13, 14:40 
> Работать с числами, большими половины максимума, вы тоже не видите смысла?

да, конечно.

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

я вообще не люблю числа, которые граничат со своими "возможностями".. не люблю граничные значения..

> То, что вы невнимательны, было заметно и до этого комментария.

хорошо.. я буду стараться быть повнимательнее :)

Ответить | Правка | Наверх | Cообщить модератору

168. "Оптимизация кода компилятором может привести к появлению про..."  +4 +/–
Сообщение от Аноним (-), 30-Окт-13, 21:33 
> четвердь

Очень жаль что тебе не вкатили двойку в "четверди" по русскому языку. Ты этого не только заслуживаешь, но и взялся бы немного за ум. А так получился папуас, который даже немного претендует на то что умеет погонщиком слонов быть.

Ответить | Правка | Наверх | Cообщить модератору

331. "Оптимизация кода компилятором может привести к появлению про..."  –1 +/–
Сообщение от Xasd (ok), 03-Ноя-13, 00:50 
> Очень жаль что тебе не вкатили двойку в "четверди" по русскому языку.

с чего ты взял что такого не случалось?

как раз такое бывало :-) ..

всё равно не понимаю почему моя школьная биография так интересна. обычная школьная биография

Ответить | Правка | Наверх | Cообщить модератору

332. "Оптимизация кода компилятором может привести к появлению..."  +1 +/–
Сообщение от arisu (ok), 03-Ноя-13, 01:54 
> с чего ты взял что такого не случалось?
> как раз такое бывало :-) ..

причём постоянно, судя по твоим текстам.

Ответить | Правка | Наверх | Cообщить модератору

334. "Оптимизация кода компилятором может привести к появлению про..."  +1 +/–
Сообщение от Led (ok), 03-Ноя-13, 03:53 
>> Очень жаль что тебе не вкатили двойку в "четверди" по русскому языку.
> с чего ты взял что такого не случалось?
> как раз такое бывало :-) ..

И ещё будет

Ответить | Правка | К родителю #331 | Наверх | Cообщить модератору

202. "Оптимизация кода компилятором может привести к появлению..."  –2 +/–
Сообщение от arisu (ok), 31-Окт-13, 08:49 
> опазорь как-нибудь меня совсем уж!

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

Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

77. "Оптимизация кода компилятором может привести к появлению про..."  +/–
Сообщение от ... (?), 30-Окт-13, 15:03 
Подобные проверки перед каждой арифметической операцией негативно повлияют как на производительность так и на читаемость кода.
Да и писать такой код, держа в голове кто unsigned, кто long, а кто вообще double и какую проверку в связи с этим нужно влепить, - не особо комфортно.
Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

99. "Оптимизация кода компилятором может привести к появлению про..."  –1 +/–
Сообщение от ананим (?), 30-Окт-13, 16:25 
А для этого есть венгерская нотация и тд.
Опять же, имеет смысл для глобальных (или в нэймспейсах) переменных.
Для локальных переменных избяточно.
Ответить | Правка | Наверх | Cообщить модератору

203. "Оптимизация кода компилятором может привести к появлению..."  +/–
Сообщение от arisu (ok), 31-Окт-13, 08:56 
> А для этого есть венгерская нотация

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

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

cntItems — нормально, если в проекте принято, что «cnt» — это префикс для обозначения счётчика.
dwItemCount — ненормально, что бы там в проекте ни принимали. привет, проблемы с портируемостью, например: «по средам и субботам dw обозначает два байта, по четвергам — четыре, а в пятницу бывает восемь, если это чётный день года.»

Ответить | Правка | Наверх | Cообщить модератору

214. "Оптимизация кода компилятором может привести к появлению..."  +/–
Сообщение от ананим (?), 31-Окт-13, 13:06 
>например: «по средам и субботам dw обозначает

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

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

Ответить | Правка | Наверх | Cообщить модератору

201. "Оптимизация кода компилятором может привести к появлению..."  +1 +/–
Сообщение от arisu (ok), 31-Окт-13, 08:46 
> какого чёрта — программист такой «умный» что уже ПОСЛЕ того как СОВЕРШИТ
> переполнение проверяет «а не случилось ли переполнение?»..

прикинь, процессор тоже делает именно так. сюрпрайз, да?

а то, что си заставляет вместо элегантной проверки на установленый carry flag постфактум городить портянки типа вышеприведённой — это недостаток стандарта.

кстати: а нагороди-ка такую портянку на выражение типа такого: 'a+(b*c)/d-e+f*g', а?

ну да, ну да: у нас же машины правят миром, поэтому работу, которую может выполнить машина, на самом деле должен выполнять человек: городить кучу дурацких ручных проверок, разбивая выражение на куски (представим, кстати, что в этом выражении некоторые члены — не переменные, а вызовы функций). при том, что процессор заботливо устанавливает флажок переноса, позволяющий обойтись чем-то вроде 'guard_carry(expr) { fail-processing-code }'. тьфу.

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

321. "Оптимизация кода компилятором может привести к появлению..."  +/–
Сообщение от Аноним (-), 02-Ноя-13, 10:04 
> прикинь, процессор тоже делает именно так. сюрпрайз, да?

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

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру