LINUX.ORG.RU
Форум — Development  

Комитет не может остановиться..

 , ,


0

3

Привет, ЛОР!

Я просто оставлю это здесь: https://isocpp.org/files/papers/P2996R4.html

Для Ъ: в C++26 будет добавлена поддержка статической рефлексии. Теперь C++ будет компилироваться ЕЩЁ ДОЛЬШЕ.

← Шрифты с отличающейся кириллицей
Почему проигрывание медиа в Chromium такое дерьмовое? →

  1 2 3 4 5 6
Ответ на: комментарий от zx_gamer

Как офигительно. А теперь допиши, скомпилируй одно для big-endian, а второе на little-endian машине и убедись, что данные не будут переданы корректно.

И убедись что данные будут сконвертированы в be, ты хотел сказать? Ну, да. Для этого эти функции и нужны :DDDD

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

Ахахаа, смотри, а ядро с тобой не согласно:

	sb->raid_disks = cpu_to_le32(mddev->raid_disks);
	sb->size = cpu_to_le64(mddev->dev_sectors);
	sb->chunksize = cpu_to_le32(mddev->chunk_sectors);
	sb->level = cpu_to_le32(mddev->level);
	sb->layout = cpu_to_le32(mddev->layout);

КАК ЖЕ ТАК-ТО А.

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

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

Это запись суперблока рейда. Который в диск пишется. Который потом могут прочитать на другом компе с другим процом. Серьезно, ты нас обманул и C видел только на картинках :DDDDDDD

cumvillain
()
Ответ на: комментарий от zx_gamer 
/*
 * The version-1 superblock :
 * All numeric fields are little-endian.
 *
 * total size: 256 bytes plus 2 per device.
 *  1K allows 384 devices.
 */
struct mdp_superblock_1 {
	/* constant array information - 128 bytes */
	__le32	magic;		/* MD_SB_MAGIC: 0xa92b4efc - little endian */
	__le32	major_version;	/* 1 */
	__le32	feature_map;	/* bit 0 set if 'bitmap_offset' is meaningful */
	__le32	pad0;		/* always set to 0 when writing */

	__u8	set_uuid[16];	/* user-space generated. */
	char	set_name[32];	/* set and interpreted by user-space */

	__le64	ctime;		/* lo 40 bits are seconds, top 24 are microseconds or 0*/
	__le32	level;		/* 0,1,4,5 */
	__le32	layout;		/* only for raid5 and raid10 currently */
	__le64	size;		/* used size of component devices, in 512byte sectors */

	__le32	chunksize;	/* in 512byte sectors */
	__le32	raid_disks;
	union {
		__le32	bitmap_offset;	/* sectors after start of superblock that bitmap starts
					 * NOTE: signed, so bitmap can be before superblock
					 * only meaningful of feature_map[0] is set.
					 */

		/* only meaningful when feature_map[MD_FEATURE_PPL] is set */
		struct {
			__le16 offset; /* sectors from start of superblock that ppl starts (signed) */
			__le16 size; /* ppl size in sectors */
		} ppl;
	};

	/* These are only valid with feature bit '4' */
	__le32	new_level;	/* new level we are reshaping to		*/
	__le64	reshape_position;	/* next address in array-space for reshape */
	__le32	delta_disks;	/* change in number of raid_disks		*/
	__le32	new_layout;	/* new layout					*/
	__le32	new_chunk;	/* new chunk size (512byte sectors)		*/
	__le32  new_offset;	/* signed number to add to data_offset in new
				 * layout.  0 == no-change.  This can be
				 * different on each device in the array.
				 */

	/* constant this-device information - 64 bytes */
	__le64	data_offset;	/* sector start of data, often 0 */
	__le64	data_size;	/* sectors in this device that can be used for data */
	__le64	super_offset;	/* sector start of this superblock */
	union {
		__le64	recovery_offset;/* sectors before this offset (from data_offset) have been recovered */
		__le64	journal_tail;/* journal tail of journal device (from data_offset) */
	};
	__le32	dev_number;	/* permanent identifier of this  device - not role in raid */
	__le32	cnt_corrected_read; /* number of read errors that were corrected by re-writing */
	__u8	device_uuid[16]; /* user-space setable, ignored by kernel */
	__u8	devflags;	/* per-device flags.  Only two defined...*/
#define	WriteMostly1	1	/* mask for writemostly flag in above */
#define	FailFast1	2	/* Should avoid retries and fixups and just fail */
	/* Bad block log.  If there are any bad blocks the feature flag is set.
	 * If offset and size are non-zero, that space is reserved and available
	 */
	__u8	bblog_shift;	/* shift from sectors to block size */
	__le16	bblog_size;	/* number of sectors reserved for list */
	__le32	bblog_offset;	/* sector offset from superblock to bblog,
				 * signed - not unsigned */

	/* array state information - 64 bytes */
	__le64	utime;		/* 40 bits second, 24 bits microseconds */
	__le64	events;		/* incremented when superblock updated */
	__le64	resync_offset;	/* data before this offset (from data_offset) known to be in sync */
	__le32	sb_csum;	/* checksum up to devs[max_dev] */
	__le32	max_dev;	/* size of devs[] array to consider */
	__u8	pad3[64-32];	/* set to 0 when writing */

	/* device state information. Indexed by dev_number.
	 * 2 bytes per device
	 * Note there are no per-device state flags. State information is rolled
	 * into the 'roles' value.  If a device is spare or faulty, then it doesn't
	 * have a meaningful role.
	 */
	__le16	dev_roles[];	/* role in array, or 0xffff for a spare, or 0xfffe for faulty */
};
cumvillain
()

А когда-то я С++ знал практически на 100%. Сейчас я им вообще не пользуюсь, страшно представить объем знаний. Да уж, плюсовики себе жоб секюрити обеспечили.

vbr ★★★★
()
Ответ на: комментарий от zx_gamer

И что там не понятного? Переберать шаблоны до тех пор, пока не подойдет какой-нибудь. Очень простая идея.

Идея-то вполне понятна. Непонятны портянки ошибок на сотни строк, которые от sfinae выкатывает компилятор. Ну и реализация, как правило, тоже не самая очевидная, за пределами базовых сценариев.

Ivan_qrt ★★★★★
()
Ответ на: комментарий от zx_gamer

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

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

Здесь типы подобраны так, чтобы не было разрывов. Нужные места забиты паддингами (pad3 намекает). И все это возможно как раз потому, что в ядре кто-то задрочился и сделал аналог stdint.h для поддерживаемых архитектур.

Ну и да — теперт ты понял как htobe и betoh работают?

cumvillain
()

Я джва года ждал эту фичу. Макропортянок станет ещё меньше.

Но, конечно, надо чтобы ещё поддержку модулей допилили в компиляторах и системах сборки, ибо скорость компиляции это самое.

KivApple ★★★★★
()
Ответ на: комментарий от zx_gamer

Разные системы по-разному хранят числа.

Все системы хранят числа одинаково - в little endian. Исключение - исчезающе малое количество копролитов, на которые не нужно ориентироваться.

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

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

Bfgeshka ★★★★★
()
Ответ на: комментарий от zx_gamer

Как 8 char, которые потом разворачивать.

Нет, так не интересно. Покажи код, который будет проще чем вот это:

struct foobar {
    uint32_t a;
    uint32_t b;
};

void
read_foobar(int fd, struct foobar *f)
{
    int ret;

    ret = read(fd, f, sizeof(*f));
    if (ret == -1)
        errx(1, "cannot read foobar from socket");

    f->a = be32toh(f->a);
    f->b = be32toh(f->b);
}

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

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

Достаточно одной функции, первый аргумент указатель на структуру, второй режим конвертации. В случае если архитектура совпадает с архитектурой машины, то можно вообще сделать один fread и все.

MOPKOBKA ★★★★
()
Ответ на: комментарий от zx_gamer

На первое число, и на второе, это же твое предложение, читаем отдельно в разные поля.

-- Твой алгоритм:

читаем в поле 1
читаем в поле 2
читаем в поле 3

конвертируем поле 1
конвертируем поле 2
конвертируем поле 3

-- Алгоритм со сжатой фиксированной структурой иной:

читаем структуру

конвертируем поле 1
конвертируем поле 2
конвертируем поле 3

MOPKOBKA ★★★★
()
Ответ на: комментарий от zx_gamer

Ничто кроме GCC (и возможно clang) не сможет это собрать.

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

MOPKOBKA ★★★★
()
  1 2 3 4 5 6
← Шрифты с отличающейся кириллицей
Development
Почему проигрывание медиа в Chromium такое дерьмовое? →