Tynambule

En nos temps où l’orienté-objet est roi, un schéma de fonctionnement revient régulièrement :

Un objet dont chaque instance correspond à une ligne en base. On charge les données lors de l’initialisation de l’objet (dans son constructeur), puis on les sauvegardes lorsque l’on a fini de les modifier.

La problématique est la suivante : mais quand a-t-on fini de les modifier? Dans 99% des cas, « ça dépend« . Les méthodes pour implémenter cette notion sont légions: une méthode genre save que l’on appelle « à la fin« , une sauvegarde systématique à chaque modification, et la rationnelle mais risquée sauvegarde dans le destructeur de l’objet.

Cette dernière méthode semble la plus intéressante, puisqu’elle défini avec une presque certitude la notion de « fin » de modifications. Toutefois, dans notre contexte orienté objet, il y a de fortes chances que l’on utilise un objet pour se connecter à la base de donnée. Et cet objet fermera probablement sa connexion dans le destructeur. Et comment savoir que la base est encore connectée lors de l’exécution du destructeur de notre objet de données? C’est le drame.

Lire la suite…

Il y a longtemps, en octobre 2003 (fichtre… un coup de vieux…), j’avais codé un petit moteur 3D en AS1, permettant d’afficher des wireframes d’objets à partir d’un fichier XML.

J’ai repris le même principe pour cette note, mais en recodant la classe en AS2, parce que quand même, c’est plus mieux. J’en ai également profité pour coder un petit exporteur pour 3D Studio Max afin d’afficher des objets plus complexes. Un exemple en image:

[NdT: A pu ]

Cette petite démo n’existe pas tant pour l’aspect que pour la technique de calcul et de rendu. Elle intègre notament la multiplication de matrices, et le rendu est fait sur le principe Vertex Buffer/Index Buffer cher à nos cartes graphiques, sans pousser toutefois le vice jusqu’à nécessiter des primitives triangulaires.

Lire la suite…

Le C++ nous offre la merveilleuse possibilité de surcharger les opérateurs pour certaines classes. Prenons par exemple une petit classe toute simple:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

class Point {
public:
    Point ( int NewX, int NewY );
private:
    int m_nX;
    int m_nY;
public:
    int GetX ( void );
    int GetY ( void );
};
 
Point::Point ( int NewX, int NewY ) {
    m_nX = NewX;
    m_nY = NewY;
}
 
int Point::GetX( void ) {
    return m_nX;
}
 
int Point::GetY( void ) {
    return m_nY;
}

Et maintenant, essayons de lui implémenter l’opérateur << pour pouvoir l’utiliser dans un cout…

Lire la suite…

Essayez de créer un répertoire ou un fichier nommé « con(.n’importe quoi) ». Ou alors « nul ». Voyez, Microsoft n’autorise que l’élite à utiliser ses produits.

Bon, en fait, c’est en rapport avec le fait que CON et NUL sont des noms réservés sur le système de fichier NTFS (et FAT, d’ailleurs), puisqu’il s’agit de flux virtuels dirigés vers des ports. Tous ces noms sont réservés :

 COM1 à COM9 - Les ports sériels LPT1 à LPT9 - Les ports parallèles CON         - Port virtuel de la console NUL         - Port nul (les données sont perdues) PRN         - Port imprimante 

Pour vous en rendre compte, ouvrez une session console et écrivez simplement :

 copy C:\unfichier.txt con 

Eh bim, ce fichier s’affiche dans la console. Un mystère de moins! Allez, salut.

Si le passage d’arguments est essentiel aux applications console, et donc très bien intégré à Visual Studio lors du développement de ce genre de soft, il est en revanche bien moins en avant dans le cadre d’un développement Windows Forms.

Pourtant, passer des arguments peut aussi se faire à ce genre de soft. Par exemple, j’ai travaillé dernièrement sur un petit outil de sauvegarde automatique, lancé au démarrage de Windows. Afin de ne pas ennuyer l’utilisateur avec une fenêtre visible, je souhaitais donc lancer ce programme dans une fenêtre minimisée, sous forme d’une icône systray.

Mais comment?

Lire la suite…