Wrap or not?

[sirGustav]

Efter att ha spenderat ungefär en halv dag till att wrappa(sp?) physfs för att passa in i mitt övriga system, så börjar jag fundera av vilken anledning jag gör detta. Yagni skriker och gapar i bakhuvudet och jag vet att det inte är speciellt svårt att byta mellan två bibliotek, så varför känns det så fel att explicit lägga in en koppling till ett externt bibliotek?
Så för att göra en lång historia kort, hur gör ni? wrappar eller använder bibliotek direkt?

[TheSpaceMan]

Använder jag ett bibliotek direkt utan wrapper lager så försöker jag göra det med beslutet att hela det nuvarande projektet ska använda det externa libet tills det är klart.

[dooz]

Det beror nog även på hur stor påverkan det externa libbet har på koden, för är det något som man tycker är lite fult, så vill man ogärna ha det överallt. Och säkert även på projektets storlek; i min egen kod, där har jag inga som helst problem med att byta ut vad som helst, det är bara att göra det och fixa felen. På jobbet med skitmånga inblandade, och veckolånga releaseprocessor, så hade jag nog funderat över en wrapper ifall jag inte var säker på libbet jag valde (nu är vi väldigt nih på jobbet, så det har inte blivit aktuellt ).

För tillfället använder jag zlib, bzip samt d3dx (och säkert något annat jag glömt) som externa lib. zlib/bzip är begränsade till mina file-io rutiner, som har mitt egna gränssnitt utåt, och d3dx är så innästlat överallt, att det tänker jag inte ens på som ett lib längre.

Om du bestämmer dig för att wrappa något, så bör du också fråga dig "hur är det tänkt att använda hans lib, och kommer min wrapper att funka på samma sätt". Jag tror det är lätt att man gör något knöligt om man wrappar ett API som det är tänkt att använda på ett visst sätt, med funktioner som innebär att man måste jobba med det på ett annat sätt.

[sirGustav]

Det är inte att det är fult eller att jag tror att jag kommer att byta ut det, det är bara det att funktions-namn och arbetssätt inte passar in i resten av mitt spel, plus att det känns fel att plocka in externa beroenden och bygga sin kod på dem. Dock har jag inga som helst problem att göra direkta kopplingar till andra liknande bibliotek som tiny-xml, så mina tankegångar känns inte direkt logiska

Dock stämmer det som du säger att physfs, precis som zlib, bzip (och tiny-zml), är begränsat till io, så det är ganska enkelt att byta ut... hmmm...

[dooz]

Ah, haha, jag läste nog lite fel när jag läste vilket lib du snackade om. Jag fick det till någon felskrivning av något fysiklib, och inte file system-lib, och då har det ju mycket mindre inverkar på kodbasen. Jag supportar zlib och bzip i min file-io, och använder #ifdef SUPPORTS_ZLIB etc runt includsen och koden som anropar zlib-specifika funktioner för att kunna använda file-io grejerna i raw mode (dvs utan komprimering), utan att behöva inkludera zlib överallt.

Så var det dock inte från början, utan det var först när jag började på något mindre projekt och ville ha simplast möjliga file-io som jag la till mina #ifdefs. Jag insåg att det var rätt dumt att känna att det var jobbigt att använda kod man skrivit själv

En grej som jag börjar överväga allt mer är att låsa mig till en viss version av ett lib när jag märker att det funkar, och helt enkelt vara så brutal att jag då tar och slänger ihop libbets alla .c/.h filer till en enda stor .c och .h fil, och lägger till den i min kod istället för att ha den som en extern lib. Det kanske mest är för att komma runt någon psykisk "åh nej, inte fler lib jag måste få med i min solution.." grej, men jag testade lite smått med ett .mpq lib (warcrafts filformat) samt ett dxt-uppackarlib, och det kändes helt ok. Plus att det blir lättare om man ska ge bort koden på något sätt.

[sirGustav]

Ah, haha, jag läste nog lite fel när jag läste vilket lib du snackade om. Jag fick det till någon felskrivning av något fysiklib, och inte file system-lib, och då har det ju mycket mindre inverkar på kodbasen.

det må ha ett konstigt namn, men ett bättre/stabilare vfs går inte att hitta

Jag supportar zlib och bzip i min file-io, och använder #ifdef SUPPORTS_ZLIB etc runt includsen och koden som anropar zlib-specifika funktioner för att kunna använda file-io grejerna i raw mode (dvs utan komprimering), utan att behöva inkludera zlib överallt.

varför två olika komprimeringsbibliotek baserat på kompilator-flaggor? Såvida det inte finns några externa krav, så verkar det mest som du ger dig själv dubbelt så mycket arbete, eller är det någon fördel som jag missat?

[dooz]

varför två olika komprimeringsbibliotek baserat på kompilator-flaggor? Såvida det inte finns några externa krav, så verkar det mest som du ger dig själv dubbelt så mycket arbete, eller är det någon fördel som jag missat?

Vad bra det är att ventilera detaljer för folk som inte automatiskt tycker att jag är awesome (läs: jag själv ). Nej, du har rätt, det blev inte alls så bra som jag hade hoppats på, utan bara knöligt att behöva ha extra projektinställningar.

[sirGustav]

Det är inte projektinställningarna som är det största problemet, eftersom med ett vettigt byggsystem så skall det bara vara en inställning, checkbox i cmake som ett vettigare (än vs) exempel. Problemet är istället att man ger sig extra arbete till "ingen" nytta. "ingen" i detta fallet är inom fnuttar, eftersom du kan enkelt designa ett vfs som har support för bzip, gzip och andra arkivsystem för att det behövs. Sedan kan man lägga in kompilatorflaggor för att plocka bort gzip, och bzip för att få en mindre exe, och vips så finns ett system som är mer kompilcerat...
Man kan också tänka sig ett system där kraven är att det antingen måste läsa bzip eller gzip, men det beror på externa beslut som tar lång tid och det kommer ta för lång tid för en eventuell portning när man får reda på vilket, eller att systemet har två beställare och den ena använder gzip och den andra bzip av diverse skäl.
Så... det är en awesome idé om det finns anledningar