C, C++,c# - Seite 2

Seite 2 von 3 - Forum: Coding Stuff auf overclockers.at

URL: https://www.overclockers.at/coding-stuff/c_cc_159405/page_2 - zur Vollversion wechseln!

Zitat von M.I.P.S.

Von C++ würde ich abraten, da es hauptsächlich die Nachteile von C und C# vereint

thx!

der Miniprogrammierkurs in den aktuellen ct's hat mich veranlasst ein C-Programmierbuch auszuleihen. Nun bin ich nach einer Weile draufgekommen, dass C und C# nicht das gleiche ist; darum meine Frage.
Sofern mich nicht die Lust verlässt, werde ich bei C bleiben. Wenn ich es richtig verstanden haben, ist C in gewisser Weise die Grundlage dieser Programmiersprachen und die Grundlage von Linux, weil der Linuxkernel und Treiber in C geschrieben sind.

naja, C++ auf objektorientiertheit only zu reduzieren ist schon beinahe verboten.

modernes C++ (in bestimmten bereichen wie scientific computing zB) geht immer mehr weg von objektorientiertheit, weil einfach ersten performance darunter leider oder die objektkopplung zu eng für einige dinge sind.

btw ist objektorientiertheit ein design philosophie, nicht nur ein feature einer sprache. objektorientierte software für C gibt es genug, zB gtk.

wenn du schon dabei bist was anständiges zu lernen: versuchs doch einfach mal mit D (das was C++ hätte werden sollen ))

und btw: C ist der grund warum C++ manchmal grauenerregend sein muß.

Zitat von SYSMATRIX

Zitat von GNU

Wallfahrten
Geben die Lebensfreude
Stärke

Zitat

btw ist objektorientiertheit ein design philosophie, nicht nur ein feature einer sprache. objektorientierte software für C gibt es genug, zB gtk.

Zitat von gue

Jep, aber setzt man in wissenschaftlichen bzw. high-performance Applikationen nicht sowieso Fortran ein?

Zitat von gue

Dem muss ich widersprechen. Ohne dem Support der Sprache gibt es keine Objektorientierung. C ist aber auf keinen Fall eine OO-Sprache und deshalb ist das absurde GTK auch nicht OO.

Zitat

Although GTK+ is written in C, a language without explicit support for object-oriented program, the design of GTK+ is heavily object oriented. The basis of this is a layer known as the GTK+ Object System. In addition to such traditional features as inheritance, polymorphism and reference counting, the GTK+ Object System also adds a number of features particularly adapted for a widget toolkit, including a signal system for notification and an object attribute system.

Inheritance in the GTK+ Object System is achieved by nesting structures within each other. For instance, the GtkButton class inherits from GtkWidget, so the first part of a GtkButton structure is a GtkWidget structure. This means that a pointer to a GtkButton can be cast into a pointer to a GtkWidget. Each class also has an associated class structure, which is essentially a table of pointers to the class's implementation of functions that it overrides from the parent class. (For example, the GtkWidgetClass structure includes a pointer to a draw() function; GtkButtonClass provides an implementation that draws buttons.)

Each GTK+ object class can have an associated set of signals. Each signal represents a certain type of event or other occurence that an application would want to attach a callback to. For instance, the GtkButton class provides the "clicked" signal that is emitted when the user clicks the button widget. Any number of callbacks can be connected to a signal and when the signal is emitted all callback will be called in order. Signals can also be used to change the behavior of widgets - for instance, by connecting to the "insert_text" signal for a GtkEntry widget, an application can filter the text that the user enters into the Entry to allow only numbers.

Each class also has an associated set of arguments; each argument represents some characteristic of the widget that can be queried or set. For instance, the GtkLabel widget provides a "label" argument to allow setting the text of the label and a "justify" argument to allow setting the justification of the label. The powerful feature of the argument system is that the set of arguments for a class can be dynamically queried at run time. This allows a graphical builder application to provide interfaces for setting the arguments of widgets it didn't know about in advance.

Zitat von gue

Und C# ist mit Mono genauso plattformunabhängig (sobald die mal die Windows Forms nachprogrammiert haben ), ich weiß nicht, was ihr dagegen habt.

also ich habe eigentlich mit Fortran zu programmeiren angefangen und es macht seither spass, schaue mir gerade etwas C# und Java an.

werde aber eher auf der fortran schiene beliben da es in meinem Bereich starke vorteil hat (Polymer simulationen)
alleien weil bisher alles darauf geschreiben wurde.

werde mir abe rmal das High performance fortran genauer ansehen.

(hat da wer infos?)

Zitat von SYSMATRIX

nein, heavy template basierende sachen sind genau so schnell. (boost, glitz und dergleichen wirst als informatiker eh kennen, nehm ich mal an) das einzige daß unter C++ irgendwie suckt ist die I/O performance. die streams sind im vergleich zu einem plain fscanf ~ 2x langsamer. (eh klar warum)

ja, weil fortran matrix operationen im compiler eingebaut hat

warten wir auf den neuen c++ standard, wenn teile der boost library übernommen werden.

Zitat von gue

@Master99: Die Intention hinter C# ist ganz anders als bei Java: Nicht eine Sprache für alle Plattformen sondern alle Sprachen für eine Plattform
Und Microsoft hat die .NET Bibliothek durchaus gut umgesetzt. Dass Mono noch ein bisschen hinterherhinkt ist nicht die Schuld von Microsoft und ganz bestimmt nicht die einer Programmiersprache.

Zitat von mat

ja, weil fortran matrix operationen im compiler eingebaut hat

warten wir auf den neuen c++ standard, wenn teile der boost library übernommen werden.

Zitat von gue

Also diese "Objektorientierung" beim GTK hab ich nicht gekannt (hab ja auch noch nie was damit gemacht ), weißt du auch wie sie dynamische Bindung realisieren?

Hab noch nicht geschaut, was in den neuen C++ Standard reinkommt, ich versteh ja nicht mal den alten

Hab jetzt interessehalber nachgeforscht wie das GTK+ Team das mit dynamischer Bindung und so realisiert. ABARTIG. Anstatt eine OO-Sprache zu verwenden, programmieren sie ALLE OO-Konzepte selbst nach, FÜR JEDE "KLASSE" einzeln! Also man muss schon sehr in C vernarrt sein, um sich den Aufwand anzutun und die Arbeit des Compilers übernimmt.

Z.B. so was:

Code:

struct _GtkDialogClass
{
  GtkWindowClass parent_class;

  void (* response) (GtkDialog *dialog, gint response_id);

  /* Keybinding signals */

  void (* close)    (GtkDialog *dialog);

  /* Padding for future expansion */
  void (*_gtk_reserved1) (void);
  void (*_gtk_reserved2) (void);
  void (*_gtk_reserved3) (void);
  void (*_gtk_reserved4) (void);
};

Zitat von gue

Also man muss schon sehr in C vernarrt sein, um sich den Aufwand anzutun und die Arbeit des Compilers übernimmt.

egal warum sie es machen => function pointer sind der anfang vom ende

Zitat von mat

ja, weil fortran matrix operationen im compiler eingebaut hat

warten wir auf den neuen c++ standard, wenn teile der boost library übernommen werden.

overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2026