AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

c++ vs delphi

Ein Thema von Lesco · begonnen am 4. Apr 2005 · letzter Beitrag vom 9. Apr 2005
Antwort Antwort
Seite 5 von 10   « Erste     345 67     Letzte »    
tommie-lie
(Gast)

n/a Beiträge
 
#41

Re: c++ vs delphi

  Alt 5. Apr 2005, 16:01
Zitat von Binärbaum:
Code:
{
  int a;
  char b;

  b= 'A';
  a= 7;
  b= b+a;///na, was sagst du dazu?
}
Dazu sage ich, daß das eines der Dinge ist, die mir an C gefallen, nämlich daß die Daten so gehandhabt werden, wie sie für den Prozessor vorliegen und der Programmierer nicht meilenweit von der Architektur alles mit Samthandschuhen serviert bekommt.
Der C-Char und der Delphi-Char sind zwei verschiedene Datentypen. Ein Char in C ist nur ein Byte, was auch immer ich darin speichere und als was auch immer ich dieses Byte interpretiere. "c = 'A'" ist eine Zuweisung, wobei "'A'" zwar vom Menschen als Buchstabe interpretiert wird, in Wirklichkeit jedoch nichts anderes als die Zahl 65 ist. Genauso wie ShortInt und LongInt in Delphi sind auch char und int in C zuweisungskompatibel. b enthält danach den Wert 65+7=72. Versuche ich das wieder als Zeichen zu interpretieren (indem ich es ohne in einen String umzuwandeln ausgebe, kriege ich das Zeichen "H", aber nur, weil die Konsole die Zahl 72 aus dem Buffer als H auf den Bidlschirm pinselt.
Die korrekte Delphi-Übersetzung wäre also eher:
Delphi-Quellcode:
var
  a: LongInt;
  b: ShortInt;
begin
  b := Ord('A'); //(oder "b := Byte('A');", ich weiß nicht, ob der Compiler sowas zulässt,
                 // vielleicht geht auch schon das implizite Casting mit "b := 'A';"
  a := 7;
  b := b + a;
end;

Zitat von malo:
Bei folgendem Code kommt aber auch eine AV
Code:
{
  printf(b);
}
Klar, bei
Delphi-Quellcode:
var
  x: PLongWord;
begin
  x := nil;
  x^ := 123;
end;
kommt auch eine

Wenn man printf() richtig anwendet, kommt keine Zugriffsverletzung, sondern wie oben gesagt ein "H", da b (72) als ASCII-Zeichen (%c) interpretiert wird:
Code:
{
  int a;
  char b;

  b= 'A';
  a= 7;
  b= b+a;///na, was sagst du dazu?
  printf("%c", b);
}
So, nu aber Schluß mit dem versuchten Beweis, daß C das Böse[tm] selbst ist.



Zitat von mael:
Es bleibt natürlich der Nachteil der Header-Übersetzungen (ist aber eigentlich nur fürs DDK relevant).
Und für FreePascal, wenn man's unter Linux einsetzen will

Zitat von mael:
Diese peinliche Superhero Werbung von Borland ist ja auch dem Delphi-Ansehen nicht gerade zuträglich.
Vielleicht Kompensation für einen kleinen... Entwicklungsstand
Und Hunde die Bellen, beißen nicht...


Edit: Mann, mann, nichtmal taggen kann ich richtig
  Mit Zitat antworten Zitat
Benutzerbild von Binärbaum
Binärbaum

Registriert seit: 19. Jan 2005
Ort: Elstra
764 Beiträge
 
Delphi 7 Enterprise
 
#42

Re: c++ vs delphi

  Alt 5. Apr 2005, 16:04
Zitat von bigg:
Zitat:
Bei folgendem Code kommt aber auch eine AV
ja und genau das kann unvorhergesehene Fehler verursachen,
kann aber auch Vorteile haben.
Ich sehe im Moment keine Vorteile an einer AV außer dass man damit ziemlich abrupt das Programm beenden kann. Aber dafür gibt es doch bessere Möglichkeiten.
Also IMHO sollte der Compiler sowas auch erkennen, wenn schon zur Compilerzeit klar ist, dass durch den Code eine AV ausgelöst wird. Aber das geht jetzt schon mehr in Richtung Compiler als Sprache...

MfG
Binärbaum
There are exactly 10 kinds of people: those who understand binary, and those who don't.
---
"Software reift beim Kunden. Bei Hardware ist es anders: Hardware fault beim Kunden." - Rainer G. Spallek
  Mit Zitat antworten Zitat
Michael_Bayer

Registriert seit: 20. Mär 2005
137 Beiträge
 
Delphi 7 Enterprise
 
#43

Re: c++ vs delphi

  Alt 5. Apr 2005, 16:05
Ich glaube, das sagt einiges:
Monster.de Sucherergebnis (leider keine Trefferanzahl - nur Seitenzahl)

Suche nach C++: 18 Seiten
Suche nach Delphi: 1 Seite
Suche nach C#: 3 Seiten

Man beachte, dass C# die "jüngste" Sprache ist...
  Mit Zitat antworten Zitat
bigg
(Gast)

n/a Beiträge
 
#44

Re: c++ vs delphi

  Alt 5. Apr 2005, 16:07
Zitat:
Ich sehe im Moment keine Vorteile an einer AV
Die muss doch nicht zwangsweise immer auftretten
In diesem Fall ist das natürlich ... äh ... doof
  Mit Zitat antworten Zitat
Benutzerbild von sECuRE
sECuRE

Registriert seit: 10. Apr 2003
Ort: Heidelberg
360 Beiträge
 
Delphi 7 Professional
 
#45

Re: c++ vs delphi

  Alt 5. Apr 2005, 16:28
Hi,


Zitat von Pseudemys Nelsoni:
Zitat:
C++ soll angeblich leichter sein als C
Kaum, da C++ eine Obermenge von C ist, d.h alles was in C geht, geht auch in C++. Demnach kann C++ höchstens schwerer(wenn überhaupt) sein als C.
nunja, in C++ steht dir die STL zur Verfügung, die insbesondere das Handling der Strings einfacher macht.

cu
  Mit Zitat antworten Zitat
Benutzerbild von mael
mael

Registriert seit: 13. Jan 2005
391 Beiträge
 
Delphi XE3 Professional
 
#46

Re: c++ vs delphi

  Alt 5. Apr 2005, 17:09
Zitat von tommie-lie:
Zitat von mael:
Es bleibt natürlich der Nachteil der Header-Übersetzungen (ist aber eigentlich nur fürs DDK relevant).
Und für FreePascal, wenn man's unter Linux einsetzen will
Die wichtigen Dinger sind schon übersetzt, wie gesagt, ich halte nichts davon zuviel Fremdkode zu verwenden. Programme die so geschrieben sind neigen zu Blähungen (siehe mal Adobe Reader, die Liste der Fremdbeiträge ist enorm) und Fehlern. Immer das Neuste zu verwenden ist auch nicht unbedingt gut. Okay jetzt sage ich es: ich finde GTK, Qt schei*e, auch wenn es dafürÜbersetzungen gibt. Man schaue sich mal die GUIs an, überall kleine Fehler, nicht das Standardaussehen, eigene Komponenten anstatt die des OS (z.B. Dateidialog). Das ist nicht was man als Firma gebrauchen kann. Linux ist eher fürs Web/Server Zeugs im kommerziellen Bereich interessant, und dafür hat man mit Kylix oder FreePascal was man braucht.

Zitat von tommie-lie:
Zitat von mael:
Diese peinliche Superhero Werbung von Borland ist ja auch dem Delphi-Ansehen nicht gerade zuträglich.
Vielleicht Kompensation für einen kleinen... Entwicklungsstand
Und Hunde die Bellen, beißen nicht...
Soweit würde ich nicht gehen, ich finde eher daß die Entwicklung nicht weiter geht. Zuviel Zeit wird in Zusatzkomponenten investiert anstatt die Kern-Eigenschaften zu verbessern, wie Kompiler und Sprache. U.a. einer der Gründe warum ich Datenbanken und Webzeugs nicht so mag, sie ziehen zuviele Resourcen auf sich.
HxD, schneller Hexeditor:
http://mh-nexus.de/hxd
  Mit Zitat antworten Zitat
tommie-lie
(Gast)

n/a Beiträge
 
#47

Re: c++ vs delphi

  Alt 5. Apr 2005, 17:43
Zitat von mael:
Zitat von tommie-lie:
Zitat von mael:
Es bleibt natürlich der Nachteil der Header-Übersetzungen (ist aber eigentlich nur fürs DDK relevant).
Und für FreePascal, wenn man's unter Linux einsetzen will
Die wichtigen Dinger sind schon übersetzt
Ja, nur teilweise falsch und unvollständig, zum Bleistift popen() und pclose() oder einige Signal-Handling-Funktionen. Wenn ich Units als deprecated deklariere (oldlinux), sollte ich auch dafür sorgen, daß die gleiche Funktionalität in den neuren Units zur Verfügung steht (und ein "external blubb" tut ja nun wirklich nicht weh...).

Zitat von mael:
wie gesagt, ich halte nichts davon zuviel Fremdkode zu verwenden
Oh, ich halte sehr viel davon, vorhandene und standardisierte Sachen nicht wieder und immer wieder neu zu implementieren. Die libc ist da, warum sind nicht alle deren Funktionen entsprechend der Docs importiert worden?

Zitat von mael:
Okay jetzt sage ich es: ich finde GTK, Qt schei*e, auch wenn es dafürÜbersetzungen gibt. Man schaue sich mal die GUIs an, überall kleine Fehler, nicht das Standardaussehen, eigene Komponenten anstatt die des OS (z.B. Dateidialog).
Ich finde nonVCL sche*e. Überall baut man sich seine Dialoge selber, sie sehen nicht aus wie die VCL-Dinger aus Delphi, sie können teilweise viel mehr und sind daher mit Funktioenn überfüllt. Und an das einheitliche Layout halten sie sich auch noch!
Merkste wat? Jenaaaau, es kommt drauf an, *wie* man etwas macht. Daß nicht jedes Programm die Gnome-Filedialogs benutzt, hat überhaupt rein garnix mit GTK zu tun.

Zitat von mael:
Soweit würde ich nicht gehen, ich finde eher daß die Entwicklung nicht weiter geht.
Aber sie bellen laut, mit ihrem Superhero. Trotzdem beißt die IDE lange nicht mehr, weil sie der Entwicklung zu weit zurückhinken. Microsoft hat Produktivitätsfeatures in der IDE, von denen träumt Borland nachts. Mit Delphi8/2005 sind sie ja immerhin in Richtung *ein* Fenster für *eine* IDE gegangen, ist schonmal was Feines, wenn man's richtig macht. (Umso schlimmer, daß Lazarus es immer noch nicht auf die Reihe kriegt, die zahllosen Fenster vernünftig zusammenzufassen, wenn Metacity (und die meisten anderen WMs) nicht die Möglichkeit für mehrere virtuelle Desktops hätte, Lazarus wäre nicht benutzbar, wenn man nebenbei noch Mailclient, Browser, Dokumentationen und sonstiges offen hat.)
  Mit Zitat antworten Zitat
Benutzerbild von mael
mael

Registriert seit: 13. Jan 2005
391 Beiträge
 
Delphi XE3 Professional
 
#48

Re: c++ vs delphi

  Alt 5. Apr 2005, 18:29
Zitat von tommie-lie:
Zitat von mael:
wie gesagt, ich halte nichts davon zuviel Fremdkode zu verwenden
Oh, ich halte sehr viel davon, vorhandene und standardisierte Sachen nicht wieder und immer wieder neu zu implementieren. Die libc ist da, warum sind nicht alle deren Funktionen entsprechend der Docs importiert worden?
Libc hat in Delphi/Pascal nichts zu suchen. Dafür gibt es Jedi. Was C++ angeht verwendet man natürlich libc und STL. Aber z.b. nicht die verkorkste HDR-Image-library die war mist.

Zitat von tommie-lie:
Ich finde nonVCL sche*e. Überall baut man sich seine Dialoge selber, sie sehen nicht aus wie die VCL-Dinger aus Delphi, sie können teilweise viel mehr und sind daher mit Funktioenn überfüllt. Und an das einheitliche Layout halten sie sich auch noch!
Merkste wat? Jenaaaau, es kommt drauf an, *wie* man etwas macht. Daß nicht jedes Programm die Gnome-Filedialogs benutzt, hat überhaupt rein garnix mit GTK zu tun.
Ich merke sehrwohl das Du da was vermischst. Es geht nicht um VCL oder nicht, sondern um die Standard BS-Dialoge. Ich hasse Programme die GTK-OpenDialog anstatt Windows-OpenDialog haben und die eben nicht leistungsfähiger sind. Die haben kein Explorer-Kontextmenü und häufig wird auch noch das Dateisystem à la Unix dargestellt. Umgekehrt mag ich es auch nicht in Unix Systemen wenn der Windows-Stil erzwungen wird (wie z.B. Teilweise in Kylix).
Zum Glück verwendet nicht jedes Programm den GTK DateiDialog, und natürlich hat das gerade was mit GTK zu tun Ich meine selbst FireFox kriegt das gebacken.

Zitat von tommie-lie:
Trotzdem beißt die IDE lange nicht mehr, weil sie der Entwicklung zu weit zurückhinken. Microsoft hat Produktivitätsfeatures in der IDE, von denen träumt Borland nachts.
Wenn man sauberen Kode schreibt ist Refactoring höchstens für Umbenennungen sinnvoll. Aber allgemein deutet häufige Nutzung auf schlechtes Design und Planung hin. Erst seit .NET hat MS VC++ einen ordentlichen Form-Designer, aber besser als in D7 ist der nicht. Die IDE ist auch nicht das Problem, sondern die fehlende Sprachentwicklung (von Delphi). D7 IDE mit GExperts da kommt MS VS nicht ran.

Zitat von tommie-lie:
Mit Delphi8/2005 sind sie ja immerhin in Richtung *ein* Fenster für *eine* IDE gegangen, ist schonmal was Feines, wenn man's richtig macht.
Geschmackssache

Zitat von tommie-lie:
(Umso schlimmer, daß Lazarus es immer noch nicht auf die Reihe kriegt, die zahllosen Fenster vernünftig zusammenzufassen, wenn Metacity (und die meisten anderen WMs) nicht die Möglichkeit für mehrere virtuelle Desktops hätte, Lazarus wäre nicht benutzbar, wenn man nebenbei noch Mailclient, Browser, Dokumentationen und sonstiges offen hat.)
Ich verwende Lazarus nicht, weil es schlecht ist: buggy, zusammengestückelt, gehackt (so wie viele C++ IDEs).
Mit Delphi 7, also getrennten Fenstern, und x weiteren geöffneten Programmen habe ich keine Probleme. Für Multimonitornutzer sind gedockte Fenster unpraktisch.

Aber das alles wird OT.
HxD, schneller Hexeditor:
http://mh-nexus.de/hxd
  Mit Zitat antworten Zitat
tommie-lie
(Gast)

n/a Beiträge
 
#49

Re: c++ vs delphi

  Alt 5. Apr 2005, 19:28
Zitat von mael:
Libc hat in Delphi/Pascal nichts zu suchen. Dafür gibt es Jedi. Was C++ angeht verwendet man natürlich libc und STL. Aber z.b. nicht die verkorkste HDR-Image-library die war mist.
*räusper*
Auf einem GNU-System will ich auch die offizielle GNU-Laufzeitumgebung benutzen, und die ist nunmal die GNU C Library. Die bietet Dinge wie Signal Handling, IPC und sogar ein Waschbecken. Außerdem kann man davon ausgehen, daß sie auf jedem GNU-System vorhanden ist, daher kann ich sie dynamisch linken und meine Echse bleibt schön klein.
Und wie öffne ich mit JEDI einen POSIX-Pipe zu einem Prozess, von dem ich die PID habe?

Zitat von mael:
Ich merke sehrwohl das Du da was vermischst. Es geht nicht um VCL oder nicht
Nein, darum ging es mir auch nicht...
Die VCL hält sich auch nicht immer an das, was Windows ihr vor die Füße wirft. Und seit XP sehen sie auch nicht immer so aus, wie alle anderen Windows-Anwendungen. Deswegen die vCL zu verteufeln ist aber auch nicht das Wahre. Wenn du sämtliche Windows-Features haben willst, musst du sie dir selber besorgen und nicht Fremdkapselungen benutzen. Erst Recht nicht GTK oder Qt, die auch noch komplett eigene Widgets zur Verfügung stellen.

Zitat von mael:
sondern um die Standard BS-Dialoge. Ich hasse Programme die GTK-OpenDialog anstatt Windows-OpenDialog haben und die eben nicht leistungsfähiger sind.
Ah, I see... Und wie stellst du dir das unter Linux mit dem Windows-Dialog vor? Wine zu erzwingen kann's ja wohl nicht sein... Wenn ich mein Programm nur unter Windows veröffnetlichen will, brauche ich kein GTK, da komme ich mit den Windows Controls schneller und vor allem mit kleineren Programmen (keine GTK-Bibliotheken) ans Ziel. Wenn ich Programme für Windows und Linux bereitstellen will, muss ich eine gemeinsame Teilmenge finden. Und die ist nunmal nur GTK. Natürlich kann ich mir mehrere Versionen meines Quellcodes zulegen. Da wäre eine für Windows, eine für Gnome, eine für KDE, eine für xfce, eine für fvwm, eine für icewm, eine für fluxbox, eine für Enlightenment, eine für... fein, und du maintainst das dann? Abgemacht.

Zitat von mael:
Die haben kein Explorer-Kontextmenü und häufig wird auch noch das Dateisystem à la Unix dargestellt.
Ach herrje. Dann benutz' Windows-Software, die hat auch windowsspezifische Dialoge und Features.

Zitat von mael:
Ich meine selbst FireFox kriegt das gebacken.
Die haben auch genug maintainer für beide Plattformen. Bei OpenOffice.org hast du sogar im laufenden Betrieb die Wahl zwischen dem OO.o-eigenen (selbstgebastelten) Dialog und den System-Dialogen.

Zitat von mael:
Wenn man sauberen Kode schreibt ist Refactoring höchstens für Umbenennungen sinnvoll. Aber allgemein deutet häufige Nutzung auf schlechtes Design und Planung hin.
Finde ich nicht, es weist lediglich auf gewachsenen, ergo entwickelten Code hin.

Zitat von mael:
Zitat von tommie-lie:
Mit Delphi8/2005 sind sie ja immerhin in Richtung *ein* Fenster für *eine* IDE gegangen, ist schonmal was Feines, wenn man's richtig macht.
Geschmackssache
Zugegeben.

Zitat von mael:
Ich verwende Lazarus nicht, weil es schlecht ist: buggy, zusammengestückelt, gehackt (so wie viele C++ IDEs).
Aus den selben Gründen würde ich es ebenfalls nicht benutzen, aber mangels Alternative bin ich leider dazu gezwungen.

Zitat von mael:
Mit Delphi 7, also getrennten Fenstern, und x weiteren geöffneten Programmen habe ich keine Probleme.
Für Multimonitornutzer sind gedockte Fenster unpraktisch.[/quote]Ja, Delphi legt dir auch nicht für jedes Fenster einen eigenen Eintrag in die Taskleiste und behandelt nicht jedes Fenster als getrenntes Fenster, sondern als Unterfenster des Hauptfensters, sodaß bei einem Klick auf ein belibebiges Fenster die gesamte IDE in den Vordergrund kommt. Lazarus macht das nicht.

Zitat von mael:
Aber das alles wird OT.
Stimmt.
  Mit Zitat antworten Zitat
Benutzerbild von mael
mael

Registriert seit: 13. Jan 2005
391 Beiträge
 
Delphi XE3 Professional
 
#50

Re: c++ vs delphi

  Alt 5. Apr 2005, 20:49
Zitat:
Auf einem GNU-System will ich auch die offizielle GNU-Laufzeitumgebung benutzen, und die ist nunmal die GNU C Library.
Tut auch string-handling anbieten was unnötig ist für Pascal. Andere notwendige Sachen sind vorhanden, zumindest habe ich bis jetzt noch nichts gehabt was nicht übersetzt war und wofür pascal nicht selbst was bietet.

Zitat:
Die VCL hält sich auch nicht immer an das, was Windows ihr vor die Füße wirft.
Aber zu über 90%, XP konnte vorher nicht sein, aber es gibt ja D7 oder Lischkes Theme-Manager und das sieht genau wie XP aus weil es eben Win-Controls verwendet. VCL ist fast nur ein Wrapper.
Schau dir mal ne Qt Anwendung mit Themes an...

Zitat:
Erst Recht nicht GTK oder Qt, die auch noch komplett eigene Widgets zur Verfügung stellen.
Was genau das ist was ich nicht mag, ListView und TreeView von Windows sollten verwendet werden, ich will kein importiertes Linux.


Zitat:
Und wie stellst du dir das unter Linux mit dem Windows-Dialog vor?
Da sollte der Window-Manager Standard-Dialog verwendet werden (wie KDE oder GNOME ihn anbieten) und nur wenn nicht vorhanden dann GTK oder Qt Dialoge. Ich habe doch schon gesagt, unter Linux mag ich auch kein importiertes Windows. (siehe Bemerkung zu Kylix)

Zitat:
Wenn ich Programme für Windows und Linux bereitstellen will, muss ich eine gemeinsame Teilmenge finden. Und die ist nunmal nur GTK.
Aber ein schlechter Kompromiss, genausogut könnte man die VCL erweitern und Wrapper um die X Window API machen und eventl. noch Window Manager berücksichtigen. Ein ordentlicher Pascal-Wrapper dafür wäre durchaus machbar und von allen verwendbar (wodurch sich die Last verteilt) aber eben nicht auf GTK basiert.

Zitat:
Natürlich kann ich mir mehrere Versionen meines Quellcodes zulegen. Da wäre eine für Windows, eine für Gnome, eine für KDE, eine für xfce, eine für fvwm, eine für icewm, eine für fluxbox, eine für Enlightenment, eine für... fein, und du maintainst das dann? Abgemacht.
Unsinn, nur Win32 API und X Window API, der Window Manager(für Unix) macht kaum mehr als die Darstellung. Um die Abweichungen muß sich außerdem GTK auch kümmern, und das tut es auch nicht immer so schön.

Zitat:
Ach herrje.
Stöhn nicht, es geht darum das Windows Software wie Windows Software funktionieren und aussehen muß, gleiches gilt für Linux Software und für Crossplattform.
Ein Programm muß sich an das BS anpassen und nicht sein Heimatland importieren. Wenn ich ins Ausland gehe um dort zu leben lerne ich die Sprache dieses Landes und seine Bräuche.
Ich verlange nicht meine Wurstbude und mein Bier, und installiere mir meine eigene neutrale Zone, das ist unhöflich.

Zitat von mael:
Ich meine selbst FireFox kriegt das gebacken.
Zitat:
Die haben auch genug maintainer für beide Plattformen. Bei OpenOffice.org hast du sogar im laufenden Betrieb die Wahl zwischen dem OO.o-eigenen (selbstgebastelten) Dialog und den System-Dialogen.
Sag ich ja, geht auch anders.

Zitat:
Zitat von mael:
Wenn man sauberen Kode schreibt ist Refactoring höchstens für Umbenennungen sinnvoll. Aber allgemein deutet häufige Nutzung auf schlechtes Design und Planung hin.
Finde ich nicht, es weist lediglich auf gewachsenen, ergo entwickelten Code hin.
Schon, aber es sollte nicht soweit kommen, daß man nicht mehr ohne auskommt und daher die IDE für einen "unnutzbar" ist.


Zitat:
Zitat von mael:
Mit Delphi 7, also getrennten Fenstern, und x weiteren geöffneten Programmen habe ich keine Probleme.
Für Multimonitornutzer sind gedockte Fenster unpraktisch.
Ja, Delphi legt dir auch nicht für jedes Fenster einen eigenen Eintrag in die Taskleiste und behandelt nicht jedes Fenster als getrenntes Fenster, sondern als Unterfenster des Hauptfensters, sodaß bei einem Klick auf ein belibebiges Fenster die gesamte IDE in den Vordergrund kommt. Lazarus macht das nicht.[/quote]
Das ist natürlich schlecht, solange hab ich mir das nichtmal angesehen.


P.S. Ich habe nichts gegen Linux. Auch nicht gegen OpenSource Frameworks, aber die mir bisher bekannten sind einfach unsauber. Dann MS VS hat sich gerade mal gemausert da ist jetzt die Borland IDE plötzlich total schlecht? Das finde ich doch etwas unobjektiv.
Momentan sind viele Lösungen (insbesondere GUI) nicht ausgereift sowohl für Pascal als auch für C++.
HxD, schneller Hexeditor:
http://mh-nexus.de/hxd
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 5 von 10   « Erste     345 67     Letzte »    


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 21:00 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz