Evrey

Oberschurke im Ruhestand

  • »Evrey« ist der Autor dieses Themas

Motto: "Satzzeichen sind keine Rudeltiere." - Chesra

  • Nachricht senden

1

Dienstag, 5. Mai 2009, 17:14

C++ Operatoren? Wie das?

Sö, da ich nix aufklärendes fand, frage ich mal lieber die örtlichen C++-Experten^^
In Ruby isses ja nix sonderlich neues, mal eben einen Operator für seine Klasse zu schreiben, z.B. die Indexklammern für eine Array-Klasse:

Ruby Quellcode

1
2
3
4
5
6
def []()
  #blubb
end
def []=()
  #blubb
end

Meine Frage: Wie definiere ich so ziemlich alle Operatoren (Von + bis %= über &= usw. Alles halt.) in C++?
Anlass zur Frage: Ich will mir eine Klasse für seeehr große Zahlen schreiben (z.B. 256b) und so anpassen, wie ich es brauche. Gut, Code ist an sich fast fertig, aber mal im Ernst:
Das da...

Quellcode

1
2
3
INT512 a(3),b(4),c; // Große Zahlen würden diesen Post seeehr breit machen...
c = a.add0(4); // c=a+b
std::cout<< c.num0();

... sieht nicht nur beschissen aus, sondern ist auch nervig hässliches Getippe.

P.S.: Auch wenn es sich um Zahlen handelt, wo also theoretisch gesehen nur Mathe gebraucht würde, den Index-Operator und Bitmanipulation bräuchte ich ebenfalls ;)
  • :medal: Werbung

    Bild

    Cpp Quellcode

    1
    
    #define TRUE FALSE //Happy debugging suckers
    (Einfach nur wundervoll.)
  • :palette: 1plus3 :cake:

    Bild
  • :fires: Nuuuhminaaah

    Bild
  • :medal: compétences

    mes compétences
    :heart_full: :heart_full: :heart_full: :heart_full: :heart_full: max.
    :ruler-triangle: Maps machen :heart_full: :heart-empty: :heart-empty: :heart-empty: :heart-empty:
    :media-player: Musik machen :heart_full: :heart-half: :heart-empty: :heart-empty: :heart-empty:
    :cup: Scripts machen :heart_full: :heart_full: :heart_full: :heart_full: :heart-break:
    :paper: Story ausdenken :heart_full: :heart_full: :heart_full: :heart-empty: :heart-empty:
    :cut: Pixeln und so :heart-empty: :heart-empty: :heart-empty: :heart-empty: :heart-empty:
    :game: Events proggen :heart_full: :heart_full: :heart_full: :heart_full: :heart_full:
    (Dieser Tab ist rein satirisch.)
  • :folder-open: mes projets

    • :addressbook: Silentium
      :book: Name: Silentium
      :rmxp: Maker: Eigenbau (C++, x86-SSE/AVX-Assembly, Ruby/Lua)

      :paper: Story
      :game: NPCs
      :cup: Scripts
      :drill: Ressis
      :ruler-triangle: Maps
      :compile: Gesamt
      (3+4)% 42 69% 0815 -17.438 103.38% ± 6.3mm²

      (Die Tabelle erfüllt lediglich satirische Zwecke.)
    • :compile: Onyx
      Eine in C++ implementierte, modulare, plattformunabhängige, virtuelle Maschine. Die Test-Version ist bereits halb fertig. Ab dann gibt es vielleicht mehr Infos. Sie soll die auf dem ersten Blick LISP-artige und eigens dafür konstruierte Sprache Obsidian ausführen können. Experimentell wird auch ein Lua-Compiler für Onyx gebaut. Ziel ist eine leistungsfähige, virtuelle Maschine für beliebige Scriptsprachen. Theoretisch gesehen müsste man bloß noch einen kompatiblen Compiler schreiben, der Quellcode jener Sprache in Onyx-Assembly, oder direkt in Onyx-Bytecode übersetzt. Ob die jemand nutzen wird, ist eine andere Frage und nur ein sekundäres... nein, eher tertiäres Ziel dieser VM. Primär dient es mir lediglich dazu, mein Verständnis von Hardware, ISA, und Assembly zu vertiefen, sowie eigene Grenzen auszutesten.

      :exclamation: Warnung!
      Das Entwickeln einer virtuellen Maschine oder Programmiersprache (im wahnsinnigsten Fall beides) ist eine höchst komplizierte Tätigkeit, aus der viel Frust und Hirnmatsche hervor gehen. Sollte sich dennoch ein ähnlich wahnsinniger finden, der sowas zusammen schustern will, so lege ich ihm/ihr die folgenden Bücher ans Herz:
      • Compiler - Das Drachenbuch [978-3-8273-7097-6]
        Dieses Buch schlachtet ausführlich und leicht verständlich die Grundlagen bis hoch zu den Experten-Techniken des Compilerbaus aus. Es fängt mit der Automaten-Theorie und formalen Sprachen an, arbeitet sich durch Analysetechniken vor, und landet schließlich bei Techniken wie Optimierung und Register-Zuweisung. Das Buch wiegt 3Kg oder 4Kg. Hab's mal gewogen. Ist also nicht gerade die Lektüre für unterwegs.

      • Computerarchitektur [3-8273-7016-7]
        Hier werden leicht verständlich die wichtigsten Entwicklungen der Rechnerarchitekturen erklärt (Gut, das Buch ist in die Jahre gekommen, aber der Weg zu heute ist ein winziger Schritt, den man sich nach diesem Buch selbst erdenken kann). Hauptbestandteil des Buchs ist eine relativ umfassende Betrachtung der Funktionsweise dreier gänzlich unterschiedlicher, aber dominierender Prozessor-Typen am Beispiel des Pentium II, UltraSPARC II, sowie picoJava. Die meisten Elemente dieses Buchs sind zwar für die Konstruktion einer virtuellen Maschine irrelevant, oder aufgrund der Tatsache, dass die VM Software ist und z.B. Byte-Grenzen hat, sogar zu Leistungseinbußen führen kann, doch ist ein hinreichendes Verständnis dieser Maschinen, mit denen wir arbeiten, äußerst hilfreich für die Überlegungen, wie die VM arbeiten soll.

      Es kann sehr hilfreich und inspirierend sein, den Code quelloffener, virtueller Maschinen anderer Sprachen zu überfliegen. Meine Lieblings-Quelle war und ist stets die VM von Lua. Sie ist schlank, verständlich, in C implementiert, und basiert im Gegensatz zu vielen anderen Scriptsprachen-VMs auf einer Register-Maschine statt einer Stapelmaschine. Es wäre natürlich vorteilhaft, die entsprechende Sprache zu verstehen, in der man auch die eigene VM implementieren will. Weiterhin ist es äußerst vorteilhaft, eine leistungsstarke und bequeme Sprache wie C++ zu beherrschen, um die VM zu implementieren. Und bevor irgendwer auf die Idee kommt: Assembly ist NICHT als dominierende Sprache für den Bau einer VM geeignet. Wer die Frage des "Warum?" nicht beantworten kann, sollte zunächst die gewählte Sprache und Assembly hinreichend verstehen lernen, und es dann erneut mit der Frage versuchen. Es lohnt sich dennoch, Assembly zu lernen. Allein schon, um erneut das Verständnis zu vertiefen, zumal ihr mehr oder weniger gezwungen seid, auch für eure VM eine Assembler-Sprache zu entwickeln (Außer natürlich ihr schreibt eure Test-Programme Bit für Bit ;3).
  • :locale: enfin

    Je ne peux pas parler français.
    C'est tout ce que Goodle et les restes de cours de français.
Signaturstand: 24.07.2013

2

Dienstag, 5. Mai 2009, 18:31

C++ ist leider nicht so Programmierbar wie Ruby, daher kann man nicht wirklich diese Operatoren in Klassen einprogrammieren.

Daher musst du wirklich schon metthode wie add,minus,durch usw. schreiben.
Gamedev-Nation.org - Die freundliche Spieleentwickler Community

I am sick of it to be a beta nerd. So I have decided to become a alpha!

3

Dienstag, 5. Mai 2009, 18:48

Zitat

C++ ist leider nicht so Programmierbar wie Ruby, daher kann man nicht wirklich diese Operatoren in Klassen einprogrammieren.

Daher musst du wirklich schon metthode wie add,minus,durch usw. schreiben.

so ein schmarrn

es gibt 2 Möglichkeiten, entweder als freie Funktion:

Quellcode

1
2
3
4
dieKlasse operator+(dieKlasse const& a, dieKlasse const& b)
{
  //additionscode
}

oder als Member(weniger empfehlenswert):

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
class dieKlasse
{
  public:
    dieKlasse operator+(dieKlasse const& that) const;
  //und so weiter
};
//....
 
dieKlasse dieKlasse::operator+(dieKlasse const& that) const
{
  //additionscode
}


Index geht genau so(nur halt operator[](size_t index) z.B.) Bitmanipulation ist für Streams ja sogar überladen, geht genau so.

Das geht für fast alle vordefinierten Operatoren(mir fällt als Ausnahme gerade nur der . Operator ein, gibt aber bestimmt noch einen, jedenfalls lässt sich sogar (und ist auch oft nötig) der Zuweisungsoperator überladen), aber du kannst keine neuen Operatoren definieren(in Scala oder Haskell z.B. geht das, keine Ahnung ob das in Ruby geht, in C++ kannst du jedenfalls nur existierende Operatoren überladen)

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Ankou« (5. Mai 2009, 19:01)


Evrey

Oberschurke im Ruhestand

  • »Evrey« ist der Autor dieses Themas

Motto: "Satzzeichen sind keine Rudeltiere." - Chesra

  • Nachricht senden

4

Dienstag, 5. Mai 2009, 19:58

Ok wunderbar, das wollte ich wissen, danke!^^

Jetzt kann ich auch auf schöne Art an Zahlen wie z.B. Ackermann4/2 rankommen (~19700 Ziffern).
  • :medal: Werbung

    Bild

    Cpp Quellcode

    1
    
    #define TRUE FALSE //Happy debugging suckers
    (Einfach nur wundervoll.)
  • :palette: 1plus3 :cake:

    Bild
  • :fires: Nuuuhminaaah

    Bild
  • :medal: compétences

    mes compétences
    :heart_full: :heart_full: :heart_full: :heart_full: :heart_full: max.
    :ruler-triangle: Maps machen :heart_full: :heart-empty: :heart-empty: :heart-empty: :heart-empty:
    :media-player: Musik machen :heart_full: :heart-half: :heart-empty: :heart-empty: :heart-empty:
    :cup: Scripts machen :heart_full: :heart_full: :heart_full: :heart_full: :heart-break:
    :paper: Story ausdenken :heart_full: :heart_full: :heart_full: :heart-empty: :heart-empty:
    :cut: Pixeln und so :heart-empty: :heart-empty: :heart-empty: :heart-empty: :heart-empty:
    :game: Events proggen :heart_full: :heart_full: :heart_full: :heart_full: :heart_full:
    (Dieser Tab ist rein satirisch.)
  • :folder-open: mes projets

    • :addressbook: Silentium
      :book: Name: Silentium
      :rmxp: Maker: Eigenbau (C++, x86-SSE/AVX-Assembly, Ruby/Lua)

      :paper: Story
      :game: NPCs
      :cup: Scripts
      :drill: Ressis
      :ruler-triangle: Maps
      :compile: Gesamt
      (3+4)% 42 69% 0815 -17.438 103.38% ± 6.3mm²

      (Die Tabelle erfüllt lediglich satirische Zwecke.)
    • :compile: Onyx
      Eine in C++ implementierte, modulare, plattformunabhängige, virtuelle Maschine. Die Test-Version ist bereits halb fertig. Ab dann gibt es vielleicht mehr Infos. Sie soll die auf dem ersten Blick LISP-artige und eigens dafür konstruierte Sprache Obsidian ausführen können. Experimentell wird auch ein Lua-Compiler für Onyx gebaut. Ziel ist eine leistungsfähige, virtuelle Maschine für beliebige Scriptsprachen. Theoretisch gesehen müsste man bloß noch einen kompatiblen Compiler schreiben, der Quellcode jener Sprache in Onyx-Assembly, oder direkt in Onyx-Bytecode übersetzt. Ob die jemand nutzen wird, ist eine andere Frage und nur ein sekundäres... nein, eher tertiäres Ziel dieser VM. Primär dient es mir lediglich dazu, mein Verständnis von Hardware, ISA, und Assembly zu vertiefen, sowie eigene Grenzen auszutesten.

      :exclamation: Warnung!
      Das Entwickeln einer virtuellen Maschine oder Programmiersprache (im wahnsinnigsten Fall beides) ist eine höchst komplizierte Tätigkeit, aus der viel Frust und Hirnmatsche hervor gehen. Sollte sich dennoch ein ähnlich wahnsinniger finden, der sowas zusammen schustern will, so lege ich ihm/ihr die folgenden Bücher ans Herz:
      • Compiler - Das Drachenbuch [978-3-8273-7097-6]
        Dieses Buch schlachtet ausführlich und leicht verständlich die Grundlagen bis hoch zu den Experten-Techniken des Compilerbaus aus. Es fängt mit der Automaten-Theorie und formalen Sprachen an, arbeitet sich durch Analysetechniken vor, und landet schließlich bei Techniken wie Optimierung und Register-Zuweisung. Das Buch wiegt 3Kg oder 4Kg. Hab's mal gewogen. Ist also nicht gerade die Lektüre für unterwegs.

      • Computerarchitektur [3-8273-7016-7]
        Hier werden leicht verständlich die wichtigsten Entwicklungen der Rechnerarchitekturen erklärt (Gut, das Buch ist in die Jahre gekommen, aber der Weg zu heute ist ein winziger Schritt, den man sich nach diesem Buch selbst erdenken kann). Hauptbestandteil des Buchs ist eine relativ umfassende Betrachtung der Funktionsweise dreier gänzlich unterschiedlicher, aber dominierender Prozessor-Typen am Beispiel des Pentium II, UltraSPARC II, sowie picoJava. Die meisten Elemente dieses Buchs sind zwar für die Konstruktion einer virtuellen Maschine irrelevant, oder aufgrund der Tatsache, dass die VM Software ist und z.B. Byte-Grenzen hat, sogar zu Leistungseinbußen führen kann, doch ist ein hinreichendes Verständnis dieser Maschinen, mit denen wir arbeiten, äußerst hilfreich für die Überlegungen, wie die VM arbeiten soll.

      Es kann sehr hilfreich und inspirierend sein, den Code quelloffener, virtueller Maschinen anderer Sprachen zu überfliegen. Meine Lieblings-Quelle war und ist stets die VM von Lua. Sie ist schlank, verständlich, in C implementiert, und basiert im Gegensatz zu vielen anderen Scriptsprachen-VMs auf einer Register-Maschine statt einer Stapelmaschine. Es wäre natürlich vorteilhaft, die entsprechende Sprache zu verstehen, in der man auch die eigene VM implementieren will. Weiterhin ist es äußerst vorteilhaft, eine leistungsstarke und bequeme Sprache wie C++ zu beherrschen, um die VM zu implementieren. Und bevor irgendwer auf die Idee kommt: Assembly ist NICHT als dominierende Sprache für den Bau einer VM geeignet. Wer die Frage des "Warum?" nicht beantworten kann, sollte zunächst die gewählte Sprache und Assembly hinreichend verstehen lernen, und es dann erneut mit der Frage versuchen. Es lohnt sich dennoch, Assembly zu lernen. Allein schon, um erneut das Verständnis zu vertiefen, zumal ihr mehr oder weniger gezwungen seid, auch für eure VM eine Assembler-Sprache zu entwickeln (Außer natürlich ihr schreibt eure Test-Programme Bit für Bit ;3).
  • :locale: enfin

    Je ne peux pas parler français.
    C'est tout ce que Goodle et les restes de cours de français.
Signaturstand: 24.07.2013

5

Dienstag, 5. Mai 2009, 20:44

Zitat

C++ ist leider nicht so Programmierbar wie Ruby, daher kann man nicht wirklich diese Operatoren in Klassen einprogrammieren.

Daher musst du wirklich schon metthode wie add,minus,durch usw. schreiben.

so ein schmarrn

es gibt 2 Möglichkeiten, entweder als freie Funktion:

Quellcode

1
2
3
4
dieKlasse operator+(dieKlasse const& a, dieKlasse const& b)
{
  //additionscode
}

oder als Member(weniger empfehlenswert):

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
class dieKlasse
{
  public:
    dieKlasse operator+(dieKlasse const& that) const;
  //und so weiter
};
//....
 
dieKlasse dieKlasse::operator+(dieKlasse const& that) const
{
  //additionscode
}


Index geht genau so(nur halt operator[](size_t index) z.B.) Bitmanipulation ist für Streams ja sogar überladen, geht genau so.

Das geht für fast alle vordefinierten Operatoren(mir fällt als Ausnahme gerade nur der . Operator ein, gibt aber bestimmt noch einen, jedenfalls lässt sich sogar (und ist auch oft nötig) der Zuweisungsoperator überladen), aber du kannst keine neuen Operatoren definieren(in Scala oder Haskell z.B. geht das, keine Ahnung ob das in Ruby geht, in C++ kannst du jedenfalls nur existierende Operatoren überladen)

Danke, wieder was gelern!
Gamedev-Nation.org - Die freundliche Spieleentwickler Community

I am sick of it to be a beta nerd. So I have decided to become a alpha!

6

Sonntag, 10. Mai 2009, 21:24

Was ich dennoch etwas blöd an C++ finde ist das man nicht so welche Getter und Setter Methoden hinkriegt wie in Ruby:

Quellcode

1
2
3
4
5
6
7
8
class A
  def initialize
    @var = 0
  den
  def var=(var)
    @var = var
  den
end

Quellcode

1
2
a = A.new
a.var = 15

So was kann man in C++ nicht machen...(oder?)

7

Sonntag, 10. Mai 2009, 21:40

Doch klar. Genau das hat Ankou auch zwei Posts über dir beschrieben ;)

Drag-On

8

Sonntag, 10. Mai 2009, 21:51

Das gilt nur für die Klasse selbst aber nicht für die Klassenvaraiblen.
Was Ankou beschreiben hat war das überschreiben von Operatorn der Klasse.
Mit der Funktion kann man dann Object und Object addieren.
Was ich aber meine sind die Getter und Settter Methoden die einfach mit attr_reader, attr_writer oder attr_accessor erstellt werden können.
Oder eben durch eine Methode:

Quellcode

1
2
3
4
5
6
7
8
class A
  def initialize
    @var = 0
  den
  def var=(var)
    @var = var
  den
end

So was hab ich aber noch nicht in C++ gesehen.

Evrey

Oberschurke im Ruhestand

  • »Evrey« ist der Autor dieses Themas

Motto: "Satzzeichen sind keine Rudeltiere." - Chesra

  • Nachricht senden

9

Sonntag, 10. Mai 2009, 22:57

Wieso? Es müsste nur anders aussehen o__O"
Z.B.:

Quellcode

1
2
3
4
SupertolleKlasse operator=(int &num0)
{
    this->num0 = num0;
}

Oder so in etwa o__O"
  • :medal: Werbung

    Bild

    Cpp Quellcode

    1
    
    #define TRUE FALSE //Happy debugging suckers
    (Einfach nur wundervoll.)
  • :palette: 1plus3 :cake:

    Bild
  • :fires: Nuuuhminaaah

    Bild
  • :medal: compétences

    mes compétences
    :heart_full: :heart_full: :heart_full: :heart_full: :heart_full: max.
    :ruler-triangle: Maps machen :heart_full: :heart-empty: :heart-empty: :heart-empty: :heart-empty:
    :media-player: Musik machen :heart_full: :heart-half: :heart-empty: :heart-empty: :heart-empty:
    :cup: Scripts machen :heart_full: :heart_full: :heart_full: :heart_full: :heart-break:
    :paper: Story ausdenken :heart_full: :heart_full: :heart_full: :heart-empty: :heart-empty:
    :cut: Pixeln und so :heart-empty: :heart-empty: :heart-empty: :heart-empty: :heart-empty:
    :game: Events proggen :heart_full: :heart_full: :heart_full: :heart_full: :heart_full:
    (Dieser Tab ist rein satirisch.)
  • :folder-open: mes projets

    • :addressbook: Silentium
      :book: Name: Silentium
      :rmxp: Maker: Eigenbau (C++, x86-SSE/AVX-Assembly, Ruby/Lua)

      :paper: Story
      :game: NPCs
      :cup: Scripts
      :drill: Ressis
      :ruler-triangle: Maps
      :compile: Gesamt
      (3+4)% 42 69% 0815 -17.438 103.38% ± 6.3mm²

      (Die Tabelle erfüllt lediglich satirische Zwecke.)
    • :compile: Onyx
      Eine in C++ implementierte, modulare, plattformunabhängige, virtuelle Maschine. Die Test-Version ist bereits halb fertig. Ab dann gibt es vielleicht mehr Infos. Sie soll die auf dem ersten Blick LISP-artige und eigens dafür konstruierte Sprache Obsidian ausführen können. Experimentell wird auch ein Lua-Compiler für Onyx gebaut. Ziel ist eine leistungsfähige, virtuelle Maschine für beliebige Scriptsprachen. Theoretisch gesehen müsste man bloß noch einen kompatiblen Compiler schreiben, der Quellcode jener Sprache in Onyx-Assembly, oder direkt in Onyx-Bytecode übersetzt. Ob die jemand nutzen wird, ist eine andere Frage und nur ein sekundäres... nein, eher tertiäres Ziel dieser VM. Primär dient es mir lediglich dazu, mein Verständnis von Hardware, ISA, und Assembly zu vertiefen, sowie eigene Grenzen auszutesten.

      :exclamation: Warnung!
      Das Entwickeln einer virtuellen Maschine oder Programmiersprache (im wahnsinnigsten Fall beides) ist eine höchst komplizierte Tätigkeit, aus der viel Frust und Hirnmatsche hervor gehen. Sollte sich dennoch ein ähnlich wahnsinniger finden, der sowas zusammen schustern will, so lege ich ihm/ihr die folgenden Bücher ans Herz:
      • Compiler - Das Drachenbuch [978-3-8273-7097-6]
        Dieses Buch schlachtet ausführlich und leicht verständlich die Grundlagen bis hoch zu den Experten-Techniken des Compilerbaus aus. Es fängt mit der Automaten-Theorie und formalen Sprachen an, arbeitet sich durch Analysetechniken vor, und landet schließlich bei Techniken wie Optimierung und Register-Zuweisung. Das Buch wiegt 3Kg oder 4Kg. Hab's mal gewogen. Ist also nicht gerade die Lektüre für unterwegs.

      • Computerarchitektur [3-8273-7016-7]
        Hier werden leicht verständlich die wichtigsten Entwicklungen der Rechnerarchitekturen erklärt (Gut, das Buch ist in die Jahre gekommen, aber der Weg zu heute ist ein winziger Schritt, den man sich nach diesem Buch selbst erdenken kann). Hauptbestandteil des Buchs ist eine relativ umfassende Betrachtung der Funktionsweise dreier gänzlich unterschiedlicher, aber dominierender Prozessor-Typen am Beispiel des Pentium II, UltraSPARC II, sowie picoJava. Die meisten Elemente dieses Buchs sind zwar für die Konstruktion einer virtuellen Maschine irrelevant, oder aufgrund der Tatsache, dass die VM Software ist und z.B. Byte-Grenzen hat, sogar zu Leistungseinbußen führen kann, doch ist ein hinreichendes Verständnis dieser Maschinen, mit denen wir arbeiten, äußerst hilfreich für die Überlegungen, wie die VM arbeiten soll.

      Es kann sehr hilfreich und inspirierend sein, den Code quelloffener, virtueller Maschinen anderer Sprachen zu überfliegen. Meine Lieblings-Quelle war und ist stets die VM von Lua. Sie ist schlank, verständlich, in C implementiert, und basiert im Gegensatz zu vielen anderen Scriptsprachen-VMs auf einer Register-Maschine statt einer Stapelmaschine. Es wäre natürlich vorteilhaft, die entsprechende Sprache zu verstehen, in der man auch die eigene VM implementieren will. Weiterhin ist es äußerst vorteilhaft, eine leistungsstarke und bequeme Sprache wie C++ zu beherrschen, um die VM zu implementieren. Und bevor irgendwer auf die Idee kommt: Assembly ist NICHT als dominierende Sprache für den Bau einer VM geeignet. Wer die Frage des "Warum?" nicht beantworten kann, sollte zunächst die gewählte Sprache und Assembly hinreichend verstehen lernen, und es dann erneut mit der Frage versuchen. Es lohnt sich dennoch, Assembly zu lernen. Allein schon, um erneut das Verständnis zu vertiefen, zumal ihr mehr oder weniger gezwungen seid, auch für eure VM eine Assembler-Sprache zu entwickeln (Außer natürlich ihr schreibt eure Test-Programme Bit für Bit ;3).
  • :locale: enfin

    Je ne peux pas parler français.
    C'est tout ce que Goodle et les restes de cours de français.
Signaturstand: 24.07.2013

10

Sonntag, 10. Mai 2009, 23:30

Wozu Accessor-Methoden, wenn du öffentliche Attribute definieren kannst? Sowas macht nur Sinn, wenn du entweder reinen Lese-Zugriff definieren willst (für sowas kannst du dir auch Macros schreiben. Die arbeiten dann ähnlich wie attr_reader), oder wenn du während des Zugriffs auf die Variable noch eigenen Code ausführen willst (in diesem Fall kommst du um eine eigene Methode nicht herum).
Bild
RMXP Grundkurs
1 2 3
Ruby/RGSS-Kurs

Evrey

Oberschurke im Ruhestand

  • »Evrey« ist der Autor dieses Themas

Motto: "Satzzeichen sind keine Rudeltiere." - Chesra

  • Nachricht senden

11

Sonntag, 10. Mai 2009, 23:34

Oh stimmt xD

Quellcode

1
2
public:
  int dingens;

hat ja dieselben Fähigkeiten wie der accessor o__O"
  • :medal: Werbung

    Bild

    Cpp Quellcode

    1
    
    #define TRUE FALSE //Happy debugging suckers
    (Einfach nur wundervoll.)
  • :palette: 1plus3 :cake:

    Bild
  • :fires: Nuuuhminaaah

    Bild
  • :medal: compétences

    mes compétences
    :heart_full: :heart_full: :heart_full: :heart_full: :heart_full: max.
    :ruler-triangle: Maps machen :heart_full: :heart-empty: :heart-empty: :heart-empty: :heart-empty:
    :media-player: Musik machen :heart_full: :heart-half: :heart-empty: :heart-empty: :heart-empty:
    :cup: Scripts machen :heart_full: :heart_full: :heart_full: :heart_full: :heart-break:
    :paper: Story ausdenken :heart_full: :heart_full: :heart_full: :heart-empty: :heart-empty:
    :cut: Pixeln und so :heart-empty: :heart-empty: :heart-empty: :heart-empty: :heart-empty:
    :game: Events proggen :heart_full: :heart_full: :heart_full: :heart_full: :heart_full:
    (Dieser Tab ist rein satirisch.)
  • :folder-open: mes projets

    • :addressbook: Silentium
      :book: Name: Silentium
      :rmxp: Maker: Eigenbau (C++, x86-SSE/AVX-Assembly, Ruby/Lua)

      :paper: Story
      :game: NPCs
      :cup: Scripts
      :drill: Ressis
      :ruler-triangle: Maps
      :compile: Gesamt
      (3+4)% 42 69% 0815 -17.438 103.38% ± 6.3mm²

      (Die Tabelle erfüllt lediglich satirische Zwecke.)
    • :compile: Onyx
      Eine in C++ implementierte, modulare, plattformunabhängige, virtuelle Maschine. Die Test-Version ist bereits halb fertig. Ab dann gibt es vielleicht mehr Infos. Sie soll die auf dem ersten Blick LISP-artige und eigens dafür konstruierte Sprache Obsidian ausführen können. Experimentell wird auch ein Lua-Compiler für Onyx gebaut. Ziel ist eine leistungsfähige, virtuelle Maschine für beliebige Scriptsprachen. Theoretisch gesehen müsste man bloß noch einen kompatiblen Compiler schreiben, der Quellcode jener Sprache in Onyx-Assembly, oder direkt in Onyx-Bytecode übersetzt. Ob die jemand nutzen wird, ist eine andere Frage und nur ein sekundäres... nein, eher tertiäres Ziel dieser VM. Primär dient es mir lediglich dazu, mein Verständnis von Hardware, ISA, und Assembly zu vertiefen, sowie eigene Grenzen auszutesten.

      :exclamation: Warnung!
      Das Entwickeln einer virtuellen Maschine oder Programmiersprache (im wahnsinnigsten Fall beides) ist eine höchst komplizierte Tätigkeit, aus der viel Frust und Hirnmatsche hervor gehen. Sollte sich dennoch ein ähnlich wahnsinniger finden, der sowas zusammen schustern will, so lege ich ihm/ihr die folgenden Bücher ans Herz:
      • Compiler - Das Drachenbuch [978-3-8273-7097-6]
        Dieses Buch schlachtet ausführlich und leicht verständlich die Grundlagen bis hoch zu den Experten-Techniken des Compilerbaus aus. Es fängt mit der Automaten-Theorie und formalen Sprachen an, arbeitet sich durch Analysetechniken vor, und landet schließlich bei Techniken wie Optimierung und Register-Zuweisung. Das Buch wiegt 3Kg oder 4Kg. Hab's mal gewogen. Ist also nicht gerade die Lektüre für unterwegs.

      • Computerarchitektur [3-8273-7016-7]
        Hier werden leicht verständlich die wichtigsten Entwicklungen der Rechnerarchitekturen erklärt (Gut, das Buch ist in die Jahre gekommen, aber der Weg zu heute ist ein winziger Schritt, den man sich nach diesem Buch selbst erdenken kann). Hauptbestandteil des Buchs ist eine relativ umfassende Betrachtung der Funktionsweise dreier gänzlich unterschiedlicher, aber dominierender Prozessor-Typen am Beispiel des Pentium II, UltraSPARC II, sowie picoJava. Die meisten Elemente dieses Buchs sind zwar für die Konstruktion einer virtuellen Maschine irrelevant, oder aufgrund der Tatsache, dass die VM Software ist und z.B. Byte-Grenzen hat, sogar zu Leistungseinbußen führen kann, doch ist ein hinreichendes Verständnis dieser Maschinen, mit denen wir arbeiten, äußerst hilfreich für die Überlegungen, wie die VM arbeiten soll.

      Es kann sehr hilfreich und inspirierend sein, den Code quelloffener, virtueller Maschinen anderer Sprachen zu überfliegen. Meine Lieblings-Quelle war und ist stets die VM von Lua. Sie ist schlank, verständlich, in C implementiert, und basiert im Gegensatz zu vielen anderen Scriptsprachen-VMs auf einer Register-Maschine statt einer Stapelmaschine. Es wäre natürlich vorteilhaft, die entsprechende Sprache zu verstehen, in der man auch die eigene VM implementieren will. Weiterhin ist es äußerst vorteilhaft, eine leistungsstarke und bequeme Sprache wie C++ zu beherrschen, um die VM zu implementieren. Und bevor irgendwer auf die Idee kommt: Assembly ist NICHT als dominierende Sprache für den Bau einer VM geeignet. Wer die Frage des "Warum?" nicht beantworten kann, sollte zunächst die gewählte Sprache und Assembly hinreichend verstehen lernen, und es dann erneut mit der Frage versuchen. Es lohnt sich dennoch, Assembly zu lernen. Allein schon, um erneut das Verständnis zu vertiefen, zumal ihr mehr oder weniger gezwungen seid, auch für eure VM eine Assembler-Sprache zu entwickeln (Außer natürlich ihr schreibt eure Test-Programme Bit für Bit ;3).
  • :locale: enfin

    Je ne peux pas parler français.
    C'est tout ce que Goodle et les restes de cours de français.
Signaturstand: 24.07.2013

12

Sonntag, 10. Mai 2009, 23:55

Das wiederspricht dann aber voll dem Prinzip der Datenkapselung.
public:
entspricht auch nicht den Accessors, weil man in Ruby die accessors leicht durch getter und setter ersetzen kann und in C++ nicht, wodurch die Datenkapselung flöten geht.

Wie auch immer, in C++ geht vieles, was nicht direkt unterstützt wird.
Das Beispiel, das ich gerade geschrieben habe implementiert zwar Propertys, funktioniert aber nicht, wenn Operatoren auf die Propertys angewand werden sollen. Das kann man mit Operatorenüberladung zwar noch nachrüsten, aber gerade der wichtige . Operator könnte Probleme bereiten. Auch mit Templates oder variadic functions könnte es hier Probleme geben. (Das Problem besteht immer dann wenn nicht gecastet wird
Eine Alternative die mir einfällt, wäre, dass man den getter irgendwie durch Makros implementiert, darüber müsst ich jetzt nochmal nachdenken, ob das geht. Jedenfalls rate ich dringend davon ab, so etwas in produktivem Code zu versuchen, aber hier mal das Beispiel.

Quellcode

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
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
#include <iostream>
#include <boost/function.hpp>
#include <boost/bind.hpp>
 
using namespace std;
using namespace boost;
 
template <typename propertyT>
class property
  {
  public:
    property(function<void (propertyT const&)> const& setter, function<propertyT ()> const& getter);
    propertyT operator=(propertyT const& val);
    operator propertyT();
  private:
    function<void (propertyT const&)> m_setter;
    function<propertyT ()> m_getter;
  };
 
template <typename propertyT>
property<propertyT>::property(function<void (propertyT const&)> const& setter, function<propertyT ()> const& getter) :
  m_setter(setter),
  m_getter(getter)
  {}
 
template <typename propertyT>
propertyT property<propertyT>::operator=(propertyT const& val)
  {
  m_setter(val);
  return val;
  }
 
template <typename propertyT>
property<propertyT>::operator propertyT()
  {
  return m_getter();
  }
 
//Ab hier beginnt das Nutzungsbeispiel:
class example
  {
  public:
    example();
    string get_prop();
    void set_prop(string const& val);
    property<string> prop;
  private:
    string m_prop;
  };
 
example::example() :
  prop(bind(&example::set_prop, this, _1), bind(&example::get_prop, this))
  {}
 
string example::get_prop()
  {
  cout << "get " << m_prop << endl;
  return m_prop;
  }
 
void example::set_prop(string const& val)
  {
  cout << "set " << val << endl;
  m_prop = val;
  }
 
int main()
  {
  example ex;
  ex.prop = "hi"; //gibt zusätzlich noch set hi aus
  string a(ex.prop); //get hi
  }

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Ankou« (11. Mai 2009, 00:03)


13

Montag, 11. Mai 2009, 00:19

Warum geht da die Datenkapselung flöten? Entweder ich mache Attribute öffentlich zugänglich, oder mein Objekt verwaltet seine Attribute selbst. attr_accessor sorgt für ersteres. Der Umweg über die Methode interessiert ja nicht, da die Methode ohnehin nicht mehr macht als eine Attributzuweisung/rückgabe.

Und ob man nun foo.bla = 5 schreibt oder das javatypische foo.setBla(5) ist doch irgendwo egal. In C/C++ wird nunmal zwischen Funktion und Attribut unterschieden. Code zu schreiben, der Funktionen wie Attribute aussehen lässt, find ich dann schon irgendwo etwas gruselig (auch wenns beeindruckend ist, wie du das hingekriegt hast). Das geht ja schon richtung Rails, wo auch massiv rumgetrickst wird um den Code irgendwie "magischer" aussehen zu lassen, mit dem Resultat, dass es schwieriger wird die interne Arbeitsweise des Codes zu verstehen.
Bild
RMXP Grundkurs
1 2 3
Ruby/RGSS-Kurs

14

Montag, 11. Mai 2009, 13:11

Zitat

Warum geht da die Datenkapselung flöten? Entweder ich mache Attribute öffentlich zugänglich, oder mein Objekt verwaltet seine Attribute selbst. attr_accessor sorgt für ersteres. Der Umweg über die Methode interessiert ja nicht, da die Methode ohnehin nicht mehr macht als eine Attributzuweisung/rückgabe.

Datenkapselung bedeuted, dass man den internen Code was das Attribut angeht ändern kann ohne etwas am Externen zu ändern.
Das ist in Ruby gegeben, weil man den öffentlichen Member jederzeit durch eigene getter und setter ersetzen kann.
Das ist in C++ nicht gegeben, weil das syntaktische Änderung nach sich zieht(Attributsyntax durch Funktionssyntax ersetzen).

was das andere angeht bin ich deiner Meinung, in C++ sollte man getter und setter als Methoden schreiben

Social Bookmarks