- LiTime Speicher und Akkus         
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 20

Thema: MAL Wieder "C" Frust

  1. #1
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    05.11.2007
    Beiträge
    1.076

    MAL Wieder "C" Frust

    Anzeige

    Praxistest und DIY Projekte
    Hallo zusammen:

    Ich wollte gestern mal eben eine Software für mein RIGOL Oszilloskop installieren,
    Dies schlug aber fehl, weil irgend etwas mit Microsofts Redistributable nicht in Ordung ist.

    Keine Ahnung was das sein soll,
    in meiner Systemsteuerung konnte ich finden, das es "ETLICHE" von diesen Dingern gibt.

    Bei weiteren Recherchen scheint es so zu sein, das man die NUR braucht wenn jemand Software in Visual C++ geschrieben hat ???

    Ich bin echt, mal wieder genervt von dem "C" Mist.....
    Kann man keine Programme mehr in "vernünftigen Programmiersprachen" schreiben, die auch funktional sind....

    Ihr wisst ja, dass ich ein "C" Gegner bin und irgendwie werde ich immer wieder bestätigt.

    Wenn ich in Pascal, Delphi oder Lazarus ein Programm schreiben, dann habe ich genau EINE .EXE Datei, die funktional ist.

    Zumal scheint es ja ZIG Versionen von diesem Redistributable zu geben, wo jedes Programm anscheinend sein eigenes benötigt.
    Welche Programme die benötigen weis ich nicht, das werde ich merken wenn ich alle rausschmeisse.

    So, der Frust abgelassen

    kann man die Dinger einfach so rausschmeissen und im Zweifelsfalle wieder nachinstallieren ?
    Das sind ja wohl irgendwelche Bibliotheken, und warum kann man die nicht gleich mit ranlinken, dann bräuchte man die doch garnicht.

    Siro
    Geändert von Siro (22.11.2018 um 09:23 Uhr)

  2. #2
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    39
    Beiträge
    3.416
    Ihr wisst ja, dass ich ein "C" Gegner bin und irgendwie werde ich immer wieder bestätigt.
    hey hey hey hey bitte! Schmeiß hier C nicht mit C# und .Net zusammen, das ist echt mies!

    Delphi oder besser gesagt Pascal (ist ja nur ein Dialekt von Pascal) sind zwar leichter als Anfänger aber in Performance kommt man nicht an ordentliches C/++ ran!

    Das hier für ein Oszi massiver Gebrauch von .Net gemacht wird ist ein M$ Problem. Die von Rigol sind wohl primär C Programmierer (für die Firmware der Oszis) und müssen dnan auchnoch eine GUI dafür schreiben (selten schafft sich dafür eine Firma einen dedizierten Anwendungsentwickler an, wenn sie schon Programmierer haben)

    Und wenn du schonmal Windows API mit reinem C gemacht hast wärst du nicht hier sondern hättest dich wohl schon erschossen :P (Sinnbildlich, es ist zu kotzen, das kann cih dir sagen)

    Also nimmt man Visual Studio und das ist halt mit .Net zugekippt ... um es noch schlimmer zu machen hat man als trölfzig Stellen die Möglichkeit die gleiche Eigenschaft zu verändern damit etwas so aussieht wie es soll, nur wenn man anfängt an trölfzig stellen rum zu fummeln funktioniert hinterher garnichts mehr ... deswegen sage ich ja dass man eigentlich einen .Net gelernten Entwickler (der die Struktur hinter .Net begreift) für sowas braucht, auch wenn jeder hinz und kunz "mal was programmieren kann" mit .Net ... nur eben nicht richtig.

    Aber da Ende vom Lied ist wie bei Java ... man muss die Redistributables eben mit reinpacken ...

    schau doch mal in die zip ob da nicht ein isntaller neben der ssetup.exe ist (.msi z.b.) der bringt das notwendige paket meist mit.

    Rausschmeißen würde ich sie nicht sonst funktioniert irgendwann irgend ein anderes Programm nicht ... wenn du nicht gerade eine zu kleine Festplatte hast würde ich sie lieber drin lassen

    Und wenns erlaubt ist zu fragen, wo ziehst du deine Grenze der Aversion was C/++/# angeht denn? Ich muss gestehen dass mir persönlich C++ schon nciht schmeckt weils eine Symbolüberhäufte Sprache ist ....

    "hey du hast da ein ":" vergessen ... ich schmeiß jetzt mal n kryptischen Fehler an irgend einer andern Stelle deswegen"

    oder mein top favorit

    "hmm ... da müsste eigentlich ein ":" stehen ... tut es aber nicht ... egal compilen wir es trotzdem und verhalten uns am ende einfach affig"

    und was .Net angeht, finde ich es herrlich wenn sich ein Ingenieur damit versucht und du am Ende eine Episode von 1000 Wege ins Gras zu beißen mit der Anwendung machen kannst weil der ingenieur linear denkt und alles in einem einzigen Thread schreibt weil Thread-Handling ne Wissenschaft für sich ist und du dann an der GUI zugucken kannst was das Programm im Hintergrund rechnet.

    Bestes Beispiel dafür ist eine Profi-Fräse von einem Namenhaften Hersteller dessen Software sogar das Kamerabild während des Fräsen zeigt ... aber die GUI bei jeder Bewegung inklusive Kamerabild einfriert solange die Fräse eine kontinuierliche Bewegung ausführt, weil der Steuerprozess im selben Thread wie die GUI läuft und die Methode zum verfahren auf das Ende der Fahrt wartet


    PS: um mich Shedepe an der Stelle ein kein wenig entgegen zu stellen, ich habe beide Welten programmiert, Borland Turbo Pascal (und die können einem auch herzlichen mit Packages und Libs um die Ohren fliegen) und intensives Anwendungsentwicklung mit C++ .Net .... ich mag Pascal echt lieber weil es eindeutiger ist, aber schneller ist halt immernoch OS-Nativ mit .Net
    Geändert von Ceos (22.11.2018 um 09:52 Uhr)
    Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
    nicht.

  3. #3
    shedepe
    Gast
    Ohne jetzt mal auf deinen Rant gegen C einzugehen:
    Überlege dir mal warum es eventuell eine schlechte Idee ist fest gegen Bibliotheken zu linken. Eine davon ist: Du kannst ansonsten keine Updates der Bibliothek machen z.B. bei Sicherheitslücken. Das ist vorallem bei so zentralen Sachen wie dem was in der Redistributable drin ist sinnvoll.
    Die Unterschiedlichen Versionen kommen daher, dass für jede Major Version ein neues Release gemacht wird (dann wenn die Kompabilität gebrochen wird).

    Btw. Du kannst auch in C diese Bibliotheken fest reinlinken. Ich würde es dir nur nicht empfehlen. (Und mach doch bitte noch einen Unterschied zwischen Visual C++ und normalen C/C++)

    Und um doch noch auf deinen Rant einzugehen: ich bin entschiedener Delphi Gegner

  4. #4
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    05.11.2007
    Beiträge
    1.076
    Hallo Ceos und shedepe
    es ist nicht ganz so negativ gemeint, wie es aussehen mag....
    aber da wir hier im "Tratsch" Thread sind, kann man mal vom Leder lassen

    Ich kann ja zu C# C++ oder.NET z.B. garnichts sagen, da ich nie damit gearbeitet habe...

    Aber ich war "mal wieder" genervt, als ich ergoogeln muste,
    das die Rigol Software nicht funktioniert, weil sie anscheinend in einer Variante von "C" geschrieben wurde.
    Wobei dies anscheinend C++ ist.

    Die Abneigung von "C" hat bei mir viele Gründe, wobei ich nun nach zig Jahren programmieren in "C"
    für Embedded Anwendungen die meisten Hürden erlebt und überwunden habe.
    Habe mit dem "normalen" C eigentlich gar keine Probleme mehr.


    Irgendwie hab ich gelesen, das man die Software bei C++ wohl hätte "statisch" linken können, dann bräuchte man wohl
    die Laufzeitbibliotheken garnicht, zumindest hab ich das so verstanden. Deshalb finde ich es sehr schade,
    dass Rigol eine so "halbherzige" Software dazu liefert.
    Hab grad gelesen von shedepe, dass es aber nicht unbedingt sinnvoll ist wegen Updates etc.

    @Ceos:
    Windows API programmieren:
    Jo, is geil, wenn man dann Masochist ist

    Ich hab da auch so einige Erfahrung und bin immer wieder mal dran an der API
    Hab mal am Audio Interface programmiert (Multimedia Api) und vor kurzen grad wieder RS232 und Timer..
    brauchte eine serielle Schnittstelle die mit den FTDI oder SILABs Treiber kommuniziert.

    Zurück zum Redistributable:
    Ich muss mal gucken welche Version die Rigol Software braucht und Du hast recht,
    meistens haben die Installer gleich eine Version der Bibliothek mit installiert.
    Da werd ich sicher noch fündig.


    @shedepe:
    Ich bin auch ein Delpi Gegner geworden, da es einfach ÜBERTEURT war und nun ist Lazarus (Open Source Freeware) mein Nonplusultra...

    Siro

  5. #5
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    39
    Beiträge
    3.416
    RS232 mit Windows API .... Strg + A, Strg + D, Strg + S .... wegrenn

    ich pack mir immer eine POSIX UART Lib dazwischen ... sonst wird man beim setzen der serial struct irre
    Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
    nicht.

  6. #6
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    05.11.2007
    Beiträge
    1.076
    @Ceos:
    Du meinst bestimmt die Struktur DCB, muss man mögen

    Viel interesanter fand ich, um zu ermitteln wieviele Bytes sich im Empfangspuffer befinden,
    muss man die Funktion "ClearCommError" aufrufen. Da muss man erstmal drauf kommen....
    und da es keine UART Interrupts mehr gibt, habe ich diese Funktion nun in einen Timer packen müssen,
    weil ich Zeitnah (sofern man das bei Windows überhaupt erwähnen darf) meine Daten haben wollte.

  7. #7
    HaWe
    Gast
    gegen C ist eigentlich nichts zu sagen: es ist klar definiert, schreibt extrem wenig vor, kann so gut wie jede Hardware adressieren und händeln, hat nur knapp 20 fest definierte Bezeichner, eine extrem einfache Syntax, und die Executables sind rasend schnell.
    Nicht umsonst werden ganze Betriebssysteme damit geschrieben (wozu es ja gerade entwickelt wurde).
    Alles was du bemängelst, betrifft die libs, die andere Leute geschrieben und zu vertreten haben, und da gebe ich dir völlig Recht: da ist irrsinng viel Schrott unterwegs.

  8. #8
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    05.11.2007
    Beiträge
    1.076
    Hast Du nicht unrecht HaWe, jede Sprache hat Vor und Nachteile.
    Ich hab aber doch immer wieder mal Probleme mit C die ich in Pascal nicht habe.
    Mal abgesehen davon, dass es bei C99 wohl 190 Fälle gibt, wo nicht vorgeschrieben ist was der Compiler daraus machen soll...
    Muste ich natürlich mit in meine Risikoanalyse aufnehmen....
    https://www.elektronikpraxis.vogel.d...che-c-a-426198

    Mich würde ja mal interessiren um welche Fälle es sich da handelt, falls da jemand Informationen oder Links zu hat, wäre ich sehr dankbar.

    Zum Problem mit den Redistributablen von Microsoft:
    Ich war mal, wie immer, experimentierfreudig ich habe die gesamten Microsoft Redistributables deinstalliert.....
    Ältestes zuerst bis zum Aktuellsten.
    Das Letzte liess sich nicht entfernen, vielleicht braucht das Windows selbst, keine Ahnung.
    Aber nun konnte ich problemlos meine RIGOL Software installieren, was voher nicht ging.
    Ich hatte übrignes nach der Deinstallation diverse Programme ausprobiert, ob sie davon betroffen sind.
    OpenOffice
    FireFox
    Eagle
    MCUXPresso
    MPLAB
    LAZARUS
    keiner hatte Probleme, aber es war, wie gesagt, noch eine letzte Version vorhanden von 2017
    viel mehr an Software läuft auch nicht auf meinem Rechner.

    wenn ich jetzt sagen sollte, die Rigol Software läuft gut, müste ich lügen.
    Das Bild auf dem Rechner entspricht nicht dem auf dem Oszilloskop Bildschirm.....Ohje.....
    Wenn man das Programm verlässt und neu startet stimmt es wieder. Man darf nix am Ossi ändern, das bekommt die Software am PC anscheinend nicht mit.
    Ist nicht perfekt, aber brauchbar...



    Siro
    Geändert von Siro (22.11.2018 um 20:49 Uhr)

  9. #9
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    39
    Beiträge
    3.416
    Mal abgesehen davon, dass es bei C99 wohl 190 Fälle gibt, wo nicht vorgeschrieben ist was der Compiler daraus machen soll...
    Muste ich natürlich mit in meine Risikoanalyse aufnehmen....
    Und das ist der Grund warum wir hier auf Arbeit keine schönen Dinge haben können (TM)

    Wir haben Guidelines die uns gewisse Dinge verbieten ... So viele schöne Kontrukte die man bauen kann aber dann kommt der "nein das darfst du nicht"-Hammer weil "offsetof" nicht sauber spezifiziert ist

    ... und solch ähnliche Späße

    Habe mir eine Standpauke über X-Makros anhören müssen .... mimimi statische Codeanalyse kann keine Functionpointer in Arrays verfolgen mimimi .... gut, jetzt ists halt ein ebenfalls per X-Makro generierter riesen-switch-case statt einer Spungtabelle ... der Compiler baut eh wieder ne Sprungtabelle draus aber wenigstens kann die statise Code analyse das jetzt verarbeiten
    Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
    nicht.

  10. #10
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    05.11.2007
    Beiträge
    1.076
    Moin Ceos
    Ist doch mal schön zu hören, dass ich nicht der Einzige bin, der nach diversen Regeln arbeiten soll...
    Wobei ich glücklicherweise NOCH keine wirklichen Vorgaben habe wie ich was implementiere.
    Der Compiler macht eh was er will, das kann man kaum steuern.
    Die wirklichen Probleme einer nicht funktionierenden Software liegen oftmals völlig woanders.
    Das ist auch der Grund warum ich stets mit verschiedenen Optionen compiliere und teste.
    Es finden sich immer wieder neue Merkwürdigkeiten, die oft sogar mit der Prozessorarchitektur zusammen hängen.
    Das kann eh keine automatische Codeanlayse feststellen.

    Ich habe auch Funktionstabellen, weil es wesentlich Übersichtlicher ist als ein switch-case.

    "offsetof" kannte ich noch garnicht, witzigerwiese scheint das genau das zu sein, was ich für meine
    EEPROM struktur verwende....
    Was soll daran nicht "sauber" bzw. nicht nachvollziehbar sein ?

    Im eeprom bei mir liegt ein struct, wo welcher Wert liegt ist nicht direkt bekannt, aber man kann es berechnen:

    Code:
    t_ee_struct *p;
    
      /* we dont know where the userdata is stored in the EEPROM */
      /* but we can calulate the address: */
      p = 0;  /* think the struct starts at address 0 */
      /* convert the pointer to a 32 Bit value (EE-ADDRESS) with the offset of setup_data */
      ee_address = (U32)(&p->setup_data);
    
    
    // Deine genannte Variante mit offsetof  sieht doch VIEL besser aus, muss ich direkt mal ausprobieren .....
      ee_address = offsetof(ee_data,setup_data);
    das macro hab ich grad gesichtet:
    Code:
    #define offsetof(struct_type, member) \
              (size_t) &(((struct_type *)0)->member)


    Siro

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. " DiBaDu und Dein Verein" für Hackerspace Bremen 2017 - wieder dabei !
    Von Andree-HB im Forum Offtopic und Community Tratsch
    Antworten: 67
    Letzter Beitrag: 08.11.2017, 07:46
  2. [ERLEDIGT] Mal wieder eine "fast" funktionierende Stoppuhr
    Von Unregistriert im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 2
    Letzter Beitrag: 09.08.2016, 09:53
  3. Genfer Autosalon 2016 - "Knutschkugel" Isetta kommt wieder - als Elektroauto
    Von Roboternetz-News im Forum Neuigkeiten / Technik-News / Nachrichten / Aktuelles
    Antworten: 0
    Letzter Beitrag: 02.03.2016, 13:30
  4. Versteckte Ordner wieder "unversteckt" machen
    Von Sebas im Forum PC-, Pocket PC, Tablet PC, Smartphone oder Notebook
    Antworten: 2
    Letzter Beitrag: 20.09.2011, 16:19
  5. "Make all" schon wieder Probleme
    Von Spongebob85 im Forum C - Programmierung (GCC u.a.)
    Antworten: 6
    Letzter Beitrag: 08.08.2007, 21:06

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiTime Speicher und Akkus