Как записать в short два char'a в верхний и нижний байт?

#short#=#char#; //нижний байт

#short#=#char#; << 8 //верхний байт

Вроде так, на си давно не писал

Точка с запятой должна быть после 8-ки, опечатка.

uint16_t var = highbyte << 8 + lowbyte;

</thread>

http://www.intuit.ru/department/pl/cpp/3/3.html

Да, я обманул с приоритетом :)

Да, приоритет не соблюдается, правильно так:

uint16_t var = (highbyte << 8) + lowbyte;

Все получилось, спасибо.

А чем плох union?

>А чем плох union?

(Не считая многословности)

> uint16_t var = (highbyte << 8) + lowbyte;

Вместо '+' лучше писать '|' - чтобы было видно, что ты месишь биты.

>Вместо '+' лучше писать '|'

Интересно, gcc одинаковым образом откомпилирует код?

> А чем плох union?

struct { char low, high; } или struct { char high, low; } ? А если вдруг компилятору приспичит выравнивать чары не по байтам, а по два байта, скажем?

>>Вместо '+' лучше писать '|'

>Интересно, gcc одинаковым образом откомпилирует код?

По-разному (4.3.3). Причём под i386 + превращается в add, а | - в or и общее количество операций одинаковое. А под x86_64 + делается через lea и получается на одну операцию короче...

((char*)dest)[0] = high; ((char*)dest)[1] = low;

Руки за такое надо отрывать.

>struct { char low, high; } или struct { char high, low; } ?

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

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

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

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

А еще он может прикола ради заменить << на >>.

>Да, приоритет не соблюдается, правильно так:

>uint16_t var = (highbyte << 8) + lowbyte;

В данном случае разницы нет, но _идеологически_ правильнее так:

(highbyte << 8) | lowbyte;

>Интересно, gcc одинаковым образом откомпилирует код?

По идее, в первом случае будет add, во втором - or.

>((char*)dest)[0] = high; ((char*)dest)[1] = low;

Здравствуйте, взращённые x86 платформой! :)

На PDP, например, ты на этом словишь аппаратное исключение.

>>((char*)dest)[0] = high; ((char*)dest)[1] = low;

>На PDP, например, ты на этом словишь аппаратное исключение.

С чего бы?

> ((char*)dest)[0] = high; ((char*)dest)[1] = low;

В http://gcc.gnu.org/bugs.html#nonbugs в секции про C написано что так нельзя.

>С чего бы?

Доступ по нечётным адресам - ошибка.

> Доступ по нечётным адресам - ошибка.

На PDP-11? Держите меня трое :D

Пардон, склероз. Это доступ к команде по нечётному адресу - ошибка.

...

Хотя, боюсь (точно уже не помню, давно было), на PDP sizeof(char) всё равно равен двум. Так что нужного эффекта автор кода всё равно не получит :)

> Хотя, боюсь (точно уже не помню, давно было), на PDP sizeof(char) всё равно равен двум

Нет. PDP-11 - очень традиционная машина. Экзотикой была PDP-10.

>на PDP sizeof(char) всё равно равен двум.

В ANSI C89 sizeof(char) всегда равен одному.

short dest;
char src[2];
memcpy(&dest,src,2);

?

>В ANSI C89 sizeof(char) всегда равен одному.

Ну, ты понял, что я имел в виду. Речь о том, что char там - два байта.

short dest;
char src[2];
memcpy(&dest,src,2);

А если little endian?

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

> А еще он может прикола ради заменить << на >>.

Компиляторы - тоже люди и они тоже умеют шутить :)

>Здравствуйте, взращённые x86 платформой! :)

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

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

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

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

Так неинтересно. Надо ж пальцы погнуть!

> А если little endian?

#ifdef FLAG
src[0]=0;
src[1]=1;
#else
src[0]=1;
src[1]=0;
#endif

?

>Здравствуйте, взращённые x86 платформой!

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

> #ifdef FLAG
> src[0]=0;
> src[1]=1;
> #else
> src[0]=1;
> src[1]=0;
> #endif

самому то нравится такой код? :)

Нет. Костыль, конечно.

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

>В начальном вопросе топикстартера не оговаривался порядок расположения байт в приёмнике.

Именно. Поэтому вариант с «s = (hb << 8) | lb» формально корректный, а вариант с memset - нет.

Я уже не говорю про то, что в варианте с присваиванием переменная может сохраниться в регистре, что положительно скажется на оптимизации.

Песец, сколько перлов в треде. Как страшно жить...

>>Песец, сколько перлов в треде. Как страшно жить...

вопрос только в том - а НАФИГА? ;-) память экономим?

> Да, приоритет не соблюдается, правильно так:
> uint16_t var = (highbyte << 8) + lowbyte;
> Все получилось, спасибо.

А вот что по этому рецепту получилось у меня:

$ cat a.cpp
#include <stdio.h>
int main() {
char high = 0x55;
char low = 0x88;
short result = (high << 8) | low;
return !printf("result = %x\n", 0xffff & result);
}
$ g++ ./a.cpp
$ ./a.out
result = ff88

А вовсе не 5588.

Действительно, что ни рецепт - то пёрл.

> Ну да, на big-endian системах все наоборот, только программист обычно знает под какую систему пишет. На крайняк можно по ifdef 2 варианта поставить. А код можно просто скомпилять и в дебаггере посмотреть работает или нет - чем флейм разводить.

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

мать вашу! програмёры, блин!

char -- в данном случае -- 8 bit. посему и high << 8 == 0, всегда!

а вот если заменить char на int или short -- то и будет вам щастье.

Гы, а пёрлов всё больше ;-)

>мать вашу! програмёры, блин!
>char -- в данном случае -- 8 bit. посему и high << 8 == 0, всегда!

#include <stdio.h>
int main() {
char high = 0x55;
printf ("%s\n", high << 8 == 0 ? "programmers blin" : "epic fail");
return 0;
}

#include <stdio.h>
int main() {
char high = 0x55;
printf("%s\n", (char)(high << 8) == 0 ? "programmers blin" : "epic fail");
return 0;
}

Ы?

в общем, alexsaa, не позорься. в printf у тебя вышло неявное приведении типов к int, который является в сях типом по умолчанию.

> high << 8 == 0, всегда!
> (char)(high << 8) == 0
> в общем, alexsaa, не позорься

:)

high у нас char или где? и с чем же ты тут не согласен?

я не согласен с тем, что "(high << 8) == 0" и "((char)(high << 8)) == 0" - одно и то же. /* Необязательные скобки я здесь расставил для ясности. */