Wykorzystanie pliku jako zawartości tablicy char

pytanie zadane 11 listopada w C i C++ przez Badzonor Obywatel (1,410 p.)

Cześć, chcę wiedzieć czy jest jakaś możliwość aby kompilator C++ jako początkową zawartość tablicy char użył pliku. To znaczy zamiast

char t[] = "test test";

użyć zewnętrznego pliku o treści "test test" a kompilator wykorzysta to jako zawartość zmiennej.

Pozdrawiam.

komentarz 11 listopada przez j23 Mędrzec (194,340 p.)

No a plik źródłowy to nie plik?

komentarz 11 listopada przez Badzonor Obywatel (1,410 p.)

Potrzebuje żeby był oddzielny, kiedy chcę żeby plik png (który jest binarny) był treścią zmiennej to muszę go wpierw konwertować a to nie pomaga w wydajnej pracy.

komentarz 11 listopada przez j23 Mędrzec (194,340 p.)

Tak się nie da. Co najwyżej możesz w procesie kompilacji odpalić jakiś program lub skrypt, który generuje plik źródłowy z plików binarnych, które chcesz osadzić w programie.

komentarz 11 listopada przez Oscar Nałogowiec (29,130 p.)

@Badzonor, Kiedyś powszechnie było stosowane narzędzie bin2c - czyli coś co z pliku binarnego robi (jako źródło C) definicje tablicy. Oczywiście wymaga to kolejnego kroku w kompilacji - trzeba to uwzględnić w makefile, tak by zmiana tego obrazka skutkowała przekompilowaniem programu. Sam ostatnio popełniłem takie narzędzie:

#include <stdio.h>

int main(int argc, char * argv[])
{
    int c, cnt = 0;
    while ((c = getchar()) != EOF)
    {
        cnt ++;
        if (cnt == 1)
        {
            printf("    ");
        }
        printf("0x%02X, ", c);
        if (cnt == 24)
        {
            printf("\n");
            cnt = 0;
        }
    }
}

Oczywiście to banalnie proste, działa jak taki unixowy filtr - trzeba przekierować wejście i wyjście,

./bin2c < plik.png > plik.png.h

wygenerowany plik to po prostu ciąg liczb w formacie strawnym dla C

    0x14, 0xAA, 0x5D, 0x88, 0xD6, 0x20, 0x7A, 0x08, 0x7A, 0xF4, 0xE2, 0xCD, 0x1D, 0x8F, 0x96, 0xE9, 0xC7, 0x23, 0xAE, 0xEC, 0x23, 0xAD, 0xAD, 0x8E, 
    0xA6, 0x80, 0x4F, 0xFC, 0x16, 0x4A, 0xFE, 0xC4, 0xA6, 0x4F, 0xF9, 0x94, 0x52, 0x56, 0xE8, 0x71, 0x8A, 0x06, 0x87, 0x3D, 0xF3, 0x22, 0xA6, 0xDE, 
    0xF0, 0x01, 0x6C, 0xB8, 0xC0, 0xE8, 0xD5, 0x97, 0x1D, 0xBF, 0x52, 0x34, 0x24, 0x8F, 0xAE, 0x2D, 0xA6, 0xA1, 0x16, 0x78, 0xAC, 0xE2, 0x9D, 0x96, 
    0x89, 0xDB, 0x9D, 0x4C, 0x01, 0x4C, 0x49, 0xB0, 0x47, 0xF9, 0x3F, 0x98, 0xE8, 0x7E, 0x30, 0xDF, 0x05, 0x69, 0xD7, 0xCD, 0x35, 0x0D, 0xD4, 0x65, 
    0x51, 0xE5, 0x22, 0x26, 0xD7, 0x38, 0xD4, 0x55, 0x10, 0xBA, 0x3F, 0x62, 0xA8, 0xE4, 0xC1, 0xC3, 0x1C, 0xC5,

a we właściwym kodzie źródłowym:

static const uint8_t table[] = {
#include "plik.png.h"  
};

Ale jeśli chodzi o obrazki to np. GIMP jako jedną z opcji zapisu pliku umożliwia zapis jako format pliku źródłowego C - generuje wtedy strukturę opisującą obrazek wraz w mapą pixeli.

komentarz 11 listopada przez adrian17 Ekspert (337,960 p.)

Żeby takiego potworka nie musieć robić, C23 doda #embed :)

Natomiast pytanie do Badzonora, bo wszyscy z góry skoczyli do łączenia pliku w momencie kompilacji - nie możesz wczytać pliku do tablicy podczas działania programu? Tak będzie trochę prościej.

komentarz 12 listopada przez j23 Mędrzec (194,340 p.)

bo wszyscy z góry skoczyli do łączenia pliku w momencie kompilacji

Skoczyli, bo OP zdaje się o to pytał.

komentarz 13 listopada przez Oscar Nałogowiec (29,130 p.)

@adrian17, Takie numery robi się w dwóch przypadkach - chcesz mieć aplikację w 1 pliku exe i wszystko w środku (taki max portable) albo masz jakiś prosty embedded i nie ma plików. Czasem stosowało się zwykłe doklejenie pliku na końcu wyniku z kompilacji.