gnuC Compiler: Problem mit double- Pointer

WICHTIG: Der Betrieb von goMatlab.de wird privat finanziert fortgesetzt. - Mehr Infos...

Partner:

Forum

Option

[Erweitert]

• Diese Seite per Mail weiterempfehlen

Gehe zu:

Matt Lappen

Forum-Anfänger


	Beiträge: 42

	Anmeldedatum: 23.10.11

	Wohnort: ---

	Version: ---

Verfasst am: 23.10.2011, 16:02 Titel: gnuC Compiler: Problem mit double- Pointer

Hallo Zusammen,

Beim Kompilieren mit dem gnucc stoße ich immer wieder auf Fehlermeldungen dieser Art, welche zum Abbruch des Bulid führen (so vermute ich, da der Abbruch immer direkt nach diesen Meldungen in der Log-File gelistet wird):
Warning: C:\Programme\MATLAB\R2009b\toolbox\mbc\mbcsimulink\xreg3xSplineJacobSFnV1.c ( 212 )
initialization discards qualifiers from pointer target type

Es sind jeweils bis zu 20 Meldungen derart. Sie alle sind auf Zeilen im c-Code zurückzuführen, in denen double-Pointer mit mxgetPr befüllt werden.
Ein Beispiel aus einer C-File:

Code:

% Diese Zeilen verursachen die Fehler/Warnmeldungen
double *n = mxGetPr(ORDER);
double *reorder = mxGetPr(REORDER);
double *knots = mxGetPr(KNOTS);
% Diese Zeilen werden ohne Probleme kompiliert
int poly_order = (int) mxGetPr(POLY_ORDER)[0];
int interact = (int) mxGetPr(INTERACT)[0];
int numKnots = (int) mxGetNumberOfElements(KNOTS);

Funktion ohne Link?

Hintergrund:
Ich arbeite mit der ModelbasedCalibrationToolbox (3.7 / MatlabR2009 x86, WinXp). Ich exportiere Simulinkmodelle, welche dann die Simulink-Biblithekserweiterung aus de,Verzeichnis matlabroot\toolbox\mbc\mbcsimulink nutzen. In diesem Verzeichnis befinden sich alle Funktionen jeweils als c, mexw32 und mexw32.csf - Dateien. Die Fehler beziehen sich stets auf die c-Dateien in diesem Verzeichnis.
Die Simulinkmodelle lassen sich auch problemlos via RealTimeWorkshop kompilieren.
Erst beim Build in einer (Matlab-)externen Simulationsumgebung (Etas/Intecrio3.2) mit dem integrierten GNU-C-Compiler tauchen dann diese Fehler auf.

Da ich sogut wie keine C-Kenntnisse habe, weiß ich leider nicht, wie mit diesem Problem umzugehen ist.
Im Zusammenhang mit einem IntelFortranCompiler habe ich gelesen, dass es ratsam ist, den Pointer aus mxgetPr() als int zu definieren und dann samt Array-Dimension an eine Subroutine zu übergeben, welche mit double-Pointern umgehen kann. Allerdings hilft das mir als Laien nicht weiter, außer dass es auf eine scheinbar bekannte Problematik hinweist.

Grüße,
Matt

Jan S

Moderator


	Beiträge: 11.057

	Anmeldedatum: 08.07.10

	Wohnort: Heidelberg

	Version: 2009a, 2016b

Verfasst am: 23.10.2011, 16:34 Titel: Re: gnuC Compiler: Problem mit double- Pointer

Hall Matt Lappen,

Das Ergebnis von "mxGetPr()" ist ein "const double *". Das Weglassen des const-Qualifiers ist potentiell gefährlich, weil man z.B. auf keinen Fall in die Arrays schreiben sollte, die man als Inputs von Matlab erhalten hat.

Code:

int poly_order = (int) mxGetPr(POLY_ORDER)[0];

Funktion ohne Link?

Das ist tückisch. Ich würde eher dies nutzen:

Code:

int poly_order = (int) mxGetScalar(POLY_ORDER);

Funktion ohne Link?

Gruß, Jan

Matt Lappen

Themenstarter

Forum-Anfänger


	Beiträge: 42

	Anmeldedatum: 23.10.11

	Wohnort: ---

	Version: ---

Verfasst am: 23.10.2011, 17:42 Titel:

Hi Jan,
danke für die Antwort,das macht auch gerade bei den nachvolliehbaren Werten Sinn, die auf jeden immer Fall reell sind (wie zb. Ordnungen).

Was bedeutet das nun für die double-Pointer (obere 3 Zeilen)? Ist das Problem dann mit

Code:

const double *n = mxGetPr(ORDER);

Funktion ohne Link?

möglicherweise bereits umgangen?
Oder hilft auch hier

Code:

double *n = mxGetScalar(ORDER);

Funktion ohne Link?

und was bedeutet die Klammer (int), bzw. wie müsste diese beim double * aussehen? Etwa so:

Code:

double *n = (double *)mxGetScalar(ORDER);

Funktion ohne Link?

Wie gesagt, in C hab ich keine Ahnung wie mit Variablen oder auch Typen umzugehen ist.

Gruß

Jan S

Moderator


	Beiträge: 11.057

	Anmeldedatum: 08.07.10

	Wohnort: Heidelberg

	Version: 2009a, 2016b

Verfasst am: 23.10.2011, 23:41 Titel:

Hallo Matt Lappen,

C ist bei der Umwandlungen zwischen Variablen Typen extrem empfindlich. Man kann sich ohne genaue Kenntnisse sehr leicht gemeine Probleme einhandeln, z.B. Code erzeugen, der manchmal läuft, manchmal aber auch nicht. C ist da viel zickiger als z.B. Matlab.

Dies sollte eigentlich functionieren:

Code:

const double *n = mxGetPr(ORDER);

Funktion ohne Link?

Allerdings muss dann auch bei jeder Benutzung von n der const-Qualifier gesetzt sein, also bei allen Unterfunktionen, die n benutzen.

Dies ist ein Fehler:

Code:

double *n = mxGetScalar(ORDER);

Funktion ohne Link?

mxGetScalar liefert einen Wert und keinen Pointer.

"(int)" wandelt den Wert einer Variable in einen anderen Typ um. Das entspricht Matlab's CAST.

Code:

double *n = (double *) mxGetScalar(ORDER);

Funktion ohne Link?

Brr. In C wird das schon laufen, aber es ist bestimmt nicht das, was Du erwartest. Der Wert der Variablen ORDER wird in einen Pointer auf ein DOUBLE Array umgewandelt. Ein Segmentation Fault ist zu erwarten.

In C mit Typen zu spielen endet in 100% der Fälle im Desaster. Ich empfehle vor der Benutzung dringen einen C-Kurs. Das ist immer noch schneller als später viele Tage lang nach den Bugs zu suchen.

Gruß, Jan


Einstellungen und Berechtigungen
Beiträge der letzten Zeit anzeigen:	Du kannst Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen. Du kannst Dateien in diesem Forum posten Du kannst Dateien in diesem Forum herunterladen

Impressum | Nutzungsbedingungen | Datenschutz | FAQ |

RSS

Hosted by:

Copyright © 2007 - 2025 goMatlab.de | Dies ist keine offizielle Website der Firma The Mathworks

MATLAB, Simulink, Stateflow, Handle Graphics, Real-Time Workshop, SimBiology, SimHydraulics, SimEvents, and xPC TargetBox are registered trademarks and The MathWorks, the L-shaped membrane logo, and Embedded MATLAB are trademarks of The MathWorks, Inc.