What is this in a C++ structure

Discussion in 'Programmer's Corner' started by bug13, May 27, 2019.

  1. nsaspook

    AAC Fanatic!

    Aug 27, 2009
    5,698
    6,395
    Good points. I just think that the boost in software productivity for larger projects doesn't scale well into the smaller embedded domain with lots of hardware state complexity instead of algorithmic complexity and asynchronous interaction of complex abstract data objects. Efficient hardware implementation is the primary goal. If C types actually thought that native C++ would reduce the time it took to design the software for a complete bare-metal embedded system from scratch most would be on it like ducks on a June bug but we really don't see much enthusiasm for that. The learning it right part is important as there are 40 ways to do something in C++ but maybe only a few ways that actually can provide a boost in productivity when things go bad.

    Linux is written in C ( C being effectively portable assembly) and is at least somewhat responsible for the aversion to C++ for SoC development as almost every new system boots and uses some version of Linux as the base embedded OS. The Linux C based abstract machine seems sufficient for just about any hardware related task (writing programs for gadgets) with a large library of working C examples.
     
    Last edited: Jun 4, 2019
  2. bug13

    Thread Starter Senior Member

    Feb 13, 2012
    1,644
    62
    Would you mind telling me a bit more why you want to avoid those? I am very keen to know as I am leaning to use C++ in an embedded system. Thanks a lot!
     
  3. MrSoftware

    Senior Member

    Oct 29, 2013
    1,369
    426
    As with most things development related, I find it not a good idea to say never. There are often corner cases where life might actually be easier if you do things you don't normally do.

    That said; exceptions and templates can possibly lead to larger code (more memory required), depending on how they are written and used. I don't see a reason not to use namespaces, other than they may add unneeded complexity to a relatively small project.
     
  4. 402DF855

    Active Member

    Feb 9, 2013
    55
    16
    While namespaces seem like a good idea, I've seen in practice they seem to have the opposite of the intended result. In most cases you can avoid name overlap by using a different ID for a function or variable. I think the worst scenario uses multiple nested namespaces.

    Templates also seem a good idea, and have their place. But I've seen it abused to the point of making the language tortuously complicated, and for little or no benefit. Sometimes developers like to prove how clever they are rather than creating clear and accurate code. Iterators come to mind, a popular element of before mentioned C++ libraries. Really? Just use the tried and true for(i=0;i<n;i++).

    I've mentioned that function overloading is a nice addition to the language. But I'd argue that overloading the pointer dereference is somewhat evil. I've seen it used for reference counting in hopes of achieving automatic memory deallocation (garbage collection) and it made debugging a nightmare.

    Exceptions are Goto's from hell. Originally exceptions were designed for really obscure hardware type failures requiring extreme mitigation to handle safely. In practice people use them as normal function semantics rather than returning a success flag or enum. Code becomes bloated with try/catch clauses. If a function encounters a pathological condition, return an error flag and leave it to the caller to deal with it. Throwing an exception and hoping some function call further up the stack will handle it is dangerous and just poor design IMO.
     
    bug13 and nsaspook like this.
  5. 402DF855

    Active Member

    Feb 9, 2013
    55
    16
    Here are examples I've cherry picked from a project I participated in.
    Code (C):
    1. ::x::Service::Pointer list_serve( xxlib::service::x::Namespace::entry::list::create() );
    Code (C):
    1. return  ::boost::xmath::policies::detail::raise_a_domain_error(
    2.            func, msg, avalue,  ::boost::xmath::policies::domain_error< ::boost::math::policies::errno_on_error>());
    Imagine a hundred source files saturated with this sort of thing. I tolerated it, but was never convinced this was good design.
     
  6. bug13

    Thread Starter Senior Member

    Feb 13, 2012
    1,644
    62
    This does look bad!
     
Loading...