CIN nmake(MS) returns C2099

[brimcd]

Im trying to include header files in a CIN that has code like:

const int CONST1    = 512;

const int CONST2    = CONST1 - 1;

the second line fails with error error C2099: initializer is not a constant

MS nmake ver 8.00.50727.42

I'm not an nmake user, but it appears the Labview 8.2 cintools\ntlvsb.mak calls cl, which is:

MS C/C++ compiler ver 14.00.50727.42

anybody know why constants don't work here?

[rolfk]

---

@brimcd wrote:

Im trying to include header files in a CIN that has code like:

const int CONST1    = 512;

const int CONST2    = CONST1 - 1;

the second line fails with error error C2099: initializer is not a constant

MS nmake ver 8.00.50727.42

I'm not an nmake user, but it appears the Labview 8.2 cintools\ntlvsb.mak calls cl, which is:

MS C/C++ compiler ver 14.00.50727.42

anybody know why constants don't work here?

---

Are you sure you can do that in Visual C? After all it is using the same C compiler core I would assume. Not sure if what you want to do is really valid ANSI C. Probably not ANSI C 99 anyhow.

As it is in fact an MS tool error I'm quite sure there is nothing NI could do about that and not sure there is anything MS would want to do about that.

Rolf Kalbermatter

[brimcd]

---

@rolfk wrote:

---

@brimcd wrote:

Im trying to include header files in a CIN that has code like:

const int CONST1    = 512;

const int CONST2    = CONST1 - 1;

the second line fails with error error C2099: initializer is not a constant

MS nmake ver 8.00.50727.42

I'm not an nmake user, but it appears the Labview 8.2 cintools\ntlvsb.mak calls cl, which is:

MS C/C++ compiler ver 14.00.50727.42

anybody know why constants don't work here?

---

Are you sure you can do that in Visual C? After all it is using the same C compiler core I would assume. Not sure if what you want to do is really valid ANSI C. Probably not ANSI C 99 anyhow.

As it is in fact an MS tool error I'm quite sure there is nothing NI could do about that and not sure there is anything MS would want to do about that.

Rolf Kalbermatter

---

I certainly agree that neither NI nor MS is going to change the compiler to make my job easier!. After other discussions, I'm told that constants are a c++ feature not available in Ansi c compiler. So my last gasp effort, since the alternative is going to be a lot of manual dissecting of the header files, is whether there is a way to use the c++ compiler through the CIN procedure (modify the NI .mak file?).

Alternatively, I'll fall back to creating a dll in c++ and call that from the vi.

My ultimate issue here is trying to match up a large data array returned from a dll (not mine), mapped to a structure that I built in a vi, that includes arrays. Setting up a union in c works fine until I hit an array handle, where the size bytes in the handle mess up the alignment in memory (shift 4 bytes, return cluster via CIN, Labview crashes).

I expect there is no easy answer since the c and vi array definitions are different, so I'll move to dll creation unless someone has a brilliant idea.

Thanks,

Brian

[rolfk]

---

@brimcd wrote:

My ultimate issue here is trying to match up a large data array returned from a dll (not mine), mapped to a structure that I built in a vi, that includes arrays. Setting up a union in c works fine until I hit an array handle, where the size bytes in the handle mess up the alignment in memory (shift 4 bytes, return cluster via CIN, Labview crashes).

I expect there is no easy answer since the c and vi array definitions are different, so I'll move to dll creation unless someone has a brilliant idea.

---

Unless you use a very old version of LabVIEW there is absolutely no reason why you could not pass LabVIEW data directly to a DLL and work with it just as you could in a CIN. Check out the Adapt to Type datatype in the parameter configuration.

All functions documented in the External Code Reference Manual are also available in a DLL just as they are in a CIN, if you link labview.lib with your DLL project. This makes the DLL of course only operable when called by LabVIEW or a LabVIEW executable, but that is the same with CINs. So if you think you can handle your data alignements from LabVIEW to your C++ code in a CIN you can do the same in a DLL.

Advantage of a DLL is that you could compile the according object modules in C++ while you maintain a standard C exported API (this is required since the Call Library Node can only deal with standard C entry points but not with C++ objects or methods directly. Still you could compile your code in C++ and only tell the compiler to create specific exported functions as standard C export.

Rolf Kalbermatter