[C] Как набор байт в памяти сделать файлом, не создавая файл на диске?

Создай файл в /dev/shm/*, на диске его не будет.

> Создай файл в /dev/shm/*, на диске его не будет.

C вообще-то кроссплатформенный язык, надо кроссплатформенное решение.

никак

portable != cross-platform

А по теме: боюсь, что никак...

Может быть можно как-то хитро fopen() использовать чтоб получить дескриптор не на файл а на кусок байт?

Да, кстати, задача упрощается - надо открывать кусок байт только на чтение. Но позволить читать с помощью fread(), fgetc(), двигаться с помощью fseek(), и тому подобное.

ну создай рамдиск.

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

fmemopen

> fmemopen

Во, похоже оно!


#include <stdio.h>
#include <string.h>

static char buffer[] = "foobar";

int main (void)
{
int ch;
FILE *stream;

stream = fmemopen(buffer, strlen (buffer), "r");
if (stream == NULL)
/* handle error */;

while ((ch = fgetc(stream)) != EOF)
printf("Got %c\n", ch);

fclose(stream);
return (0);
}

>fmemopen

GNU-specific, не портабельно. http://bytes.com/groups/c/218007-fmemopen-portable-version

<troll>и чего только люди не придумывают лишь бы не писать на С++</troll>

> GNU-specific, не портабельно

Буллщит

> <troll>и чего только люди не придумывают лишь бы не писать на С++</troll>

<fat-troll>И чем, интересно, твои кресты помогут в данном случае?</fat-troll>

man stream

> man stream

И что, поток можно скармливать в fgets() и направлять в futs() ?

> И что, поток можно скармливать в fgets() и направлять в futs() ?

вам надо унифицированный доступ к памяти, файлам, stdio etc.? потоки все это умеют

> man stream

Изыди, демон! У меня чуть йайцы не поседели, пока я с этим кошмариком не разобрался хоть чуть. Разработчикам stream нужно гвоздь в голову вбить!

> Изыди, демон! У меня чуть йайцы не поседели, пока я с этим кошмариком не разобрался хоть чуть. Разработчикам stream нужно гвоздь в голову вбить!

o_O там же все проще простого

> там же все проще простого

Ну, на вкус и цвет, как говорится, все фломастеры разные. Мне streams не понравились совершенно. Громоздкие они какие-то (с моей колокольни), код ужасный получается.

> Громоздкие они какие-то

если их использовать не поназначению - то да, их главный плюс - абстрагирование от способа хранения данных

> их главный плюс - абстрагирование от способа хранения данных

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

да, особенно пока напишешь stream'овский аналог какого-нибудь printf("a=%8.3lf; b=%.16le; c=%0.1lf\n", a, b, c) проклянешь авторов этого г. до седьмого колена

>да, особенно пока напишешь stream'овский аналог какого-нибудь printf("a=%8.3lf; b=%.16le; c=%0.1lf\n", a, b, c) проклянешь авторов этого г. до седьмого колена

boost::format
http://www.boost.org/doc/libs/1_39_0/libs/format/doc/format.html

classical printf directive, no reordering :
cout << format("writing %s, x=%s : %d-th step \n") % "toto" % 40.23 % 50;
It prints : "writing toto, x=40.23 : 50-th step \n"

Больше всего (с чего-бы вдруг???) меня умиляет беготня stream-ами по файлу/строке с чтением/записью/удалением/вставкой. Вот тут реально хочется кого-нить убить, и не сразу.

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

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

> cout << format("writing %s, x=%s : %d-th step \n") % "toto" % 40.23 % 50;

для себя написал точно такую же функцию, по сути просто вызов vsnprintf

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

что там не так?

> Возникает закономерный вопрос: где и как в компьютере man stream отжигает заполненные глинянные таблички? Если не отжечь, то они потрескаются и информация потеряется, и нафиг такое надо.

проспитесь

может проще printf использовать вместо подключения монстра-буста ради сомнительной цели использовать стримы ?

кода получается больше и нечитабельно

> для себя написал точно такую же функцию, по сути просто вызов vsnprintf

С точки зрения стримов это не кошерно, надо использовать модификаторы потоков и постоянные дергания стрелок : "a=" << a << "b=" << ... и вот тут начинается звиздец ... код разрастается до неимоверных размеров, читабельность нулевая

> может проще printf использовать вместо подключения монстра-буста ради сомнительной цели использовать стримы ?

форматирование и чтение/запись - абсолютно разные задачи, насчет буста согласен - уже писал выше

> С точки зрения стримов это не кошерно, надо использовать модификаторы потоков и постоянные дергания стрелок : "a=" << a << "b=" << ...

кто вам такое сказал? :)

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

> Разработчикам stream нужно гвоздь в голову вбить!

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

> Используя vsprintf ты по сути используешь stdio, а не стримы и подтверждаешь то, что на такую простейшую операцию стримы не способны.

а еще они не умеют умножать столбиком

> cout << format("writing %s, x=%s : %d-th step \n") % "toto" % 40.23 % 50;
                                                     ^
                                                     |

Синтаксис порвал. Понял до метки, остальное выше моего понимания.

> Синтаксис порвал. Понял до метки, остальное выше моего понимания

это не ко мне - я просто скопипастил

> cout << format("writing %s, x=_%s_ : %d-th step \n") % "toto" % _40.23_ % 50;

Это... кхм... поделие ещё и типы проверять не умеет?

> это не ко мне - я просто скопипастил

Тем не менее, судя по упоминанию этого убожества, такой синтаксис особого отторжения не вызывает?

> Тем не менее, судя по упоминанию этого убожества, такой синтаксис особого отторжения не вызывает?

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

String frmt = Format( "%d", 10 );

А как же (пафосно) ПОТОКИ?!

Функция, возвращающая std::string/const char */etc мало интересна. Вот бустовский вариант вполне вписывается в идеологию потоков в частности и С++ в общем. В том смысле, что страшное непонятное нечто с безумной перегрузкой операторов и непонятными побочными эффектами (один из них виден уже на примере, приведённом в этом треде -- оно нихрена не проверяет нормально аргументы, оттуда же следует, что вряд ли оно способно выдавать предупреждения a la printf(3)-семейство).

>> cout << format("writing %s, x=_%s_ : %d-th step \n") % "toto" % _40.23_ % 50;
> Это... кхм... поделие ещё и типы проверять не умеет?

а зачем ? :)

#include <iostream>

#include "boost/format.hpp"

int main()
{
    std::cout << boost::format("writing %s, x=%s : %d-th step \n") % "toto" % 40.23 % 50;

    return 0;
}

$ g++ -W -Wall -Wextra -pedantic a.cpp
$ ./a.out 
writing toto, x=40.23 : 50-th step 

чудеса ? :)

Действительно, чудеса. Это вот это вот самое овно усиленно пихают в следующий стандарт плюсовки? Как страшно жить.

> А как же (пафосно) ПОТОКИ?!
> Функция, возвращающая std::string/const char */etc мало интересна.

у меня другая точка зрения по этому вопросу

> boost::format >http://www.boost.org/doc/libs/1_39_0/libs/format/doc/format.html

Как я понял, получается так, что нужно установливать libboost, чтобы откомпилировать, следующий пример:

> std::cout << boost::format("writing %s, x=%s : %d-th step \n") % "toto" % 40.23 % 50;

Чтобы откомпилировать этот пример(GNU/Debian) пришлось установить следующие пакеты:

libboost-date-time-dev libboost-date-time1.34.1 libboost-doc libboost-filesystem-dev libboost-filesystem1.34.1 libboost-graph-dev libboost-graph1.34.1 libboost-iostreams-dev libboost-iostreams1.34.1 libboost-program-options-dev libboost-program-options1.34.1 libboost-python-dev libboost-python1.34.1 libboost-regex-dev libboost-regex1.34.1 libboost-serialization-dev libboost-serialization1.34.1 libboost-signals-dev libboost-signals1.34.1 libboost-test-dev libboost-test1.34.1 libboost-thread-dev libboost-thread1.34.1 libboost-wave-dev libboost-wave1.34.1 libicu-dev python-dev python2.5-dev

И это ради того, чтобы обеспечить форматированный вывод на stdout? В конечном итоге!

> ... libboost-thread-dev ... И это ради того, чтобы обеспечить форматированный вывод на stdout? В конечном итоге!

Врядли. Скорее всего, ты сказал aptitude install libboost-dev, а не то, что тебе надо.

З.Ы. Тебя так сильно волнует лишний десяток МБ на *девелоперской* тачке?

> Чтобы откомпилировать этот пример(GNU/Debian) пришлось установить следующие пакеты:

> И это ради того, чтобы обеспечить форматированный вывод на stdout? В конечном итоге!

И Чё ? :)

Сам модуль форматирования это по моему несколько .hpp файлов: http://www.boost.org/doc/libs/1_38_0/libs/format/index.html

А показанные Вами зависимости - это проблема Debian, между прочем в unstable она УЖЕ решена: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=529622

> И это ради того, чтобы обеспечить форматированный вывод на stdout? В конечном итоге!

Привыкай. C++-way как он есть.

> Привыкай. C++-way как он есть.

я вижу вы знаток "C++-way"

> Привыкай. C++-way как он есть.

Вы что-то попутали, зависимости в Debian к C++ никакого отношения не имеют :)