bonjour
 
soit un document en utf(n) samere(tm)
 
est ce que a votre avis, est ce qu'on peut utliser des algos classique de recherche de chaine de caractere sur ledit document utf-8, ou le systeme d'encodage de ce dernier risque de tout ruiner ? (donc je rapelle en gros les trucs classiques : comparaisons octet par octet)
 
merci
 
 
exemple :
 
j'ai un document encodé en mac roman
j'ai une chaine de caractère en iso-8859-1
 
je converti tout ca en utf-8 et j'utilise un boyer moore classique la dessus

ça marche mais si tu commences la balayage depuis le début de la chaine et que tu utilises des routines spécifiques pour de déplacer caractère par caractère. ou alors tu passes en utf-32

 
ca m'a l'air un peu casse gueule, non ? l'utf 32, oué, pourquoi pas, c'est une bonen feinte du pere la feinte, j'y avais pas pensé, tiens, c'est pas con.
 
edit : bon par contre pour le boyer moore faudra changer la table de lookup

non, c'est pas trop casse gueule. j'utilise ça avec glib/gtk et ça marche pas trop mal. Faut juste oublier ses habitudes de ++p c'est tout.

http://developer.gnome.org/doc/API [...] ation.html

 
tiens, bin tant qu'on y est, y'a une feinte pour savoir quelle version de glib on a d'installé ? (on a pas un linux de derniere fraicheur, donc bon. Du redhat 7.4 si je ne m'abuse)

pkg-config --modversion glib-2.0

pkg-config --list-all | grep glib
 
déjà
 
cela dit pour un bon support, je te conseille de mettre à jour ta glib (ou du moins d'utiliser une version récente à côté)

ah bin on a la 2.0  
 
bin c'ets pas trop mon pc, mais plutot le serveur de prod, donc bon, en fait on prefere pas trop y toucher
 
Sinon, tiens, sans rapport et tant que je t'ai sous la main, y'a moyen de creer un fichier sous unix en specifiant directement la taille sur disque ? (genre pour ne pas avoir a le remplir a coup de fwrite tout pourri)
 
 

1) ben tu peux installer ta glib-2.0 récente dans un coin, sans problème. pkg-config te rends service pour ajuster ton LDPATH et CPPPATH. Penses-y.
2) oui. tu ouvres, et tu fais un seek, t'écris 1 octets bidon, et voilà, t'as un fichier à trou.

alors ça passe ?

pas eu le tps
demain jmeclate avec tout ca
 
merci
 
par contre ton fseek j'ai pas tout compris

ben sous unix, tu as des fichiers à trou.
 
taille logique > espace disque occupé
 
donc pour faire un trou, c'est simple. exemple rapidos
 
 

 
vois ça comme une allocation paresseuse. c'est une technique très employée.

ah d'accord, je connaissais pas, interessant. question rapidos : si apres je map ce fichier en mémoire en MAP_SHARED, j'ai bien acces au 1.1go sans gag ? (juste pour etre sur)

mais jme demandais, c'est bien conforme aux normes ce comportements ?

C'est style les Sparse Files de NTFS ?

l'inverse !

et oui, c'est normalisé ce genre de comportement, messieurs les dev de SGBD s'en servent beaucoup d'ailleurs