GTK: int и void*

>где дальний указатель 32 бита

эммм, не вижу связи... можно сделать саааавсем дальний указатель в 128 бит. но регистры как были в 16 бит, так и остались

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

ды хоть 128 хоть 256

Я про то, что между int и void* не существует взаимнооднозначного преобразования.

А про гтк - я ж говорю, что я его не знаю. поэтому и спрашиваю. мож там это как-то обошли.....

а ты приведи пример все-таки, тогда и обсудим.

Если это в glib - то нормально - glib должна предоставлять переносимый API - а то как она реализована - вопрос отдельный и #ifdef'ы всякие никто еще не отменял.

Хе-хе, вы ведь можете преобразовать char в int, а ведь char - это 8 бит, а int(на х86 >= i386) 32 бита. Тогда посему Вас долюно удивлять преобразование void* в int. Другое дело, что при этом может теряться старшее слово(или младшее - опять же в зависимости от архитектуры).

ПС У 8086 дальний указатель 20 бит:) У 80268 - уже 24 бита. ППС Длина указателя и шина адреса не связаны между собой, у PPro ША - 36 бит, а укзатель всё равно 32 бит.

Ну если уж на то пошло - 386 процессор уже мог адресовать 2 в 46 степени байт. и шина адреса была 46 разрядной. (+2 бита на права доступа к сегменту == 48 == 32-смещение + 16сегмент)

Но я хотел бы услышать мнение тех, кто разбирается в GTK. Может кто расскажет как оно там устроено?

Зы - а ведь есть архитектуры у которых шина данных шире чем шина адреса....

>> ПС У 8086 дальний указатель 20 бит:)

sizeof(far void*) = 4байта (32 бита) (я уж забыл как там правильно пишется дальний указатель...), а не колво проводков....

а 20 - это шина адреса, а не дальний указатель

Sergej RTFM!!!!! http://iakovlev.org/index.html?p=8801&m=1&l1=7 К примеру. У i386 Сегментных регистров нет, вернее они являются селекторами. Так что не говорите глупостей...
ПС
#include <stdlib.h>
#include <stdio.h>
int main(void){
void *k=(void*)1234;
int p = (int)k;
printf("p=%d k=%d\n",p,k);
return 0;
}
ППС Такая архитекруа, к примеру почти во всех 8-ми битных микроконтроллерах, к примеру Atmel Avr

У Вас есть до сих 8086? В реальном режиме можете проверить, что длинный указатель - 20 бит

Разрядность дальнего(это только в сегментной модели, в плоской не надо е*аться с сегментами:)) указатель уж точно не может быть больше шины адреса.

>> Sergej RTFM!!!!! http://iakovlev.org/index.html?p=8801&m=1&l1=7 К примеру. У i386 Сегментных регистров нет, вернее они являются селекторами. Так что не говорите глупостей...

Сегмент-селектор - мне в данный момент пофиг. я знаю что 386 адресует 2 в 46 степени байт. Тем более что селектор указывает на информацию о сегменте - один хрен.

>> У Вас есть до сих 8086? В реальном режиме можете проверить, что длинный указатель - 20 бит

У меня есть Borland C и DOS и я вижу что sizeof == 4 байта.

А про избыточность адреса и про то, что шина адреса 20бит я в курсе

Узнаю ЛОР. по теме кто-нить выскажется или нет?

Нашел в архиве maillist'а похожий вопрос.

Ответили товарищу хорошо - примерно так: ну мы пока еще не видели 32битной системы на которой sizeof(int)>sizeof(void*). Ну и пока пусть так все и работает, а там подумаем...

Ну и фиг с ними, что тут еще сказать...

по теме никто не выскажется, пока ты конкретно не сформулируешь вопрос.

>Я не шарю в GTK

но смело судим

>Увидел что там есть преобразования указателей в целые и обратно. (точнее это наверное glib)

где конкретно? нету там такого. библиотека компилится под разные платформы по-разному. поэтому всякие int8, int16, int64, gpointer... _работают_ одинаково. как это реализовано, тебе уже говорили.

для не знающих гтк рассказываю: в нём нету int, void* ;) там есть gint, gpointer и др. метарадоти, которые определяются во время компиляции. int и void*, если мне не изменяет память, - типы в Сях. :)

И вообще вопрос был (точнее его не было) некорректен. Если нужно число, использую инт, если указатель - воид. Всё.

ЗЫ. Троллингом попахивает

>> >Увидел что там есть преобразования указателей в целые и обратно. (точнее это наверное glib)

>> где конкретно? нету там такого.

например макрос GPOINTER_TO_INT()

>> ЗЫ. Троллингом попахивает

Нет, не попахивает.

Я увидел макрос GPOINTER_TO_INT() который реализован как (gint)x и определиния gint через int и gpointer через void*. Меня это сильно удивило и я спросил "Может быть это все там как-то хитро реализовано?"

Другой вопрос был - "Что кто думает о приведении int к void* и обратно"

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

Ответ про хитрую реализацию я нашел. Это никак не реализовано. Они надеются на то, что не встретят такую платформу, на которой это не будет работать. А если встретят будут просто все это переделывать.

А мнения о корректности преобразований между int и void* я готов выслушать - интересно...

>> >Я не шарю в GTK

>> но смело судим

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

так вот терь ясно, а то попёрли в процессорные дебри...

http://developer.gnome.org/doc/API/2.0/glib/glib-Type-Conversion-Macros.html#...

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

>Я увидел макрос GPOINTER_TO_INT() который реализован как (gint)x

на amd64 #define GPOINTER_TO_INT(p) ((glong) (p)), что не одивительно - битность соблюдена

>Они надеются на то, что не встретят такую платформу, на которой это не будет работать. А если встретят будут просто все это переделывать.

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

Ну хоть в документацию отмаз включили и то радует.

У меня вот такой вариант доки скачаный - такой же как здесь -> http://www.cs.tut.fi/lintula/manual/gtk/glib/glib-type-conversion-macros.html

Наверное после письма того товарища с дековской альфой отмаз и включили...

Ну тогда наверное уже все вопросы снимаются. Гткшники сознались, что так делать нехорошо, но править они не хотят, потому что придется менять API...

ЗЫ - всем пасиба...

Сотру всю скачаную доку - буду читать наисвежайшие первоисточники)

>Гткшники сознались, что так делать нехорошо, но править они не хотят, потому что придется менять API...

Ты не забудь, что гтк себя так же позиционирует как мощная основа для биндингов и было бы глупо ограничивать пользователей (хоть они и ССЗБ) творить чёрти что рамками синтаксиса/семнтики конкретного языка (как это сделали Кути).

> например макрос GPOINTER_TO_INT()

ну и как еще ты предлагаешь этот макрос реализовать? ./configure определит нужный тип при сборке.

Я предлагаю даже не пытаться хранить int внутри void*. и наоборот.

Я просто противник идеи использовать void* как "супертип" в который можно запихать все что угодно.

Ну если нужен такой тип - сделали бы какой-нибудь

typedef long long supertype;

или

typedef char supertype[16];

и в него бы все пихали макросами или функциями. А то привыкли, что void* самый вместительный из простых типов на большинстве платформ...

Это не совсем корректно, но это работает, причем работает быстро. Примерно та же идея используется в Ruby:

#if SIZEOF_LONG != SIZEOF_VOIDP
# error ---->> ruby requires sizeof(void*) == sizeof(long) to be compiled. <<----
#else
typedef unsigned long VALUE;
typedef unsigned long ID;
#endif

#define FIXNUM_MIN RSHIFT((long)LONG_MIN,1)

#define FIXNUM_FLAG 0x01
#define INT2FIX(i) ((VALUE)(((long)(i))<<1 | FIXNUM_FLAG))
#define LONG2FIX(i) INT2FIX(i)
#define rb_fix_new(v) INT2FIX(v)
VALUE rb_int2inum _((long));
#define INT2NUM(v) rb_int2inum(v)
#define LONG2NUM(v) INT2NUM(v)
#define rb_int_new(v) rb_int2inum(v)
VALUE rb_uint2inum _((unsigned long));
#define UINT2NUM(v) rb_uint2inum(v)
#define ULONG2NUM(v) UINT2NUM(v)
#define rb_uint_new(v) rb_uint2inum(v)