[C] - Minesweeper clone

[bnvdarklord]

@migf1, παρατηρήσεις :

 

 

 

Επιχείρησα επίσης να κάνω τον κώδικα να σέβεται το 80 column rule

Για ποιο λόγο;

 

 

Ένα άλλο που έκανα, είναι να κάνω cast σε void όσα ορίσματα συναρτήσεων δεν χρησιμοποιούνται μέσα στην συνάρτηση, για να μην βγάζει warnings ο compiler.

Και γιατι δεν τα έσβηνες απλά, είχαν ξεμείνει Δυστυχώς ο compiler της microsoft με -W4 (και -Wall) δεν γκρίνιαξε και έτσι δεν τα πρόσεξα.

 

Παρατήρησα επίσης πως κάνεις #include .cpp αρχεία, αντί να διαχωρίζεις τα declarations σε .h header αρχεία, τα οποία να κάνεις κατόπιν include. Αυτό θεωρείται κακή πρακτική.

Γενικά δεν μου πολυαρέσει το include σύστημα σε C/C++ για αυτό δοκιμάζω διάφορα. Σε αυτό το project είπα να τα έχω όλα .cpp και να είναι και union build(υπάρχουν εξτρα includes ομως γιατι γκρινιάζει το visual studio). Για το τελικό exe όμως που κάνω compile με ένα batch κάνει compile μόνο το ένα win32_minesweeper.cpp. Έχω διαβάσει πλεονεκτήματα και μειονεκτήματα των union build, ήθελα απλά να δοκιμάσω.

 

Επίσης, εκείνα τα #pragma once που βάζεις στα .cpp αρχεία σου (υποθέτω για να τα προστατεύσεις από multiple inclusions) εκτός του ότι δεν είναι cross-platform, κάνουν τον gcc να παραπονιέται (επειδή κανονικά πρέπει να χρησιμοποιούνται σε .h αρχεία).

Περί cross-platform: http://en.wikipedia.org/wiki/Pragma_once#Portability

 

 

 

 

Συναφές με την πρακτική που ακολουθείς να κάνεις include .cpp αρχεία, είναι πως ο g++ παραπονιέται για συναρτήσεις που τις ορίζεις αλλά δεν τις χρησιμοποιείς. Βασικά, αυτό που κάνεις είναι να τις ορίζεις ως static σε ένα αρχείο, που σημαίνει πως έχουν internal linkage στο συγκεκριμένο .cpp αρχείο, αλλά δεν τις χρησιμοποιείς σε αυτό το αρχείο (για αυτό και παίρνεις warning από τον g++).

Όπως είπα πριν είναι union build, κάνεις build μόνο το win32_minesweeper.cpp.

 

 

Είδα επίσης πως χρησιμοποιείς πολλές global μεταβλητές (μάλλον κακό), αν και συνήθως τις περιορίζεις στο εκάστοτε file (μάλλον καλό). Όπως είπα δεν κάθισα να δω τον κώδικα, οπότε μπορεί όντως να εξυπηρετούν καλύτερα οι συγκεκριμένες καθολικές μεταβλητές.

Χρειάζονται σίγουρα κάποιες, καθώς το παιχνίδι πρέπει να διατηρεί κάποιο state μεταξύ frames.

 

(επίσης το μάλλον καλό που είπες δεν υπάρχει - union build )

 

Ακόμα, ο g++ δείχνει να τσινάει όταν κάνεις initialize με {}, ακόμα κι αν του βάλεις -std=c++11 (νομίζω πως κακώς τσινάει). Όπως και να έχει, βγάζει warnings (όχι errors) για αυτό και τα απενεργοποίησα με: -Wno-missing-field-initializers στο makefile.

Ας τσινάει  

 

Επίσης, στο αρχείο "Minesweeper.rc" (που μάλλον είναι auto-generated από το VS) έκανε include το "winres.h", το οποίο ΔΕΝ υπάρχει στο mingw32 toolchain.

Αυτό δεν μας ενδιαφέρει, γιατί το Minesweeper.rc είναι windows specific έτσι και αλλιώς.

 

Τέλος, παρατήρησα το εξής κουφό. Όταν κάνω compile με ενεργοποιημένο το debugging flag (-g3) και τρέχω το πρόγραμμα μέσα στον gdb, δεν μου κάνει draw τα σκορ και τον χρόνο, γιατί λέει πως τους παίρνει πολύ ώρα (1η φορά βλέπω κάτι τέτοιο στον gdb... ίσως υπάρχει κάποιο flag που να απενεργοποιεί τέτοιον έλεγχο, δεν ξέρω).

Τι ακριβώς γράφει ο gdb???

 

 

 

[migf1]

@migf1, παρατηρήσεις :

Γιατί το έβαλες σε spoiler? Είναι εκτός θέματος η συζήτηση για τον κώδικα;

 

 

 

Για ποιο λόγο;

Για τους λόγους που αναφέρονται στο link, με τους οποίους συμφωνώ. Είναι καθαρά υποκειμενικό (δεν είναι δηλαδή υποχρεωτικό).

 

Και γιατι δεν τα έσβηνες απλά, είχαν ξεμείνει Δυστυχώς ο compiler της microsoft με -W4 (και -Wall) δεν γκρίνιαξε και έτσι δεν τα πρόσεξα.

Είναι misleading να μην υπάρχουν ως signature της συνάρτησης στον ορισμό της.

 

Γενικά δεν μου πολυαρέσει το include σύστημα σε C/C++ για αυτό δοκιμάζω διάφορα. Σε αυτό το project είπα να τα έχω όλα .cpp και να είναι και union build(υπάρχουν εξτρα includes ομως γιατι γκρινιάζει το visual studio). Για το τελικό exe όμως που κάνω compile με ένα batch κάνει compile μόνο το ένα win32_minesweeper.cpp. Έχω διαβάσει πλεονεκτήματα και μειονεκτήματα των union build, ήθελα απλά να δοκιμάσω.

Δεν έχω την παραμικρή ιδέα τι εννοείς όταν λες "union build". Αμφιβάλλω πάντως πως υπάρχει κάποιο μοντέλο που να υποδεικνύει inclusion .c/.cpp αρχείων αντί για header files.

 

Περί cross-platform: http://en.wikipedia.org/wiki/Pragma_once#Portability

Ναι. Τι εννοείς; Δεν βλέπω να λέει κάτι διαφορετικό από αυτό που έγραψα. Υπάρχουν + και -, αλλά όπως έγραψα και πριν το #pragma once είναι compiler dependent (άσχετα αν τυγχάνει μεγάλης υποστήριξης).

 

Όπως είπα πριν είναι union build, κάνεις build μόνο το win32_minesweeper.cpp.

 

Χρειάζονται σίγουρα κάποιες, καθώς το παιχνίδι πρέπει να διατηρεί κάποιο state μεταξύ frames.

 

(επίσης το μάλλον καλό που είπες δεν υπάρχει - union build )

Δεν ξέρω τι είναι το union build, οπότε δεν καταλαβαίνω τι εννοείς. Αυτό που κάνεις όμως π.χ. με τη global var UI (που τη δηλώνεις static global σε ένα .cpp και κατόπιν κάνεις include ολόκληρο το .cpp σε άλλο .cpp προκειμένου να μπορέσεις να χρησιμοποιήσεις την UI KAI στο 2ο .cpp) είναι τελείως ανορθόδοξο και σίγουρα αποτελεί κακή πρακτική.

 

Ας τσινάει  

 

Αυτό δεν μας ενδιαφέρει, γιατί το Minesweeper.rc είναι windows specific έτσι και αλλιώς.

Δεν καταλαβαίνω το ύφος των παραπάνω απαντήσεών σου. Υποτίθεται πως έχεις γράψει cross-platform κώδικα στον πυρήνα και πως έχεις ξεχωρίσει το UI, με σκοπό να μπορεί κάποιος να αντικαταστήσει σε ένα μόνο αρχείο τον windows specific κώδικα του ui.

 

Αφενός λοιπόν υπέθεσα πως θα σε ενδιέφεραν λεπτομέρειες και οι αιτίες για τα warnings που βγάζει ο mingw32 g++, που είναι από τα πλέον δημοφιλή tool-chains σε όλες τις πλατφόρμες, μιας και όχι μόνο αποτελεί port του ίδιου του g++, αλλά διατίθεται και σε πληθώρα πλατφορμών (για αυτό και σου παρέθεσα αναλυτικά όσες παρατήρησα), και αφετέρου ο τρόπος που διαχειρίζεσαι το UI (με τον τρόπο που περιέγραψα πιο πάνω) δεν είναι καθόλου δόκιμος (επίσης δεν ξέρω αν θα λειτουργήσει κιόλας).

 

Ίσως κατάλαβα λάθος και μάλλον κακώς ασχολήθηκα (πάντως αν ενδιαφέρεται κανείς, τα ξέμπλεξα τα include και την UI μεταβλητή, φτιάχνοντας appropriate header files, που btw ακολουθούν τη δική σου κατηγοριοποίηση... αν είναι πείτε μου να τα ποστάρω).

 

Τι ακριβώς γράφει ο gdb???

Είδα τελικά πως έχεις βάλει εσύ στον κώδικα ένα else για όταν παίρνει πολύ χρόνο να γίνει το rendering. Αυτό έβγαζε στον gdb... μάλλον κάτι άλλο θα έκαναν τα windows εκείνη την ώρα, γιατί όταν ξαναδοκίμασα δούλευε οκ.

 

 

 

[bnvdarklord]

Επειδή είναι μακρινάρι το βάζω σε spoiler

 

 

 

 

Δεν έχω την παραμικρή ιδέα τι εννοείς όταν λες "union build". Αμφιβάλλω πάντως πως υπάρχει κάποιο μοντέλο που να υποδεικνύει inclusion .c/.cpp αρχείων αντί για header files.

"unity build" εννοούσα. Η ιδέα είναι ότι κάνεις compile ένα αρχείο μονο, στο οποίο γίνεται include ότι χρειάζεσαι(δεν σχετίζεται με χώρισμα .h/.cpp αυτό ηταν άσχετη δική μου επιλογή, και πάλι ήθελα να δοκιμάσω πως θα πάει αν το κάνω έτσι). Έχει αρκετά μειονεκτήματα, αλλά το βασικό πλεονέκτημα είναι ότι τα compile times ελαχιστοποιούνται. Ήθελα απλά να το δοκιμάσω σαν τεχνική.

 

Ναι. Τι εννοείς; Δεν βλέπω να λέει κάτι διαφορετικό από αυτό που έγραψα. Υπάρχουν + και -, αλλά όπως έγραψα και πριν το #pragma once είναι compiler dependent (άσχετα αν τυγχάνει μεγάλης υποστήριξης).

Εννοώ, ότι αφού έχει μεγάλη υποστήριξη απο compilers δεν καταλαβα γιατι υπάρχει πρόβλημα με την χρήση του. Αν θέλεις, μπορεις να μου εξηγίσεις.

 

 

Δεν καταλαβαίνω το ύφος των παραπάνω απαντήσεών σου. Υποτίθεται πως έχεις γράψει cross-platform κώδικα στον πυρήνα και πως έχεις ξεχωρίσει το UI, με σκοπό να μπορεί κάποιος να αντικαταστήσει σε ένα μόνο αρχείο τον windows specific κώδικα του ui.

Νομίζω αυτό έχω κάνει. Αν θελήσει να κάνει κάποιος port θα χρειαστεί στο πχ linux_minesweeper.cpp να φτιάξει έναν τρόπο να φορτώνει την εικόνα στην μνήμη. Είτε θα χρησιμοποιήσει κάτι αντίστοιχο για linux με το .rc αν θέλει να ενσωματώσει την εικόνα στο εκτελέσιμο, είτε θα την φορτώσει από εξωτερικό αρχείο. Ο υπολοιπος κώδικας δεν νοιάζεται για αυτό.

 

 

Αφενός λοιπόν υπέθεσα πως θα σε ενδιέφεραν λεπτομέρειες και οι αιτίες για τα warnings που βγάζει ο mingw32 g++

Όχι, έχεις δίκιο. Δοκίμασε αν θέλεις να κάνεις μια compile με g++ μόνο το win32_minesweeper.cpp. Με την λογική του unity build(άσχετα αν ειναι καλη ή οχι προς το παρον) θα γίνουν όλα include σε ένα και νομίζω δεν θα βγάλει τα warnings για τις συναρτήσεις. Αυτό εννοούσα. Τώρα ναι, μπορεί ο τρόπος αυτός να μην είναι ο καλύτερος, όπως είπα ήθελα να τον δοκιμάσω

 

Είδα τελικά πως έχεις βάλει εσύ στον κώδικα ένα else για όταν παίρνει πολύ χρόνο να γίνει το rendering. Αυτό έβγαζε στον gdb... μάλλον κάτι άλλο θα έκαναν τα windows εκείνη την ώρα, γιατί όταν ξαναδοκίμασα δούλευε οκ.

Περίεργο, θα το κοιτάξω.

 

 

[defacer]

Αυτό που έχεις κάνει εδώ όμως δεν είναι το γνωστό unity build. Unity build θα ήταν να έχεις ένα .cpp αρχείο που να κάνει #include όλα τα υπόλοιπα, και να κάνεις build μόνο αυτό το ένα. Εσύ όμως έχεις όλα τα .cpp αρχεία να κάνουν include άλλα .cpp αρχεία, με αποτέλεσμα

1. Να μην είναι προφανές ότι κάνεις unity build (π.χ. βλέποντας το αρχείο που λες ότι κάνεις build me batch)
2. Να μην έχεις πλέον τη δυνατότητα να κάνεις κανονικό build αντί για unity

Από τα παραπάνω επίσης υποψιάζομαι πως δεν έχεις εμπειρία με τα project configuration σε VS. Θα μπορούσες να κάνεις το unity σωστά και να έχεις τη δυνατότητα να φτιάχνεις είτε unity είτε κανονικό μέσα από το VS (και επίσης από command line κανονικά με το nmake).

 

Και τέλος, unity build δε σημαίνει ότι αναγκαστικά δεν έχεις .h αρχεία και τα βάζεις όλα μέσα σε .cpp (εξάλλου όσον αφορά τον compiler .h και .cpp και .whatever δεν έχει καμία διαφορά). Γενικά νομίζω πως είτε δεν κατάλαβες ακριβώς πώς και γιατί είτε απο κει που τα είδες τα εξηγούσαν λάθος.

[migf1]

Επειδή είναι μακρινάρι το βάζω σε spoiler

 

 

 

"unity build" εννοούσα. Η ιδέα είναι ότι κάνεις compile ένα αρχείο μονο, στο οποίο γίνεται include ότι χρειάζεσαι(δεν σχετίζεται με χώρισμα .h/.cpp αυτό ηταν άσχετη δική μου επιλογή, και πάλι ήθελα να δοκιμάσω πως θα πάει αν το κάνω έτσι). Έχει αρκετά μειονεκτήματα, αλλά το βασικό πλεονέκτημα είναι ότι τα compile times ελαχιστοποιούνται. Ήθελα απλά να το δοκιμάσω σαν τεχνική.

Από όσο ξέρω, αυτό το κάνουν σε τεράαααααααστια projects, για να μειωθεί το compilation time και γίνεται auo-generated. Δεν το κάνουν δηλαδή χειροκίνητα, γράφουν κανονικά τον κώδικα με τα header files, και μετά κάνουν auto-generate ένα unity build. Προσωπικά δεν έχει τύχει να ασχοληθώ με unity builds, αλλά το βρίσκω τελείως παράδοξο να ορίζεις static funcs/vars και μετά να κάνεις include το .cpp σε άλλο .cpp για να τις χρησιμοποιήσεις εκεί. Αντιτίθεται σε πάρα πολλά στάνταρ καλής πρακτικής και σίγουρα είναι ανορθόδοξο.

 

Εννοώ, ότι αφού έχει μεγάλη υποστήριξη απο compilers δεν καταλαβα γιατι υπάρχει πρόβλημα με την χρήση του. Αν θέλεις, μπορεις να μου εξηγίσεις.

Δεν είπα πως υπάρχει πρόβλημα. Επειδή όμως μιλάμε για cross-platform πυρήνα, θεώρησα χρήσιμο να αναφέρω πως το #pragma once δεν είναι cross-platform.

 

Νομίζω αυτό έχω κάνει. Αν θελήσει να κάνει κάποιος port θα χρειαστεί στο πχ linux_minesweeper.cpp να φτιάξει έναν τρόπο να φορτώνει την εικόνα στην μνήμη. Είτε θα χρησιμοποιήσει κάτι αντίστοιχο για linux με το .rc αν θέλει να ενσωματώσει την εικόνα στο εκτελέσιμο, είτε θα την φορτώσει από εξωτερικό αρχείο. Ο υπολοιπος κώδικας δεν νοιάζεται για αυτό.

Δεν εννοούσα πως δεν το έχεις κάνει (εννοούσα τα warnings που βγάζει ο g++ στον κώδικά σου, ανεξάρτητα από τα win και non-win κομμάτια του). Αυτό που είπα για το UI, είναι πως δεν ξέρω αν θα λειτουργεί έτσι όπως το έχεις δηλώσει, με τα static και με τα .cpp inclusions. Btw, γιατί το έχεις global το Ui, αντί να το περνάς ως παραμέτρο στις ρουτίνες που ασχολούνται με το ui; Αυτό είναι πιο νορμάλ και πιο safe.

 

Όχι, έχεις δίκιο. Δοκίμασε αν θέλεις να κάνεις μια compile με g++ μόνο το win32_minesweeper.cpp. Με την λογική του unity build(άσχετα αν ειναι καλη ή οχι προς το παρον) θα γίνουν όλα include σε ένα και νομίζω δεν θα βγάλει τα warnings για τις συναρτήσεις. Αυτό εννοούσα. Τώρα ναι, μπορεί ο τρόπος αυτός να μην είναι ο καλύτερος, όπως είπα ήθελα να τον δοκιμάσω

Δοκίμασα να κάνω compile μονάχα το win32_minesweeper.cpp και όντως δεν βγάζει warnings για unused functions (λογικό είναι, αφού ουσιαστικά κάνεις paste όλα τα υπόλοιπα .cpp μέσα στο win32_minesweeper.cpp) αλλά πραγματικά εύχομαι κι ελπίζω να μην υιοθετήσεις αυτή την πρακτική όταν γράφεις κώδικα. Μόνο προβλήματα θα έχεις. Αν ποτέ χρειαστείς untiy-build (πολύ χλωμό) άσε να το κάνεις auto-generate με τα διάφορα tools (το vs έχει νομίζω ειδική επιλογή, αλλού το κάνουν π.χ. με cmake, κλπ).

 

Περίεργο, θα το κοιτάξω.

Είναι στο else του: if (SecsElapsedFromFrame < TargetSecsPerFrame), στο win32_minesweeper.cpp.

 

[bnvdarklord]

Έχεις δίκιο defacer. Ήθελα να το στήσω ωραία με το VS αλλά δεν ήξερα πως. Επίσης τα έξτρα αρχεία που γίνονται include τα έκανα γιατί το intellisense μου έβγαζε errors. Οπότε τελικά έμεινα με αυτό το ας το πούμε unity build.

 

Το ξέρω ότι στα unity builds μπορεις να έχεις και .h αρχεία. Ήταν ξεχωριστή επιλογή να μην έχω. Το βασικό πλεονέκτημα που ξέρω ότι έχει ο χωρισμός σε .h/.cpp αντί για το σκέτο .cpp είναι ότι βοηθάει στα compilation times. Με το unity build όμως ουσιαστικά αυτό το πλεονέκτημα δεν χάνετε, μιας και όλα τελικά ειναι ένα αρχείο; Έτσι το σκέφτηκα. Πού κάνω λάθος στην σκέψη μου;

 

edit:

@migf1 Ενδιαφέρον αυτό με τα autogenerated unity builds. Πιστεύω πάντως ότι θα μπορούσα να τα φτιάξω και χειροκίνητα, αλλά να τα έχω καλύτερα στημένα, όπως υπονόησε ο defacer. Ό,τι δοκιμάζω πάντως δεν το υιοθετώ 100% γιατί δεν έχω την ανάλογη εμπειρία.

 

Αυτό που λές με τα digit boards με έχει προβληματίσει λίγο.

Αυτό το if που λες απλά κοιτάει αν το frame είναι πιο γρήγορο από 16ms(για 60fps) και αν είναι κάνει sleep το υπόλοιπο για να μην καιει την cpu. Το else απλά τυπώνει ένα μήνυμα warning σε περίπτωση που ξεφύγει(πχ αν κανεις maximize το παράθυρο παίζουν κανα δυο frame delays). Αυτό δεν μπορω να καταλάβω πως προκάλεσε το να μην εμφανίζονται απλά τα digit boards. Λογικά αν για κάποιο λόγο καθυστερούσε θα έπρεπε να ήταν laggy το παιχνίδι, ή να μην αποκρίνεται αν κλειδώσει το Sleep. Τι λες;

[gon1332]

Είναι σχετικό-άσχετο οπότε σε spoiler...

 

 

Αρχίζουν και ωριμάζουν πλέον και τα link time optimizations. Βλέπε llvm-gcc.

Οπότε αρχίζεί και εκλείπει και το πλεονέκτημα που ανέφερες.

 

EDIT: Επίσης είδα ότι το unity build βοηθά και στο compilation time. Βλέπε το

link παραπάνω.

 

 

[migf1]

Δεν ξέρω τι να σου πω τι έπαιξε, γιατί δεν έχω κοιτάξει τον κώδικα. Ότι είδα το είδα προσπαθώντας να κάνω enforce το Eighty Column Rule. Πάντως και πριν και τώρα, με debugging info μέσα του το .exe, μέσα στον gdb πετάει το OutputDebugString που έχεις εκεί πέρα (απλώς πριν δεν έκανε draw και τα digits, τώρα τα κάνει... αλλά το μήνυμα το βγάζει).

[παπι]

Το εβαλα εδω https://github.com/AnonymoPapaki/Insomnia_Sweeper

Θα του κανω ενα lifting ως project.

[gon1332]

Αν κάναμε ένα Insomnia Organization;

[migf1]

Εγώ πάντως όπως έγραψα και πριν, του έχω ήδη φτιάξει κατάλληλα header files, και προσθέτω τώρα πως έχω καταργήσει την UI ως global, και την περνάω ως όρισμα όπου χρειάζεται  (ο ορισμός της γίνεται στο αρχείο που ασχολείται με το win32 specific ui).

 

Θα μετατρέψω κι όλα τα υπόλοιπα αρχεία (πλην του win32 specific) που είναι cross-platform σε πιο συμβατικό ansi-c coding style, και μετά αν μου τη βαρέσει μπορεί να του φτιάξω και κάνα cross-platform GTK/Cairo ui.

 

Και μάλλον θα το γυρίσω σε pure C, αφού το μόνο C++ που υπάρχει τώρα, αν έχω δει καλά, είναι το {} initialization.

 

Το αν και πότε θα γίνουν όλα αυτά, άγνωστο

[defacer]

Το εβαλα εδω https://github.com/AnonymoPapaki/Insomnia_Sweeper

Θα του κανω ενα lifting ως project.

 

 

Αν κάναμε ένα Insomnia Organization;

 

http://www.insomnia.gr/topic/521538-c-%CE%B4%CE%B7%CE%BC%CE%B9%CE%BF%CF%85%CF%81%CE%B3%CE%AF%CE%B1-%CE%BB%CE%B1%CE%B2%CF%85%CF%81%CE%AF%CE%BD%CE%B8%CF%89%CE%BD/

 

https://github.com/InsomniaProjects/maze-generator

 

Δεν ασχολήθηκε κανείς (κρίμα).

[Aztec]

http://www.insomnia.gr/topic/521538-c-%CE%B4%CE%B7%CE%BC%CE%B9%CE%BF%CF%85%CF%81%CE%B3%CE%AF%CE%B1-%CE%BB%CE%B1%CE%B2%CF%85%CF%81%CE%AF%CE%BD%CE%B8%CF%89%CE%BD/

 

https://github.com/InsomniaProjects/maze-generator

 

Δεν ασχολήθηκε κανείς (κρίμα).

 

 

 

Ένα online issue tracking με zero -  three steps parametrization για freelancers και small teams πως ακούγεται... με invites και έτσι

 

μπορεί και να υπάρχει δεν το έχω ψάξει

[migf1]

Εγώ πάντως όπως έγραψα και πριν, του έχω ήδη φτιάξει κατάλληλα header files, και προσθέτω τώρα πως έχω καταργήσει την UI ως global, και την περνάω ως όρισμα όπου χρειάζεται  (ο ορισμός της γίνεται στο αρχείο που ασχολείται με το win32 specific ui).

 

Θα μετατρέψω κι όλα τα υπόλοιπα αρχεία (πλην του win32 specific) που είναι cross-platform σε πιο συμβατικό ansi-c coding style, και μετά αν μου τη βαρέσει μπορεί να του φτιάξω και κάνα cross-platform GTK/Cairo ui.

 

Και μάλλον θα το γυρίσω σε pure C, αφού το μόνο C++ που υπάρχει τώρα, αν έχω δει καλά, είναι το {} initialization.

 

Το αν και πότε θα γίνουν όλα αυτά, άγνωστο

 

Download: minesweeper_mingw32_02.7z (52.6Kb)

/* --------------------------------------------------
 * Coding Style Quick Notes:
 *
 * 1. Symbols starting with _ (under-bar) denote internal linkage.
 * 2. Vars starting with _g_ denote global vars with internal linkage.
 * 3. Vars starting with g_ denote global vars with external linkage.
 * 4. Preprocessor symbols are uppercase.
 * 5. Custom DataTypes are capitalized. May contain multiple capitalized words.
 * 6. Funcs are lowercase. May contain multiple words separated by _ (underbar).
 * 7. Vars are lowercase. May contain multiple capitalized words, but never
 *    the first one.
 * 8. The Eighty Column Rule is enforced (whenever possible).
 * --------------------------------------------------
 */

Όπως γράφω και στην παράθεση, έχουν επιπλέον φτιαχτεί κατάλληλα header files και η μεταβλητή UI έχει φύγει από global και περνιέται ως όρισμα στις ρουτίνες που την χρειάζονται. Ο ορισμός της γίνεται στο app entry point, στο win32_minesweeper.c.

 

Υπάρχουν κι άλλες global μεταβλητές που μπορούν να καταργηθούν, με ή χωρίς συνδυασμό διαφορετική οργάνωσης αρχείων και datatypes. Έχω αφήσει όμως την κατηγοριοποίηση που είχε κάνει ο φίλος bnvdarklord.

 

Τέλος, έβγαλα και τα C++ value initializations, και τα αντικατέστησα στο μεν core game με memset(), στο δε win32_minesweeper.c με ZeroMemory (έτσι κι αλλιώς όλα POD είναι). Οπότε έχουμε σχεδόν καθαρό C κώδικα (έχω ξεχάσει να κάνω typdef τα struct ή να ορίζω μεταβλητές τους με το struct keyword) οπότε το makefile το έχω αφήσει g++.

 

Για GTK/Cairo ui, ίδωμεν.

 

ΥΓ. Ο editor του φόρουμ πάει από το κακό στο χειρότερο.

[bnvdarklord]

@migf1 Έριξα μια γρήγορη ματιά στις αλλαγές σου και έγω κάποιες απορίες:

 

1) Ίσως είναι τελείως θέμα προσωπικό, αλλα πιστευεις αξίζει να κόβονται τα ονόματα μεταβλητών για χάρη του 80-column rule; (πχ gamememory.perm vs gamememory.permanent_storage)

 

2) Υπάρχει καλύτερος τρόπος να μειωθούν οι global μεταβλητές χωρίς να αρχικοποιούνται στο windows layer; Ρωτάω επειδή δεν μου πολυαρέσει η ιδέα να πρέπει το windows layer να ασχολείται με οτιδήποτε τελείως άσχετο με αυτό.(ίσως ενα struct game_state που να εχει μεσα ότι εχω σαν global ετσι ώστε απλά να περνάει αυτο το windows layer και να μην χρειάζεται συνεχως αλλαγες ; ) Και σαν επιπλέον ερώτηση - γιατί οι global μεταβλητές θεωρούνται κακή πρακτική;

 

3) Υπάρχει κάποιος λόγος που έκανες ZeroMemory στο game memory πριν το allocation, ή καθαρά τυπικά; Μιας και στις επόμενες γραμμές αρχικοποιούνται τα στοιχεια του struct.

 

http://www.insomnia.gr/topic/521538-c-δημιουργία-λαβυρίνθων/

 

https://github.com/InsomniaProjects/maze-generator

 

Δεν ασχολήθηκε κανείς (κρίμα).

Πωπω το είχα ξεχάσει αυτό τελείως.