Using CppUTest Without C/C++ Libraries / RTTI

[A. Robert S.]

Hi,

 

I noticed in some other posts that it is possible to compile CppUTest so it will not use the C/C++ libraries or C++ exceptions. I am currently working with tests on a target where this might be advantageous. I did not find any information about this in the TDD book. My questions are:

• Where can I find more information on how to do this?
• What are the ramifications?
• Will my tests behave any different, and how?

Thanks,

A. Robert

 

[Bas Vodde]

Hi A. Robert,

Yes, I don't think it is in the book. You can configure CppUTest without exception handling/StdC++ lib via "configure -disable-std-cpp"

You can get the configure option via "configure --help".

CppUTest even allows you to compile without Standard C library!! (useful in kernel development), but in that care you do need to implement some functionality yourself :)

> • What are the ramifications?

Not much. If a test fails, then the destructors won't be called (as it will switch internally from exception handling to longjmp) and you can't do StringFrom with Standard C++ types. There should be no other effect to doing this as the rest of CppUTest doesn't depend on them.

> • Will my tests behave any different, and how?

Only difference is that the destructors won't be called when a test fails. This is only on test failure and usually you won't notice it.

Bas

> --
> You received this message because you are subscribed to the Google Groups "cpputest" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cpputest+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[A. Robert S.]

Thank you, Bas

 

I will try this for our embedded target.

 

Robert

[A. Robert S.]

On Thursday, June 6, 2013 12:42:19 PM UTC+2, Bas Vodde wrote:

Hi A. Robert,

Yes, I don't think it is in the book. You can configure CppUTest without exception handling/StdC++ lib via "configure -disable-std-cpp"

You can get the configure option via "configure --help".

Hi again!

 

Bas, I'm afraid I lost you here...

 

I usually build CppUTest using the supplied make scripts, e.g. "make everythingInstall". These don't take any options like the one you mention.

 

There also doesn't seem to be a script or executable like "configure.sh", "configure.bat" or any such thing.

 

When I build CppUTest for the target in question, I use that compiler's IDE and I would use pre-processor defines to configure anything.

 

Finally, these options make no sense to invoke on the test executable (and besides are not recognized by it, either).

 

I have to admit, I have no idea when or what to I should apply this option.

 

I am working with CppUTest 3.3

 

Thanks for enlightening me,

Arnd

 

[Bas Vodde]

Hiya,

> I am working with CppUTest 3.3

Oki, that explains. We changed the build quite a lot in 3.4 to have a more standard interface for Open Source projects…

Uhm, with 3.3 you needed to do -DDISABLE_MEMORY_LEAK_DETECTION or something like that (not remember, better use 3.4 :P)

Bas

Bas

>
> Thanks for enlightening me,
> Arnd
>
>

[A. Robert S.]

On Monday, June 10, 2013 11:10:59 AM UTC+2, Bas Vodde wrote:

Hiya,

> I am working with CppUTest 3.3

Oki, that explains. We changed the build quite a lot in 3.4 to have a more standard interface for Open Source projects…

Uhm, with 3.3 you needed to do -DDISABLE_MEMORY_LEAK_DETECTION or something like that (not remember, better use 3.4 :P)

Bas

 

Thanks for your quick reply!

 

I had a brief look at 3.4. There is a lot of implicit information there.... For starters, under Windows, I can call "make" directly. But I have to execute "sh configure" (or run sh first).

 

The configure script does an awful lot of things. How does that tie in with using a different IDE with a different set of compiler and libraries altogether? I find this a bit daunting.... Simply setting  -DDISABLE_MEMORY_LEAK_DETECTION or the like would seem more friendly. I noticed the options of the configure script would allow me to disable the standard C Library, or the Standard C++ Library, but not exception handling as such. Maybe not such a great idea, after all.....

 

I do use memory leak detection, and if memory leak detection depends on exception handling, then I guess I might have to stick with the whole package.

 

If I may digress, I had originally made the platform-specific putchar() into a fixed buffer on the target,which worked fine. Then I started experimenting with CCS's capability to redirect printf()/cout to the host system. It works, sort-of. But bad things are happening, like running out of memory etc. etc. It seems the target compiler's iostream implementation leaves to be desired. It would have been nice to have test output on the host system, but I think I'll go back to the fixed buffer approach. This particular compiler is giving me enough headaches already, so I'd better not add another one....

 

Talking about headaches -- did you see my other post about method overloading? Is there anything you can suggest I look at to determine why the compiler resolves the test code I've written correctly, and the CppUTestExt code incorrectly?

 

Thanks again for your help. It is much appreciated.

A. Robert

[Bas Vodde]

Hi Robert,

> Bas
>
> Thanks for your quick reply!
>
> I had a brief look at 3.4. There is a lot of implicit information there.... For starters, under Windows, I can call "make" directly. But I have to execute "sh configure" (or run sh first).

Yes, you can chose to either use cmake or configure. Both are the same (or very similar)

> The configure script does an awful lot of things. How does that tie in with using a different IDE with a different set of compiler and libraries altogether? I find this a bit daunting.... Simply setting -DDISABLE_MEMORY_LEAK_DETECTION or the like would seem more friendly. I noticed the options of the configure script would allow me to disable the standard C Library, or the Standard C++ Library, but not exception handling as such. Maybe not such a great idea, after all…..

Oh yeah, sorry, the -DDISBLE_MEMORY_LEAK_DETECTION is my mistake, I mean -DDISABLE_CPP_LIB (or something like that). The configure script actually offers quite a lot of additional checking on compatability. You want to switch off the Standard C++ library. If you do that, it will turn off exception handling. So far, I decided not to make any separate switch for exception handling as there aren't much dependencies with Standard C++ library and I guess it is impossible to have a Standard C++ library without exception handling. So, turning off StdC++ will turn off the exception handling :)

I'm not sure what IDE you are using? If you use Eclipse, then you can use either configure or cmake. For VS, you can better use cmake as it can generate the project files (configure won't do that)

> I do use memory leak detection, and if memory leak detection depends on exception handling, then I guess I might have to stick with the whole package.

Yes, that was my mistake. I was replying too fast and wrongly remembered that you didn't want memory leak detection (instead of didn't want exception handling).

> If I may digress, I had originally made the platform-specific putchar() into a fixed buffer on the target,which worked fine. Then I started experimenting with CCS's capability to redirect printf()/cout to the host system. It works, sort-of. But bad things are happening, like running out of memory etc. etc. It seems the target compiler's iostream implementation leaves to be desired. It would have been nice to have test output on the host system, but I think I'll go back to the fixed buffer approach. This particular compiler is giving me enough headaches already, so I'd better not add another one….

Did you try outputting with fprintf to stderr (so that it won't be buffered)?

> Talking about headaches -- did you see my other post about method overloading? Is there anything you can suggest I look at to determine why the compiler resolves the test code I've written correctly, and the CppUTestExt code incorrectly?

Yes, I saw the mail. I was a bit puzzled about it and didn't reply yet. I'll need to read it again and think a bit.

> Thanks again for your help. It is much appreciated.

Your welcome.

btw. I do work quite a lot on TI environments, but usually we actually don't execute unit tests on the target environment. Instead we set it up so that we run the unit tests on the development enviroment and switch the compiler to gcc. There are some benefits to also run them on the real hardware, but the benefits are kinda minimal compared to the effort you'll need to put in it….

So, you might want to re-consider running most unit tests on the hardware :)

Bas



> A. Robert

[A. Robert S.]

Good morning Bas,

First of all, I really appreciate your taking the time to "talk" to me.

> So, you might want to re-consider running most unit tests on the hardware :)

Oh, yes. Anytime. The reason I am into the hardware is my client.

There is a growing sentiment in the automobile industry here in Germany that unit tests should pass on the actual hardware, especially where functional safety is concerned.

So I suggested they use an approach with TDD approach off target, and run a subset of unit tests on the hardware only before releases.

Which, unfortunately, still means running CppUTest on the hardware...

> You want to switch off the Standard C++ library.

Will do.

> If you do that, it will turn off exception handling.

Good. TI promises a quantum performance hit just for enabling it ;-).

> Did you try outputting with fprintf to stderr (so that it won't be buffered)?

Actually, no, but I switched from cout to printf() for my "pilot" unit test and the problems went away. So using the Standard C++ Library on that system does not seem like a good idea anyway.

> I'm not sure what IDE you are using?

Although Code Composer Studio is Eclipse-based nowadays, my client insists on using CCS 3.3. It has quite a few quirks, but mostly works okay. Under Windows, I use Code::Blocks / MinGW for most things. I am used to hand-editing project files. So I will stick in the #define and see where that gets me.

> btw. I do work quite a lot on TI environments

I have done some work with the cc430 (sport's watch flavor) and the IAR IDE and that was a piece of cake, in comparison. It was my own work, so I never attempted to run CppUTest on the hardware. But all else was easier to begin with. For the few unit test that I felt I wanted to run on the hardware, I used plain C. I designed an "applet" to run them interactively from the watch's UI. Neat.

The TMS320F2335 DSP, on the other hand, is definitely not for the faint-hearted....
 
Well, thanks again, I will now build CppUTest without the Standard C++ Library and then let you know how it went.

Best wishes,
A. Robert

[Bas Vodde]

Hola,

> > So, you might want to re-consider running most unit tests on the hardware :)
>
> Oh, yes. Anytime. The reason I am into the hardware is my client.
>
> There is a growing sentiment in the automobile industry here in Germany that unit tests should pass on the actual hardware, especially where functional safety is concerned.

Interesting. I've only very rarely actually found defects with running it on hardware. The only things you'll find is:
- Differences in compiler bahavior (seems you earlier found one of these)
- Endianness
- Size differences of basic types

> So I suggested they use an approach with TDD approach off target, and run a subset of unit tests on the hardware only before releases.

Oki.

> Which, unfortunately, still means running CppUTest on the hardware…

Well, it is still possible :) It isn't that it isn't possible, it is just extra work for not very much benefits. But if it makes other people happy, I guess that are the benefits :P

> > Did you try outputting with fprintf to stderr (so that it won't be buffered)?
>
> Actually, no, but I switched from cout to printf() for my "pilot" unit test and the problems went away. So using the Standard C++ Library on that system does not seem like a good idea anyway.

Yeah, I wouldn't use StdC++ on these things.

> > I'm not sure what IDE you are using?
>
> Although Code Composer Studio is Eclipse-based nowadays, my client insists on using CCS 3.3. It has quite a few quirks, but mostly works okay. Under Windows, I use Code::Blocks / MinGW for most things. I am used to hand-editing project files. So I will stick in the #define and see where that gets me.

Oki. So, then using configure will probably do.

> > btw. I do work quite a lot on TI environments
>
> I have done some work with the cc430 (sport's watch flavor) and the IAR IDE and that was a piece of cake, in comparison. It was my own work, so I never attempted to run CppUTest on the hardware. But all else was easier to begin with. For the few unit test that I felt I wanted to run on the hardware, I used plain C. I designed an "applet" to run them interactively from the watch's UI. Neat.

Eheh. Well, as you probably know, CppUTest is structured and designed to work with old and embedded compilers, so it *shouldn't* be too much work. Similarly some people been using CppUTest for Linux Kernel development, which also provided interesting challenges related to Lib Standard C.

> The TMS320F2335 DSP, on the other hand, is definitely not for the faint-hearted….

Yeah :)

> Well, thanks again, I will now build CppUTest without the Standard C++ Library and then let you know how it went.

Oki, looking forward hearing about your 'advantures'

Bas

>
> Best wishes,

[A. Robert S.]

Hi again,

I added -d"CPPUTEST_STD_CPP_LIB_DISABLED" to the compiler command line in the IDE's project file, rebuilt CppUTest without a hitch, then linked the example project with the non-exception handling runtime support library.

Everybody is happier now :)

Robert

[vinayak hungund]

Hi Robert,

I have the same issue with CPPUTEST, i need to build it for energy micro EFM32CortexM0 controller. i'm not able to compile the cpputest with the default ARM 4.7.3 gcc.can you please help me ?

thanks.

[A. Robert S.]

Hi Vinayak,

 

Sorry - haven't been here for a while. I'm afraid I cannot help you beyond what is already posted here, because I am unfamiliar with your exact controller / compiler. I have worked with another ARM controller, but never even considered running CppUTest on there. There were a few tests I wanted to run on the target (more out of ambition than necessity), which I used plain C and some macros for.

 

If measures like disabling exceptions and not including the cpp stdandard library don't help, your target's memory is probably just too small.

 

Generally, I prefer running CppUTest on the PC and testing as much of our code as possible on the development platform, writing my code in such a way that as little as possible (driver, board support package,...) needs testing on the actual target.

 

Cheers,

Robert