Thread Subject: mex compiling error

Subject: mex compiling error

From: Stephan

Date: 21 Sep, 2009 12:33:05

Message: 1 of 20

Hi there

I have a problem compiling my Mex-Files. this is the code:

...
// Variable declarations
int const nrOfFrames = (int)mxGetScalar(prhs[0]); // Input variable, nr. of frames to load
BYTE *pData[nrOfFrames]; // Pointer for image data
...

If I'm compiling this, I'm getting following error:

>> mex cameraTest.cpp
cameraTest.cpp
cameraTest.cpp(40) : error C2057: expected constant expression
cameraTest.cpp(40) : error C2466: cannot allocate an array of constant size 0
cameraTest.cpp(40) : error C2133: 'pData' : unknown size
 
  C:\PROGRA~1\MATLAB\R2009A\BIN\MEX.PL: Error: Compile of 'cameraTest.cpp' failed.
 

Why do I get this error? I thought nrOfFrames is a constant value cause it's defined as a constant...

Subject: mex compiling error

From: Rune Allnor

Date: 21 Sep, 2009 12:42:26

Message: 2 of 20

On 21 Sep, 14:33, "Stephan " <schm...@pyl.unibe.ch> wrote:
> Hi there
>
> I have a problem compiling my Mex-Files. this is the code:
>
> ...
> // Variable declarations
> int const nrOfFrames = (int)mxGetScalar(prhs[0]);   // Input variable, nr. of frames to load    
> BYTE *pData[nrOfFrames]; // Pointer for image data
> ...
>
> If I'm compiling this, I'm getting following error:
>
> >> mex cameraTest.cpp
>
> cameraTest.cpp
> cameraTest.cpp(40) : error C2057: expected constant expression
> cameraTest.cpp(40) : error C2466: cannot allocate an array of constant size 0
> cameraTest.cpp(40) : error C2133: 'pData' : unknown size
>
>   C:\PROGRA~1\MATLAB\R2009A\BIN\MEX.PL: Error: Compile of 'cameraTest.cpp' failed.
>
> Why do I get this error? I thought nrOfFrames is a constant value cause it's defined as a constant...

The constant is not known at compile time, which is why
you get the error. You need to use some sort of memory
allocation function at run-time to initialize the array.

Since you make these types of mistakes, you might want to
take a class or cource on C or C++ programming before
venturing too far into in the MEX world.

Rune

Subject: mex compiling error

From: Stephan

Date: 21 Sep, 2009 13:46:19

Message: 3 of 20

Rune Allnor <allnor@tele.ntnu.no> wrote in message <d102bc34-8206-4f28-b692-281de004e561@f33g2000vbm.googlegroups.com>...
> On 21 Sep, 14:33, "Stephan " <schm...@pyl.unibe.ch> wrote:
> > Hi there
> >
> > I have a problem compiling my Mex-Files. this is the code:
> >
> > ...
> > // Variable declarations
> > int const nrOfFrames = (int)mxGetScalar(prhs[0]); ? // Input variable, nr. of frames to load ? ?
> > BYTE *pData[nrOfFrames]; // Pointer for image data
> > ...
> >
> > If I'm compiling this, I'm getting following error:
> >
> > >> mex cameraTest.cpp
> >
> > cameraTest.cpp
> > cameraTest.cpp(40) : error C2057: expected constant expression
> > cameraTest.cpp(40) : error C2466: cannot allocate an array of constant size 0
> > cameraTest.cpp(40) : error C2133: 'pData' : unknown size
> >
> > ? C:\PROGRA~1\MATLAB\R2009A\BIN\MEX.PL: Error: Compile of 'cameraTest.cpp' failed.
> >
> > Why do I get this error? I thought nrOfFrames is a constant value cause it's defined as a constant...
>
> The constant is not known at compile time, which is why
> you get the error. You need to use some sort of memory
> allocation function at run-time to initialize the array.
>
> Since you make these types of mistakes, you might want to
> take a class or cource on C or C++ programming before
> venturing too far into in the MEX world.
>
> Rune

Sorry Rune, but I guess there is no time for a C programming cource at the moment... So how can I initialize the array at run time?

Subject: mex compiling error

From: Rune Allnor

Date: 21 Sep, 2009 14:05:42

Message: 4 of 20

On 21 Sep, 15:46, "Stephan " <schm...@pyl.unibe.ch> wrote:
> Rune Allnor <all...@tele.ntnu.no> wrote in message <d102bc34-8206-4f28-b692-281de004e...@f33g2000vbm.googlegroups.com>...
> > On 21 Sep, 14:33, "Stephan " <schm...@pyl.unibe.ch> wrote:
> > > Hi there
>
> > > I have a problem compiling my Mex-Files. this is the code:
>
> > > ...
> > > // Variable declarations
> > > int const nrOfFrames = (int)mxGetScalar(prhs[0]); ? // Input variable, nr. of frames to load ? ?
> > > BYTE *pData[nrOfFrames]; // Pointer for image data
> > > ...
>
> > > If I'm compiling this, I'm getting following error:
>
> > > >> mex cameraTest.cpp
>
> > > cameraTest.cpp
> > > cameraTest.cpp(40) : error C2057: expected constant expression
> > > cameraTest.cpp(40) : error C2466: cannot allocate an array of constant size 0
> > > cameraTest.cpp(40) : error C2133: 'pData' : unknown size
>
> > > ? C:\PROGRA~1\MATLAB\R2009A\BIN\MEX.PL: Error: Compile of 'cameraTest.cpp' failed.
>
> > > Why do I get this error? I thought nrOfFrames is a constant value cause it's defined as a constant...
>
> > The constant is not known at compile time, which is why
> > you get the error. You need to use some sort of memory
> > allocation function at run-time to initialize the array.
>
> > Since you make these types of mistakes, you might want to
> > take a class or cource on C or C++ programming before
> > venturing too far into in the MEX world.
>
> > Rune
>
> Sorry Rune, but I guess there is no time for a C programming cource at the moment...

Then stay away from MEX. If you are unwilling to do what it
takes to learn how to program C, you will only get pain and
misery from the attempt. Not to mention that you will waste
ten times a smuch time as if you coded whatever you are up
to, directly in matlab.

Rune

Subject: mex compiling error

From: Stephan

Date: 21 Sep, 2009 14:54:05

Message: 5 of 20

Rune Allnor <allnor@tele.ntnu.no> wrote in message <da8e5411-2998-41a4-afb4-97952f12037e@z34g2000vbl.googlegroups.com>...
> On 21 Sep, 15:46, "Stephan " <schm...@pyl.unibe.ch> wrote:
> > Rune Allnor <all...@tele.ntnu.no> wrote in message <d102bc34-8206-4f28-b692-281de004e...@f33g2000vbm.googlegroups.com>...
> > > On 21 Sep, 14:33, "Stephan " <schm...@pyl.unibe.ch> wrote:
> > > > Hi there
> >
> > > > I have a problem compiling my Mex-Files. this is the code:
> >
> > > > ...
> > > > // Variable declarations
> > > > int const nrOfFrames = (int)mxGetScalar(prhs[0]); ? // Input variable, nr. of frames to load ? ?
> > > > BYTE *pData[nrOfFrames]; // Pointer for image data
> > > > ...
> >
> > > > If I'm compiling this, I'm getting following error:
> >
> > > > >> mex cameraTest.cpp
> >
> > > > cameraTest.cpp
> > > > cameraTest.cpp(40) : error C2057: expected constant expression
> > > > cameraTest.cpp(40) : error C2466: cannot allocate an array of constant size 0
> > > > cameraTest.cpp(40) : error C2133: 'pData' : unknown size
> >
> > > > ? C:\PROGRA~1\MATLAB\R2009A\BIN\MEX.PL: Error: Compile of 'cameraTest.cpp' failed.
> >
> > > > Why do I get this error? I thought nrOfFrames is a constant value cause it's defined as a constant...
> >
> > > The constant is not known at compile time, which is why
> > > you get the error. You need to use some sort of memory
> > > allocation function at run-time to initialize the array.
> >
> > > Since you make these types of mistakes, you might want to
> > > take a class or cource on C or C++ programming before
> > > venturing too far into in the MEX world.
> >
> > > Rune
> >
> > Sorry Rune, but I guess there is no time for a C programming cource at the moment...
>
> Then stay away from MEX. If you are unwilling to do what it
> takes to learn how to program C, you will only get pain and
> misery from the attempt. Not to mention that you will waste
> ten times a smuch time as if you coded whatever you are up
> to, directly in matlab.
>
> Rune

Rune, calm down a bit... breathe in - breathe out!!! Better now? I did C-Courses during my education, but it's been a while. If you are a C-pro and my posts are annoying to you, just ignore them! You really don't have to answer them, but I think those user-communities are exactly to ask questions like that. So if any polite people want to answer my questions, feel free...

Subject: mex compiling error

From: James Tursa

Date: 21 Sep, 2009 15:04:04

Message: 6 of 20

"Stephan " <schmutz@pyl.unibe.ch> wrote in message <h9803b$fkp$1@fred.mathworks.com>...
>
> So how can I initialize the array at run time?

One method using the API functions:

int const nrOfFrames = (int)mxGetScalar(prhs[0]); // Input variable, nr. of frames to load
// Put it checks here for valid nrOfFrames value
BYTE **pData; // Used for allocated array of Pointers for image data
pData = (BYTE **) mxMalloc(nrOfFrames*sizeof(*pData));
if( pData == NULL ) { // not really needed since MATLAB will exit the mex function if you run out of memory
    mexErrMsgTxt("Unable to allocate pData.");
}
// other code here to use pData
mxFree(pData); // free the memory when you are done with it

P.S. Variable Length Arrays, where the array size is determined at run-time, *are* part of the current C Standard, but they are *not* part of the C++ standard. Having said that, many popular C compilers such as Microsoft Visual C (at least up to 8 ... I haven't tried 9 yet) and the lcc that ships with MATLAB, do not support Variable Length Arrays yet.

James Tursa

Subject: mex compiling error

From: Rune Allnor

Date: 21 Sep, 2009 15:24:37

Message: 7 of 20

On 21 Sep, 16:54, "Stephan " <schm...@pyl.unibe.ch> wrote:
> Rune Allnor <all...@tele.ntnu.no> wrote in message <da8e5411-2998-41a4-afb4-97952f120...@z34g2000vbl.googlegroups.com>...
> > On 21 Sep, 15:46, "Stephan " <schm...@pyl.unibe.ch> wrote:
> > > Rune Allnor <all...@tele.ntnu.no> wrote in message <d102bc34-8206-4f28-b692-281de004e...@f33g2000vbm.googlegroups.com>...
> > > > On 21 Sep, 14:33, "Stephan " <schm...@pyl.unibe.ch> wrote:
> > > > > Hi there
>
> > > > > I have a problem compiling my Mex-Files. this is the code:
>
> > > > > ...
> > > > > // Variable declarations
> > > > > int const nrOfFrames = (int)mxGetScalar(prhs[0]); ? // Input variable, nr. of frames to load ? ?
> > > > > BYTE *pData[nrOfFrames]; // Pointer for image data
> > > > > ...
>
> > > > > If I'm compiling this, I'm getting following error:
>
> > > > > >> mex cameraTest.cpp
>
> > > > > cameraTest.cpp
> > > > > cameraTest.cpp(40) : error C2057: expected constant expression
> > > > > cameraTest.cpp(40) : error C2466: cannot allocate an array of constant size 0
> > > > > cameraTest.cpp(40) : error C2133: 'pData' : unknown size
>
> > > > > ? C:\PROGRA~1\MATLAB\R2009A\BIN\MEX.PL: Error: Compile of 'cameraTest.cpp' failed.
>
> > > > > Why do I get this error? I thought nrOfFrames is a constant value cause it's defined as a constant...
>
> > > > The constant is not known at compile time, which is why
> > > > you get the error. You need to use some sort of memory
> > > > allocation function at run-time to initialize the array.
>
> > > > Since you make these types of mistakes, you might want to
> > > > take a class or cource on C or C++ programming before
> > > > venturing too far into in the MEX world.
>
> > > > Rune
>
> > > Sorry Rune, but I guess there is no time for a C programming cource at the moment...
>
> > Then stay away from MEX. If you are unwilling to do what it
> > takes to learn how to program C, you will only get pain and
> > misery from the attempt. Not to mention that you will waste
> > ten times a smuch time as if you coded whatever you are up
> > to, directly in matlab.
>
> > Rune
>
> Rune, calm down a bit... breathe in - breathe out!!! Better now? I did C-Courses during my education, but it's been a while.

If you ever had a C course, you would know about memory allocation.

> If you are a C-pro and my posts are annoying to you, just ignore them! You really don't have to answer them, but I think those user-communities are exactly to ask questions like that. So if any polite people want to answer my questions, feel free...

If you don't have the time to look up your own old class notes,
pain and misery will follow. This is not the place to get free
C education or to have C programs debugged.

If you are in such a hurry to get a result, code matlab.

Rune

Subject: mex compiling error

From: Jan Simon

Date: 21 Sep, 2009 21:33:04

Message: 8 of 20

Dear Stephan, dear Rune!

> > I did C-Courses during my education, but it's been a while.
> If you ever had a C course, you would know about memory allocation.
 
> > If you are a C-pro and my posts are annoying to you, just ignore them! You really don't have to answer them, but I think those user-communities are exactly to ask questions like that. So if any polite people want to answer my questions, feel free...
>
> If you don't have the time to look up your own old class notes,
> pain and misery will follow. This is not the place to get free
> C education or to have C programs debugged.
>
> If you are in such a hurry to get a result, code matlab.

If Stephan states, that he did his C-courses, then he did his C-courses.
Here is not the place for inpolite allegations, Rune.

This is a forum for Matlab related problems. Stephan's problem appears at compiling a MEX source, therefore he is absolutely welcome to ask and he has no reason to legitimate, why he dared to make a mistake with the fiddly C-memory-handling.

Rune: Three days ago you told us, that we should use C++ to get the results fast and peoples are working to death caused by Matlab (http://www.mathworks.com/matlabcentral/newsreader/view_thread/261124). Now you recommend using Matlab, if we are in a hurry. What's up?

James answered the problem already.

Good night, Jan

Subject: mex compiling error

From: Stephan

Date: 23 Sep, 2009 12:08:21

Message: 9 of 20

"James Tursa" <aclassyguy_with_a_k_not_a_c@hotmail.com> wrote in message <h984l4$ft2$1@fred.mathworks.com>...
> "Stephan " <schmutz@pyl.unibe.ch> wrote in message <h9803b$fkp$1@fred.mathworks.com>...
> >
> > So how can I initialize the array at run time?
>
> One method using the API functions:
>
> int const nrOfFrames = (int)mxGetScalar(prhs[0]); // Input variable, nr. of frames to load
> // Put it checks here for valid nrOfFrames value
> BYTE **pData; // Used for allocated array of Pointers for image data
> pData = (BYTE **) mxMalloc(nrOfFrames*sizeof(*pData));
> if( pData == NULL ) { // not really needed since MATLAB will exit the mex function if you run out of memory
> mexErrMsgTxt("Unable to allocate pData.");
> }
> // other code here to use pData
> mxFree(pData); // free the memory when you are done with it
>
> P.S. Variable Length Arrays, where the array size is determined at run-time, *are* part of the current C Standard, but they are *not* part of the C++ standard. Having said that, many popular C compilers such as Microsoft Visual C (at least up to 8 ... I haven't tried 9 yet) and the lcc that ships with MATLAB, do not support Variable Length Arrays yet.
>
> James Tursa

Thanks James, if I initialize it as you said, it works absolutely perfect!

Subject: mex compiling error

From: Rune Allnor

Date: 23 Sep, 2009 13:38:48

Message: 10 of 20

On 21 Sep, 23:33, "Jan Simon" <matlab.THIS_Y...@nMINUSsimon.de> wrote:
> Dear Stephan, dear Rune!
>
> > >  I did C-Courses during my education, but it's been a while.
> > If you ever had a C course, you would know about memory allocation.
> > > If you are a C-pro and my posts are annoying to you, just ignore them! You really don't have to answer them, but I think those user-communities are exactly to ask questions like that. So if any polite people want to answer my questions, feel free...
>
> > If you don't have the time to look up your own old class notes,
> > pain and misery will follow. This is not the place to get free
> > C education or to have C programs debugged.
>
> > If you are in such a hurry to get a result, code matlab.
>
> If Stephan states, that he did his C-courses, then he did his C-courses.
> Here is not the place for inpolite allegations, Rune.

If somebody claims they took a class on the C programming
language and still make the kinds of errors as the OP here,
which happens to be at the core of the C programming technique,
there are only a limited number of options:

1) The claim is false - no course was ever taken.

> This is a forum for Matlab related problems. Stephan's problem appears at compiling a MEX source,

The problem stems from a total lack of understanding of the
C programming language.

> therefore he is absolutely welcome to ask and he has no reason to legitimate, why he dared to make a mistake with the fiddly C-memory-handling.
>
> Rune: Three days ago you told us, that we should use C++ to get the results fast and peoples are working to death caused by Matlab (http://www.mathworks.com/matlabcentral/newsreader/view_thread/261124). Now you recommend using Matlab, if we are in a hurry. What's up?

Interestingly, you wrote in the same thread

"Program time = programing time + debug time + run time."

But since you asked, I will give spoon-feed an answer:
There is a difference between

1) The time spent on producing working code
2) The time spent waiting for working code to execute.

The OP claims he is in too much of a hurry to learn hor to
use the C programming language. He is trying to produce a
program. The case I was talking about related to people
using programs that took far too long to execute.

Just out of curiosity, what inferences should I make about
your intellectual abilities that you seem unable to project
the same argument you yourself presented in some other
context, to the present case?

Rune

Subject: mex compiling error

From: Jan Simon

Date: 25 Sep, 2009 10:01:05

Message: 11 of 20

Dear Rune!

> Just out of curiosity, what inferences should I make about
> your intellectual abilities that you seem unable to project
> the same argument you yourself presented in some other
> context, to the present case?

Nice try, but easy to answer:
Neither the OP nor me is interested in your inferences about my intellectual abilities, because they do not help to solve the OP's problem.

This is a Matlab related forum. Hence your trials to offend users are simply not relevant.

Kind regards, Jan

Subject: mex compiling error

From: Jan Simon

Date: 25 Sep, 2009 15:51:03

Message: 12 of 20

Dear James, dear Stephan!

> James Tursa wrote:
> P.S. Variable Length Arrays, where the array size is determined at run-time, *are* part of the current C Standard, but they are *not* part of the C++ standard. Having said that, many popular C compilers such as Microsoft Visual C (at least up to 8 ... I haven't tried 9 yet) and the lcc that ships with MATLAB, do not support Variable Length Arrays yet.

Apart from Rune's personal opinion about valid C-code, the current LCC 3.8.? does support variable length arrays of the C99 standard:
  http://www.cs.virginia.edu/~lcc-win32/
Matlab R2009a (most likely 2009b also) does not recognize this LCC version automatically in "mex -setup", but it is easy to modify the mexopts.bat of the shipped LCC 2.4.1 (adjust the paths, disable the RSP-file support!).

For an explanation about variable length arrays of the C99 standard see also:
  http://en.wikipedia.org/wiki/Variable-length_array
  http://www.ddj.com/cpp/184401444

Kind regards, Jan

Subject: mex compiling error

From: James Tursa

Date: 2 Oct, 2009 06:31:39

Message: 13 of 20

"Jan Simon" <matlab.THIS_YEAR@nMINUSsimon.de> wrote in message <h9iot7$n89$1@fred.mathworks.com>...
> Dear James, dear Stephan!
>
> > James Tursa wrote:
> > P.S. Variable Length Arrays, where the array size is determined at run-time, *are* part of the current C Standard, but they are *not* part of the C++ standard. Having said that, many popular C compilers such as Microsoft Visual C (at least up to 8 ... I haven't tried 9 yet) and the lcc that ships with MATLAB, do not support Variable Length Arrays yet.
>
> Apart from Rune's personal opinion about valid C-code, the current LCC 3.8.? does support variable length arrays of the C99 standard:
> http://www.cs.virginia.edu/~lcc-win32/
> Matlab R2009a (most likely 2009b also) does not recognize this LCC version automatically in "mex -setup", but it is easy to modify the mexopts.bat of the shipped LCC 2.4.1 (adjust the paths, disable the RSP-file support!).
>
> For an explanation about variable length arrays of the C99 standard see also:
> http://en.wikipedia.org/wiki/Variable-length_array
> http://www.ddj.com/cpp/184401444
>
> Kind regards, Jan

Thanks, Jan. I don't have this version of lcc installed, but maybe when I get some time I will download it and try to hook it up with MATLAB.

FYI, there was a thread some time ago on comp.lang.c (3/5/2008 with the title "Variable length arrays") that discussed VLA use with the lcc compiler. Seems that lcc does *not* free up the dynamic memory allocated to VLA variables when they go out of scope. So a simple loop with a VLA variable that only has scope in the loop continuously eats up memory and eventually crashes the program (allocates a new VLA variable on each iteration of the loop without freeing the previous VLA variable). The lcc author apparently doesn't consider this a bug, but others do. I am not a C Standard expert, so I don't know about the conformance of this, but IMO it is a serious flaw in the compiler that needs fixing even if it isn't strictly a conformance "bug".

James Tursa

Subject: mex compiling error

From: Stephan

Date: 7 Oct, 2009 13:05:19

Message: 14 of 20

Rune Allnor <allnor@tele.ntnu.no> wrote in message <f09dd58b-0fa9-43d5-a59f-a6b0f8bcfbde@o13g2000vbl.googlegroups.com>...
> On 21 Sep, 23:33, "Jan Simon" <matlab.THIS_Y...@nMINUSsimon.de> wrote:
> > Dear Stephan, dear Rune!
> >
> > > > ?I did C-Courses during my education, but it's been a while.
> > > If you ever had a C course, you would know about memory allocation.
> > > > If you are a C-pro and my posts are annoying to you, just ignore them! You really don't have to answer them, but I think those user-communities are exactly to ask questions like that. So if any polite people want to answer my questions, feel free...
> >
> > > If you don't have the time to look up your own old class notes,
> > > pain and misery will follow. This is not the place to get free
> > > C education or to have C programs debugged.
> >
> > > If you are in such a hurry to get a result, code matlab.
> >
> > If Stephan states, that he did his C-courses, then he did his C-courses.
> > Here is not the place for inpolite allegations, Rune.
>
> If somebody claims they took a class on the C programming
> language and still make the kinds of errors as the OP here,
> which happens to be at the core of the C programming technique,
> there are only a limited number of options:
>
> 1) The claim is false - no course was ever taken.
>
> > This is a forum for Matlab related problems. Stephan's problem appears at compiling a MEX source,
>
> The problem stems from a total lack of understanding of the
> C programming language.
>
> > therefore he is absolutely welcome to ask and he has no reason to legitimate, why he dared to make a mistake with the fiddly C-memory-handling.
> >
> > Rune: Three days ago you told us, that we should use C++ to get the results fast and peoples are working to death caused by Matlab (http://www.mathworks.com/matlabcentral/newsreader/view_thread/261124). Now you recommend using Matlab, if we are in a hurry. What's up?
>
> Interestingly, you wrote in the same thread
>
> "Program time = programing time + debug time + run time."
>
> But since you asked, I will give spoon-feed an answer:
> There is a difference between
>
> 1) The time spent on producing working code
> 2) The time spent waiting for working code to execute.
>
> The OP claims he is in too much of a hurry to learn hor to
> use the C programming language. He is trying to produce a
> program. The case I was talking about related to people
> using programs that took far too long to execute.
>
> Just out of curiosity, what inferences should I make about
> your intellectual abilities that you seem unable to project
> the same argument you yourself presented in some other
> context, to the present case?
>
> Rune

Rune, as I said: I did a C-course, but it's been a while. Maybe there are people on this planet, unlike you, which are not sitting 24 hours a day in front of a computer and programming C. I'm also doing other things in my job and my spare time. Is it your hobby, reading treads and acting as you invented the C language?! Seems you really have problems in dealing with people. I (and as it looks like also other people) really neither need your help nor your personal opinion about anything!!!

Subject: mex compiling error

From: Rune Allnor

Date: 7 Oct, 2009 13:31:53

Message: 15 of 20

On 7 Okt, 15:05, "Stephan " <schm...@pyl.unibe.ch> wrote:
> Rune Allnor <all...@tele.ntnu.no> wrote in message <f09dd58b-0fa9-43d5-a59f-a6b0f8bcf...@o13g2000vbl.googlegroups.com>...
> > On 21 Sep, 23:33, "Jan Simon" <matlab.THIS_Y...@nMINUSsimon.de> wrote:
> > > Dear Stephan, dear Rune!
>
> > > > > ?I did C-Courses during my education, but it's been a while.
> > > > If you ever had a C course, you would know about memory allocation.
> > > > > If you are a C-pro and my posts are annoying to you, just ignore them! You really don't have to answer them, but I think those user-communities are exactly to ask questions like that. So if any polite people want to answer my questions, feel free...
>
> > > > If you don't have the time to look up your own old class notes,
> > > > pain and misery will follow. This is not the place to get free
> > > > C education or to have C programs debugged.
>
> > > > If you are in such a hurry to get a result, code matlab.
>
> > > If Stephan states, that he did his C-courses, then he did his C-courses.
> > > Here is not the place for inpolite allegations, Rune.
>
> > If somebody claims they took a class on the C programming
> > language and still make the kinds of errors as the OP here,
> > which happens to be at the core of the C programming technique,
> > there are only a limited number of options:
>
> > 1) The claim is false - no course was ever taken.
>
> > > This is a forum for Matlab related problems. Stephan's problem appears at compiling a MEX source,
>
> > The problem stems from a total lack of understanding of the
> > C programming language.
>
> > > therefore he is absolutely welcome to ask and he has no reason to legitimate, why he dared to make a mistake with the fiddly C-memory-handling.
>
> > > Rune: Three days ago you told us, that we should use C++ to get the results fast and peoples are working to death caused by Matlab (http://www.mathworks.com/matlabcentral/newsreader/view_thread/261124). Now you recommend using Matlab, if we are in a hurry. What's up?
>
> > Interestingly, you wrote in the same thread
>
> > "Program time = programing time + debug time + run time."
>
> > But since you asked, I will give spoon-feed an answer:
> > There is a difference between
>
> > 1) The time spent on producing working code
> > 2) The time spent waiting for working code to execute.
>
> > The OP claims he is in too much of a hurry to learn hor to
> > use the C programming language. He is trying to produce a
> > program. The case I was talking about related to people
> > using programs that took far too long to execute.
>
> > Just out of curiosity, what inferences should I make about
> > your intellectual abilities that you seem unable to project
> > the same argument you yourself presented in some other
> > context, to the present case?
>
> > Rune
>
> Rune, as I said: I did a C-course, but it's been a while. Maybe there are people on this planet, unlike you, which are not sitting 24 hours a day in front of a computer and programming C.

I am sure there are. The only reason I was able to learn C
was that at a certain time, I spent three or four months
programming C 12-16 hrs a day. That's what it takes to
be able to work more or less effortlessly with C.

If you are not willing - or able - to spend a similar effort,
C is not the language for you.

> I'm also doing other things in my job and my spare time. Is it your hobby, reading treads and acting as you invented the C language?! Seems you really have problems in dealing with people. I (and as it looks like also other people) really neither need your help nor your personal opinion about anything!!!

Just be aware that when you program C, you do not deal
with people. Unlike people, who might offer some leeway
and slack when you communicate with them, the C language
is designed such that it will give you *exactly* what you
ask for: It is *your* responsibility as programmer to
ask for what you want.

If you are not willing - or able - to work on those terms,
C is not the language for you.

Rune

Subject: mex compiling error

From: Stephan

Date: 7 Oct, 2009 13:44:02

Message: 16 of 20

Rune Allnor <allnor@tele.ntnu.no> wrote in message <7fc181c5-fc69-4d83-ae9f-b4758e3b013d@j19g2000vbp.googlegroups.com>...
> On 7 Okt, 15:05, "Stephan " <schm...@pyl.unibe.ch> wrote:
> > Rune Allnor <all...@tele.ntnu.no> wrote in message <f09dd58b-0fa9-43d5-a59f-a6b0f8bcf...@o13g2000vbl.googlegroups.com>...
> > > On 21 Sep, 23:33, "Jan Simon" <matlab.THIS_Y...@nMINUSsimon.de> wrote:
> > > > Dear Stephan, dear Rune!
> >
> > > > > > ?I did C-Courses during my education, but it's been a while.
> > > > > If you ever had a C course, you would know about memory allocation.
> > > > > > If you are a C-pro and my posts are annoying to you, just ignore them! You really don't have to answer them, but I think those user-communities are exactly to ask questions like that. So if any polite people want to answer my questions, feel free...
> >
> > > > > If you don't have the time to look up your own old class notes,
> > > > > pain and misery will follow. This is not the place to get free
> > > > > C education or to have C programs debugged.
> >
> > > > > If you are in such a hurry to get a result, code matlab.
> >
> > > > If Stephan states, that he did his C-courses, then he did his C-courses.
> > > > Here is not the place for inpolite allegations, Rune.
> >
> > > If somebody claims they took a class on the C programming
> > > language and still make the kinds of errors as the OP here,
> > > which happens to be at the core of the C programming technique,
> > > there are only a limited number of options:
> >
> > > 1) The claim is false - no course was ever taken.
> >
> > > > This is a forum for Matlab related problems. Stephan's problem appears at compiling a MEX source,
> >
> > > The problem stems from a total lack of understanding of the
> > > C programming language.
> >
> > > > therefore he is absolutely welcome to ask and he has no reason to legitimate, why he dared to make a mistake with the fiddly C-memory-handling.
> >
> > > > Rune: Three days ago you told us, that we should use C++ to get the results fast and peoples are working to death caused by Matlab (http://www.mathworks.com/matlabcentral/newsreader/view_thread/261124). Now you recommend using Matlab, if we are in a hurry. What's up?
> >
> > > Interestingly, you wrote in the same thread
> >
> > > "Program time = programing time + debug time + run time."
> >
> > > But since you asked, I will give spoon-feed an answer:
> > > There is a difference between
> >
> > > 1) The time spent on producing working code
> > > 2) The time spent waiting for working code to execute.
> >
> > > The OP claims he is in too much of a hurry to learn hor to
> > > use the C programming language. He is trying to produce a
> > > program. The case I was talking about related to people
> > > using programs that took far too long to execute.
> >
> > > Just out of curiosity, what inferences should I make about
> > > your intellectual abilities that you seem unable to project
> > > the same argument you yourself presented in some other
> > > context, to the present case?
> >
> > > Rune
> >
> > Rune, as I said: I did a C-course, but it's been a while. Maybe there are people on this planet, unlike you, which are not sitting 24 hours a day in front of a computer and programming C.
>
> I am sure there are. The only reason I was able to learn C
> was that at a certain time, I spent three or four months
> programming C 12-16 hrs a day. That's what it takes to
> be able to work more or less effortlessly with C.
>
> If you are not willing - or able - to spend a similar effort,
> C is not the language for you.
>
> > I'm also doing other things in my job and my spare time. Is it your hobby, reading treads and acting as you invented the C language?! Seems you really have problems in dealing with people. I (and as it looks like also other people) really neither need your help nor your personal opinion about anything!!!
>
> Just be aware that when you program C, you do not deal
> with people. Unlike people, who might offer some leeway
> and slack when you communicate with them, the C language
> is designed such that it will give you *exactly* what you
> ask for: It is *your* responsibility as programmer to
> ask for what you want.
>
> If you are not willing - or able - to work on those terms,
> C is not the language for you.
>
> Rune

Rune, you're not listening: I'm not interested in your opinion.
Stephan

Subject: mex compiling error

From: Rune Allnor

Date: 7 Oct, 2009 16:32:13

Message: 17 of 20

On 7 Okt, 15:44, "Stephan " <schm...@pyl.unibe.ch> wrote:
> Rune Allnor <all...@tele.ntnu.no> wrote in message <7fc181c5-fc69-4d83-ae9f-b4758e3b0...@j19g2000vbp.googlegroups.com>...
> > On 7 Okt, 15:05, "Stephan " <schm...@pyl.unibe.ch> wrote:
> > > Rune Allnor <all...@tele.ntnu.no> wrote in message <f09dd58b-0fa9-43d5-a59f-a6b0f8bcf...@o13g2000vbl.googlegroups.com>...
> > > > On 21 Sep, 23:33, "Jan Simon" <matlab.THIS_Y...@nMINUSsimon.de> wrote:
> > > > > Dear Stephan, dear Rune!
>
> > > > > > > ?I did C-Courses during my education, but it's been a while.
> > > > > > If you ever had a C course, you would know about memory allocation.
> > > > > > > If you are a C-pro and my posts are annoying to you, just ignore them! You really don't have to answer them, but I think those user-communities are exactly to ask questions like that. So if any polite people want to answer my questions, feel free...
>
> > > > > > If you don't have the time to look up your own old class notes,
> > > > > > pain and misery will follow. This is not the place to get free
> > > > > > C education or to have C programs debugged.
>
> > > > > > If you are in such a hurry to get a result, code matlab.
>
> > > > > If Stephan states, that he did his C-courses, then he did his C-courses.
> > > > > Here is not the place for inpolite allegations, Rune.
>
> > > > If somebody claims they took a class on the C programming
> > > > language and still make the kinds of errors as the OP here,
> > > > which happens to be at the core of the C programming technique,
> > > > there are only a limited number of options:
>
> > > > 1) The claim is false - no course was ever taken.
>
> > > > > This is a forum for Matlab related problems. Stephan's problem appears at compiling a MEX source,
>
> > > > The problem stems from a total lack of understanding of the
> > > > C programming language.
>
> > > > > therefore he is absolutely welcome to ask and he has no reason to legitimate, why he dared to make a mistake with the fiddly C-memory-handling.
>
> > > > > Rune: Three days ago you told us, that we should use C++ to get the results fast and peoples are working to death caused by Matlab (http://www.mathworks.com/matlabcentral/newsreader/view_thread/261124). Now you recommend using Matlab, if we are in a hurry. What's up?
>
> > > > Interestingly, you wrote in the same thread
>
> > > > "Program time = programing time + debug time + run time."
>
> > > > But since you asked, I will give spoon-feed an answer:
> > > > There is a difference between
>
> > > > 1) The time spent on producing working code
> > > > 2) The time spent waiting for working code to execute.
>
> > > > The OP claims he is in too much of a hurry to learn hor to
> > > > use the C programming language. He is trying to produce a
> > > > program. The case I was talking about related to people
> > > > using programs that took far too long to execute.
>
> > > > Just out of curiosity, what inferences should I make about
> > > > your intellectual abilities that you seem unable to project
> > > > the same argument you yourself presented in some other
> > > > context, to the present case?
>
> > > > Rune
>
> > > Rune, as I said: I did a C-course, but it's been a while. Maybe there are people on this planet, unlike you, which are not sitting 24 hours a day in front of a computer and programming C.
>
> > I am sure there are. The only reason I was able to learn C
> > was that at a certain time, I spent three or four months
> > programming C 12-16 hrs a day. That's what it takes to
> > be able to work more or less effortlessly with C.
>
> > If you are not willing - or able - to spend a similar effort,
> > C is not the language for you.
>
> > > I'm also doing other things in my job and my spare time. Is it your hobby, reading treads and acting as you invented the C language?! Seems you really have problems in dealing with people. I (and as it looks like also other people) really neither need your help nor your personal opinion about anything!!!
>
> > Just be aware that when you program C, you do not deal
> > with people. Unlike people, who might offer some leeway
> > and slack when you communicate with them, the C language
> > is designed such that it will give you *exactly* what you
> > ask for: It is *your* responsibility as programmer to
> > ask for what you want.
>
> > If you are not willing - or able - to work on those terms,
> > C is not the language for you.
>
> > Rune
>
> Rune, you're not listening: I'm not interested in your opinion.

No opinions, only facts: You don't have what it takes to
use C as a programming language.

Your personal opinions about people who bring such facts
to your attention are irrelevant. Unless you are as stupid
as you come across, you will know I am right.

Rune

Subject: mex compiling error

From: Jan Simon

Date: 7 Oct, 2009 19:52:03

Message: 18 of 20

Dear Stephan!

You've written:
> Rune, calm down a bit... breathe in - breathe out!!! Better now?

This was a kind reaction to a rude rejection. I will remember this.

> int const nrOfFrames = (int)mxGetScalar(prhs[0]);
> BYTE *pData[nrOfFrames];
>
> cameraTest.cpp(40) : error C2057: expected constant expression

Rune does not realize, that your example is valid C99 style (e.g. LCC 3.8 does compile it without errors) and the problem was just the C++ compiler. Usually his replies are meaningful, competent and valuable for beginners and advanced Matlab programmers.
I could'nt comprehend, why he looses control here (and in other C-related threads) with such a disgusting accent. I asked Google and, in fact, now it's clearer to me.

Kind regards, Jan

Subject: mex compiling error

From: Rune Allnor

Date: 8 Oct, 2009 08:44:01

Message: 19 of 20

On 7 Okt, 21:52, "Jan Simon" <matlab.THIS_Y...@nMINUSsimon.de> wrote:

> Rune does not realize, that your example is valid C99 style (e.g. LCC 3.8 does compile it without errors) and the problem was just the C++ compiler.

It seems you don't realize what game one plays when one
starts playing with C like the Sourcerer's Apprentice.
From a similar thread a couple of days ago:

http://groups.google.no/group/comp.soft-sys.matlab/msg/72e63bfc8f1a7860?hl=no

   "Re rogue pointers--that is *exactly* what happens. After one
   of these crashes Matlab becomes completely unpredictable.
Sometimes
   I can keep going. Other times (and at other stages of debugging)
   it will close immediately, Windows will give me a (fatal) runtime
   error, or--my favorite--it won't return to the command line and
   won't let me close it, either, giving me an error message when I
   try to do so. Anyway my program isn't that long nor does it do
   anything beyond standard file I/O so hopefully I'll be able to
   sort it out soon."

The guy who posted this has a chance of getting his problems
sorted because of one thing, and one thing alone: He understands
that he does not know. He understand that he needs to learn.
He understands - not least because he has discoverd it the hard
way - what's at risk if you get even the slightest detail wrong.

So he will understadn the only two choises open to him:

1) Disregard C totally, and stick with simpler, more forgiving
   languages
2) Spend the time and effort needed to actually learn C

Both you and Stephan claim that you know soemthing about C, and
about programming. There is no way anyone can check your claims.
However, nothing in your writings indicate with the slightest hint
that you have been anywhere near these kinds of problems, or have
had to sort out such types of bugs.

Anyone with even rudimentary knowledge of C would have.

Rune

Subject: mex compiling error

From: Stiphu

Date: 8 Oct, 2009 08:55:02

Message: 20 of 20

"Jan Simon" <matlab.THIS_YEAR@nMINUSsimon.de> wrote in message <hairh3$iip$1@fred.mathworks.com>...
> Dear Stephan!
>
> You've written:
> > Rune, calm down a bit... breathe in - breathe out!!! Better now?
>
> This was a kind reaction to a rude rejection. I will remember this.
>
> > int const nrOfFrames = (int)mxGetScalar(prhs[0]);
> > BYTE *pData[nrOfFrames];
> >
> > cameraTest.cpp(40) : error C2057: expected constant expression
>
> Rune does not realize, that your example is valid C99 style (e.g. LCC 3.8 does compile it without errors) and the problem was just the C++ compiler. Usually his replies are meaningful, competent and valuable for beginners and advanced Matlab programmers.
> I could'nt comprehend, why he looses control here (and in other C-related threads) with such a disgusting accent. I asked Google and, in fact, now it's clearer to me.
>
> Kind regards, Jan

Hi Jan

I know what you mean. I also read the open letter to Rune Allnor, looks like Rune is a bit dissatisfied with himself :-) Anyways, I'm not going to comment anymore threads of this childish, impolite and rude guy...
I programmed now the interface for the camera in C++, everything works perfect. No more memory-trouble at all. I'm using the "Microsoft Visual C++ 2008 SP1" compiler, also no problems with freeing up dynamic allocated space using mxFree.

Cheers Stephan

Tags for this Thread

Everyone's Tags:

Add a New Tag:

Separated by commas
Ex.: root locus, bode

What are tags?

A tag is like a keyword or category label associated with each thread. Tags make it easier for you to find threads of interest.

Anyone can tag a thread. Tags are public and visible to everyone.

Tag Activity for This Thread
Tag Applied By Date/Time
abuse Jan Simon 7 Oct, 2009 15:54:05
offense Jan Simon 7 Oct, 2009 15:54:05
memory allocation Stiphu 21 Sep, 2009 08:34:20
constant Stiphu 21 Sep, 2009 08:34:20
compiling error Stiphu 21 Sep, 2009 08:34:20
mex Stiphu 21 Sep, 2009 08:34:20
rssFeed for this Thread
 

MATLAB Central Terms of Use

NOTICE: Any content you submit to MATLAB Central, including personal information, is not subject to the protections which may be afforded information collected under other sections of The MathWorks, Inc. Web site. You are entirely responsible for all content that you upload, post, e-mail, transmit or otherwise make available via MATLAB Central. The MathWorks does not control the content posted by visitors to MATLAB Central and, does not guarantee the accuracy, integrity, or quality of such content. Under no circumstances will The MathWorks be liable in any way for any content not authored by The MathWorks, or any loss or damage of any kind incurred as a result of the use of any content posted, e-mailed, transmitted or otherwise made available via MATLAB Central. Read the complete Terms prior to use.

Contact us at files@mathworks.com