CppUnit



  • @Bulb Expected 1 (int32), received 1 (int64). Or similar.

    Types don't match.


  • Winner of the 2016 Presidential Election

    @Bulb said in CppUnit:

    The main problem is they are using C++ as if it was Java and in fact most of the code was initially converted from Java, apparently mostly using some tool.

    Hey, we have some code that went the opposite direction (C++ -> Java), also with the help of some tool. Also - supposedly - for portability reasons. Only the bravest developers go there…


  • Winner of the 2016 Presidential Election

    @blakeyrat said in CppUnit:

    Expected 1 (int32), received 1 (int64). Or similar.
    Types don't match.

    Interesting idea. I guess if someone defined an operator== for two different integer types (which would be TRWTF), then integer conversion wouldn't happen.

    Can someone with more knowledge of the standard than me confirm that this would actually work?



  • @asdf At least one of there parameters of operator== must be a used-defined type (class or enum). Think this applies to most operators.

    Doesn't stop you from doing that, you just can't do it with the operator==, but the function/macro that does the test could still implement logic to detect different types even if they are otherwise compatible (such as checking for std::is_same<>, possibly after remove_cv/remove_reference/decay).

    If you do that, you probably need to start being really careful about your literals. So, assertsEqual( 1u, foo ) is very different from assertsEqual( 1, foo ). It also defeats any types that try to emulate other types, and constructs like owner<> or not_null<>. (Except for very special cases, I'd recommend against it.)


  • Winner of the 2016 Presidential Election

    @cvi said in CppUnit:

    At least one of there parameters of operator== must be a used-defined type (class or enum).

    Ah, right, I totally forgot about that.


  • Discourse touched me in a no-no place

    @cvi said in CppUnit:

    At least one of there parameters of operator== must be a used-defined type (class or enum). Think this applies to most operators.

    Also, the template is constraining both sides of the equality to be the same type.



  • @dkf said in CppUnit:

    Also, the template is constraining both sides of the equality to be the same type.

    Well, yeah, in that particular implementation. But if you were to make an as drastic change to the behaviour of assertEquals() as suggested, changes the method's signature would seem like a much less invasive change anyway.



  • @cvi Don't overthink it, I was just coming up with a way the variables could have the same printout but not "equal" in a way the testing framework expects. I have no idea if the framework checks types or not.





  • @dkf said in CppUnit:

    fun

    Ok, I just want to clear up a misconception here.

    Losing is Fun.

    !!fun!! is fun that's on fire.

    !!Fun!! is losing while on fire.



  • @RaceProUK said in CppUnit:

    If you want a portable language for mobile, I only know of one practical choice: C#.

    I know about 3 practical options for creating multi-platform mobile applications:

    • Xamarin, using .NET language (usually C#, but can be anything else that compiles to CLR). Disadvantage is that it is still rather expensive.
    • Qt, using C++. Free for Android and cheaper for other platforms (it is actually available under LGPL for all of them, but AppStore and LiveStore terms of service are intentionally incompatible with including a LGPL-licensed component).
    • Cordova. Unfortunately the WebAssembly is not exactly there yet, so if you need the power, you need a plugin and that is only portable in C++.

    Well, and fourth, write your own (stupid idea these days), and fifth, use something you already have in-house (because 10 years ago it was somewhat less stupid). But these again mean C++.



  • @wharrgarbl said in CppUnit:

    I wanted to find one ready-made, but they always want to implement some kind of garbage collection and put dependencies that are hard to port.

    There is Vala.

    The object system requires GLib, but it also has POSIX mode where it only uses standard C and POSIX library if you can live without inheritance. Memory management is just by injecting appropriate copy and delete operations (which are copy and delete for value types and reference counting for reference types.

    It is also relatively simple to describe use of any C library for it (it is not wrapping, because all you do is map the Vala names to C names). And it generates C, including public header, so you can call it from other C code.


  • FoxDev

    @Bulb said in CppUnit:

    Xamarin, using .NET language (usually C#, but can be anything else that compiles to CLR). Disadvantage is that it is still rather expensive.

    Actually, it's free with VS2015 Community Edition, which is also free 😉


  • Notification Spam Recipient

    @RaceProUK said in CppUnit:

    free

    "free"



  • @RaceProUK said in CppUnit:

    @Bulb said in CppUnit:

    Xamarin, using .NET language (usually C#, but can be anything else that compiles to CLR). Disadvantage is that it is still rather expensive.

    Actually, it's free with VS2015 Community Edition, which is also free 😉

    … for “Students, open-source projects, and non-enterprise up to 5 users”.


  • kills Dumbledore

    @Bulb said in CppUnit:

    non-enterprise

    They do define it, it's something like less than $500000 a year in revenue

    fake edit: less than 250 PCs or a million dollars

    enterprise organizations (meaning those with >250 PCs or >$1 Million US Dollars in annual revenue)

    source: https://www.visualstudio.com/vs/community/



  • @Jaloopa Ok, that makes it somewhat more affordable.



  • @Bulb said in CppUnit:

    it only uses standard C and POSIX library

    Already more than I have. Device makers replaced stdlib with their own incompatible shit. Porting stuff to this platform is a nightmare.



  • @wharrgarbl It might still be possible to get it running. The compiler should not actually hard-code calls to functions. Everything is described in .vapi files, which describe the mapping between Vala and C. It should be possible to write that for the non-standard API you have and tell the compiler to use that instead of the standard POSIX.vapi and get the posix mode to work. The initialization, copying/referencing and clean-up don't need much.

    The other option would be to try to get LLVM compile for the target and try Rust. There are people using Rust for various obscure controllers, so with a bit of luck, somebody might have already got it to work. And if not, as long as LLVM knows the instruction set, configuring it for specific system seems not that complicated. It is not compiled to C, but it can import C functions and export functions to C, the #[no_str] mode does not need much either, and it can provide much more safety.



  • @Bulb said in CppUnit:

    as long as LLVM knows the instruction set, configuring it for specific system seems not that complicated.

    Making llvm work with wtfdevice that runs wtfos written in C with an uncompatible library replacing stdlib doesn't sound viable.

    Vala doesn't require any library you say? It'll just generate C files?



  • @wharrgarbl said in CppUnit:

    Making llvm work with wtfdevice that runs wtfos written in C with an uncompatible library replacing stdlib doesn't sound viable.

    Have seen many blogs about people doing just that. Apparently as long as LLVM knows the instruction set (listed in llvm::Triple::ArchType), it is not that hard.

    @wharrgarbl said in CppUnit:

    Vala doesn't require any library you say? It'll just generate C files?

    I have not played with it for some years, but I believe yes. It just generates C files (that are even mostly readable!) and it should be fully configurable what functions it calls for each language feature.



  • @Bulb said in CppUnit:

    Have seen many blogs about people doing just that. Apparently as long as LLVM knows the instruction set (listed in llvm::Triple::ArchType), it is not that hard.

    Porting to a linux system with a different cpu is different to porting to a completely different system. Make rust run in a weird api wouldn't be any fun.

    Also, viable != possible



  • @Bulb said in CppUnit:

    I have not played with it for some years, but I believe yes. It just generates C files (that are even mostly readable!) and it should be fully configurable what functions it calls for each language feature.

    posix Vala seems kind of unsupported and requires "libc"



  • @wharrgarbl said in CppUnit:

    Making llvm work with wtfdevice that runs wtfos written in C with an uncompatible library replacing stdlib doesn't sound viable.

    LLVM is just a compiler. The standard library should be irrelevant.

    (I know it probably isn't, but it should)



  • @anonymous234 llvm isn't enough to run rust in a snowflake platform.

    The better I could get on this is something that translates to C without the need of any library and allow me to call my snowflake apis.

    It's just a thought exercise anyway, I could never get buy-in from the scared dinosaurs in charge for anything like this.



  • @wharrgarbl said in CppUnit:

    Porting to a linux system with a different cpu is different to porting to a completely different system. Make rust run in a weird api wouldn't be any fun.

    When I said “just that”, I did mean different system—or no system at all. It is actually where Rust brings the most benefits, because in microcontrollers you often need reliability and can't get it by slapping a collector on it.

    @wharrgarbl said in CppUnit:

    llvm isn't enough to run rust in a snowflake platform.

    Basically, yes, it is.

    Rust has this #[no_std] mode. The standard library is split approximately into 3 parts: core, collections and std.

    The core only needs only a few functions to be defined for the platform and can work even without memory allocator (in which case functionality is of course rather limited, but on microcontrollers it is common to do with just statically allocated storage).

    The collections do need allocator, but not much more. And the allocation functions are customizable.

    And then there is the full std, which adds filesystem access and process control and such. But you don't need that if you don't have those interfaces. Just bind what you have and need.

    It is a bit more fine-grained than this, but I don't remember the details off the top of my head.

    @anonymous234 said in CppUnit:

    LLVM is just a compiler. The standard library should be irrelevant.
    (I know it probably isn't, but it should)

    The standard library is irrelevant, but Rust does have some language items that need to be defined. Even C needs a support library for built-in constructs (gcc has libgcc, other compilers have similar libraries) on most platforms.

    But for the bare-bones Rust, just a handful of functions (called lang-items there) are required. And a handful more is optional, including dynamic allocation.

    @wharrgarbl said in CppUnit:

    posix Vala seems kind of unsupported and requires "libc"

    Pity. It looked like there might be some interest in that back then.


  • Discourse touched me in a no-no place

    @wharrgarbl said in CppUnit:

    Making llvm work with wtfdevice that runs wtfos

    That's actually not too bad, provided it already knows the CPU architecture. Working with LLVM itself is like working with an assembler (though an optimising one that doesn't require you to fuss around with the really low-level grime), not a conventional higher-level language. The OS really doesn't matter too much: you just call the existing basic interface lib you've got for C.

    More of a problem when targeting a small device with most languages is getting the language runtime ported in the space available. The size of language runtimes varies a lot, from C which has nearly zero actually mandatory stuff, to scripting languages like Perl6 which has a pretty chunky runtime. C# and Java, while able to target smallish systems, are usually configured to need a large runtime (and large runtimes do mean that you've got lots of capabilities available; C is only small if you don't want to do very much).



  • @Bulb I can believe you would be able to do it, but it doesn't look anything I would want to make and support, or take the blame when/if it backfires.

    Most of the simple ultra-portable and small libraries that can't go wrong simple restart this thing after I try to run it.



  • Yeah. Well, Rust would promise some increase in productivity here as it catches many mistakes that would lead to crashes (= restarts) earlier, but

    @wharrgarbl said in CppUnit:

    I could never get buy-in from the scared dinosaurs in charge for anything like this.

    without management being willing to take at least a bit of risk to give it a try there is not much point.



  • @asdf A type mismatch would abort compilation, so that wouldn't cause an issue at runtime.

    Also, you can't overload operators for built in types. Type promotion rules would handle comparing different types, converting the values to the same type before applying the comparison.


  • Winner of the 2016 Presidential Election

    @Kian said in CppUnit:

    A type mismatch would abort compilation, so that wouldn't cause an issue at runtime.

    No shit, Sherlock. ;)

    Once you forget that operators cannot be overloaded for built-in types for a second, people assume you're a complete noob, apparently.



  • @asdf I actually meant to reply to blakeyrat, which your post was replying to.