Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

1

15.07.2014, 22:30

Hilfe bei Const in meiner Klasse

Abend,

da ich bis jetzt sogut wie nie Const bei meinen Funktionen benutzt habe und man es ja eigentlich so oft benutzen sollte wie es geht habe ich mich heute mal damit beschäftigt und eine kleine Klasse geschrieben die die beiden Klassen sf::Sprite und sf::Texture aus der SFML vereint. Ich würde jetzt gern wissen ob ich Const überall richtig verwendet habe und was es da noch zu verbessern gibt.

Hier der Code aus der hpp:


C-/C++-Quelltext

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
#ifndef MATERIAL_HPP
#define MATERIAL_HPP

#include <SFML/Graphics.hpp>

class Material
{
public:
    Material(const std::string &fileName);

    void move(float x, float y);

    void move(const sf::Vector2f &offset);

    void setPosition(float x, float y);

    void setPosition(const sf::Vector2f &pos);

    void setScale(float x, float y);

    void setRotation(float angle);

    void rotate(float angle);

    float getRotation() const;

    const sf::FloatRect &getGlobalBounds() const;

    bool checkBoundingCollision(const Material &material) const;

    const sf::Vector2f &getPosition() const;

    const sf::Sprite &getSprite() const;

    void changeTexture(const std::string &fileName);

    void changeTexture(const sf::Texture &texture);
private:
    sf::Texture mTexture;

    sf::Sprite mSprite;
};
#endif // MATERIAL_HPP


LG und schönen Abend noch.

Cranberry

Treue Seele

Beiträge: 312

Wohnort: Innsbruck, Tirol

  • Private Nachricht senden

2

15.07.2014, 23:11

Const ist vorallem wichtig bei Variablen die nie ihren Wert ändern, wie zum Beispiel die Zahl Pi.

In deinem Falle hast du const aber auch richtig angewendet. Nämlich bei Gettern.
Funktionen sollten dann konstant sein, wenn die Funktion keine Variablen ändert, vorallem aber nicht die Variable die du mit return zurück gibst.
Daher sollten Getter immer const sein. Ist zwar nicht zwingend notwendig, zeugt aber von gutem Stil.

EDIT: Warum heißt deine Klasse Material? Ein Material ist eher die Eigenschaft einer Oberfläche und wird von Shadern verwendet. Ich würde die Klasse RenderComponent nennen.

Lares

1x Contest-Sieger

  • Private Nachricht senden

3

15.07.2014, 23:13

Ansich sieht das soweit ganz gut aus mit den const.
Ich bin allerdings etwas von der Membervariable mTexture irritiert.
Sicher, dass du die benötigst? Ich gehe mal davon aus, dass das Sprite eh stets die "neuste" Textur durch changeTexture() zugewiesen bekommt oder?
Es ist auf langer Sicht sinnvoll, wenn man nicht für jedes Sprite die Textur extra speichert. Stell dir vor, du hast ein Spielfeld mit 100 Figuren, die alle die gleiche Textur haben. Warum 99 mal die Textur extra speichern?
Das ist auch der Grund, warum in der SFML Textur und Sprites getrennt wurden.

4

15.07.2014, 23:14

Zitat


Funktionen sollten dann konstant sein, wenn die Funktion keine Variablen ändert, vorallem aber nicht die Variable die du mit return zurück gibst.


Auch wenn die Variable nicht verändert werden soll? :O

Zitat


EDIT: Warum heißt deine Klasse Material? Ein Material ist eher die Eigenschaft einer Oberfläche und wird von Shadern verwendet. Ich würde die Klasse RenderComponent nennen.


Ich bin ziemlich unkreativ was sowas angeht :D

Zitat


Es ist auf langer Sicht sinnvoll, wenn man nicht für jedes Sprite die Textur extra speichert. Stell dir vor, du hast ein Spielfeld mit 100 Figuren, die alle die gleiche Textur haben. Warum 99 mal die Textur extra speichern?
Das ist auch der Grund, warum in der SFML Textur und Sprites getrennt wurden.


Da habe ich ehrlich gesagt noch die drüber nachgedacht danke für den Tipp! :) Ich habs bis jetzt immer so gemacht das meine Klassen jeweils eine Textur und ein Sprite hatten.

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

5

16.07.2014, 06:36

Ich bin allerdings etwas von der Membervariable mTexture irritiert.
Sicher, dass du die benötigst? Ich gehe mal davon aus, dass das Sprite eh stets die "neuste" Textur durch changeTexture() zugewiesen bekommt oder?

Vor allem nutzt er da keine Referenz oder sowas und erzeugt somit eine Kopie der Textur. Dasselbe gilt auch für das change mit string. Damit kann man sich prima seinen Ram vollmüllen, wenn man jede Textur mehrfach lädt.
Überhaupt sehe ich in der Klasse keinen Mehrwert. Sprite kann das auch alles schon.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

6

16.07.2014, 10:03

Überhaupt sehe ich in der Klasse keinen Mehrwert. Sprite kann das auch alles schon.

Ich habe mir auch eine "SmartSprite" Klasse geschrieben, die so angefangen hat. Die zusätzliche Funktionalität kam bei mir nach und nach rein, wenn ich bestimmte Dinge einfacher machen wollte und die Klasse wird immer noch erweitert.
Mögliche Anwendungen sind zum Beispiel das automatische Ein- oder Ausfaden des Sprites, ein "shake" oder "wobble", flashen oder andere graphische Effekte.

So Far...
Laguna
Portfolio runvs.io | Gamejolt | itch.io | PEWN | Twitter

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

7

16.07.2014, 10:10

Also baut man erst ohne konkreten Mehrwert zu haben und hofft, dass der später dazu kommt? Finde ich etwas merkwürdig.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

8

16.07.2014, 10:12

Wieso müssen denn Übungen immer besonders sinnvoll sein? Er hat doch eine explizite Frage gestellt, ob er const richtig angewendet hat und nicht ob seine Klasse sinnvoll ist.

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

9

16.07.2014, 10:35

Ja, ja, er wird das ja nur zur Übung machen und nicht verwenden. Schon klar. Aber mal andersherum gefragt, wieso sollte eine Übung nicht sinnvoll sein und wieso sollte man ihm nicht sagen dürfen, dass so eine Wrapper-Klasse total überflüssig ist? Es geht beim Üben doch darum etwas zu lernen. Und dann ist auch wichtig zu lernen nichts umsonst zu bauen.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

10

16.07.2014, 10:47

Ich habe nicht gesagt, dass eine Übung nicht sinnvoll sein DARF, sondern dass sie es nicht sein MUSS.
Ob er es weiter verwendet oder nicht ist doch vom Prinzip her auch erstmal egal. Er wird schon früh genug merken, ob er sich verrannt hat oder nicht, das macht eben eine Übung unter anderem auch aus. Trial&Error.
Ich denke einfach, dass es ihm (oder generell Anfängern) relativ wenig hilft, wenn man sich über solche Belanglosigkeiten echauffiert, obwohl das ganz klar keinen Fehler oder eine größere Gefahr darstellt.

Werbeanzeige