Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
C++ for industrial automation
999 views
Skip to first unread message
jono...@googlemail.com
Jan 27, 2015, 1:10:03 PM1/27/15
to
Hi there,
are there any good methods, of using C++ for industrial automation systems?
Any patterns, frameworks, practices, etc?
* How can one conveniently handle
- hardware access
- hardware extensibility
- variants
?
* Shared resources?
* Callbacks? Signals slots?
* How can one prevent it from becoming a huge unmaintainable mess?
Thanks for your ideas and advice.
are there any good methods, of using C++ for industrial automation systems?
Any patterns, frameworks, practices, etc?
* How can one conveniently handle
- hardware access
- hardware extensibility
- variants
?
* Shared resources?
* Callbacks? Signals slots?
* How can one prevent it from becoming a huge unmaintainable mess?
Thanks for your ideas and advice.
jono...@googlemail.com
Jan 27, 2015, 1:34:48 PM1/27/15
to
Would you use a cyclic methodology, with functions recurring at regular intervals? (some more frequently than others, while others more seldom) A kind of timeslice method?
Or would you use an event-based method?
(What about using C++ on top of embedded linux?)
Öö Tiib
Jan 27, 2015, 10:51:08 PM1/27/15
to
Lot of it is written in C++.
jono...@googlemail.com
Jan 28, 2015, 11:16:07 AM1/28/15
to
On Wednesday, January 28, 2015 at 4:51:08 AM UTC+1, Öö Tiib wrote:
>
> There are millions of lines worth of software in a factory.
> Lot of it is written in C++.
I'm sorry... but your brief reply is incredible on so many levels, that I don't know what to say.
>
> There are millions of lines worth of software in a factory.
> Lot of it is written in C++.
A dose of reality might be in order:
You've probably never heard of PLCs. To present an alternative to your statement from above:
There is a lot of software in a factory.
Lot of it is written in IEC 61131-3. (Often it is interfaced to Scada Systems.)
But I'm not interested in that.
My question particularly pertains to methods of using C++ in the automation industry with regards to patterns, frameworks, practices, uses, etc.
Think of it like this: with the rise of platforms like the Raspberry Pi, Beaglebone Black, Wandboard, Udoo, Odroid, etc. the use of C++ in industrial hardware and embedded projects is more viable than ever before.
But the use of C++ for such embedded projects will be quite different from a "normal desktop program".
Scott Lurndal
Jan 28, 2015, 12:24:51 PM1/28/15
to
jono...@googlemail.com writes:
>On Wednesday, January 28, 2015 at 4:51:08 AM UTC+1, =D6=F6 Tiib wrote:
>Think of it like this: with the rise of platforms like the Raspberry Pi, Be=
>aglebone Black, Wandboard, Udoo, Odroid, etc. the use of C++ in industrial =
projects, whatever language you use, the constraints are the same.
Typically the constraints include a footprint size that precludes
using much of the standard template library. Often the constraints
also include avoiding C++ exceptions. There may or may not be
run-time facilities to support RTTI or C++ exceptions available
on the platform; there may not even be an operating system.
C++ works just fine given those constraints, assuming one avoids
the bits that aren't supported on the target platform; and the
application can still benefit from the data-hiding and encapsulation
provided by the C++ classes.
>On Wednesday, January 28, 2015 at 4:51:08 AM UTC+1, =D6=F6 Tiib wrote:
>Think of it like this: with the rise of platforms like the Raspberry Pi, Be=
>aglebone Black, Wandboard, Udoo, Odroid, etc. the use of C++ in industrial =
>hardware and embedded projects is more viable than ever before.
>
>But the use of C++ for such embedded projects will be quite different from =
>
>a "normal desktop program".
C or C++, it doesn't really matter. When programming for embedded
projects, whatever language you use, the constraints are the same.
Typically the constraints include a footprint size that precludes
using much of the standard template library. Often the constraints
also include avoiding C++ exceptions. There may or may not be
run-time facilities to support RTTI or C++ exceptions available
on the platform; there may not even be an operating system.
C++ works just fine given those constraints, assuming one avoids
the bits that aren't supported on the target platform; and the
application can still benefit from the data-hiding and encapsulation
provided by the C++ classes.
Öö Tiib
Jan 28, 2015, 1:54:51 PM1/28/15
to
On Wednesday, 28 January 2015 18:16:07 UTC+2, jono...@googlemail.com wrote:
> On Wednesday, January 28, 2015 at 4:51:08 AM UTC+1, Öö Tiib wrote:
> >
> > There are millions of lines worth of software in a factory.
> > Lot of it is written in C++.
>
> I'm sorry... but your brief reply is incredible on so many levels,
> that I don't know what to say.
>
> A dose of reality might be in order:
> You've probably never heard of PLCs.
There may be only one PLC per production line. PLC is just a cheap
> On Wednesday, January 28, 2015 at 4:51:08 AM UTC+1, Öö Tiib wrote:
> >
> > There are millions of lines worth of software in a factory.
> > Lot of it is written in C++.
>
> I'm sorry... but your brief reply is incredible on so many levels,
> that I don't know what to say.
>
> A dose of reality might be in order:
> You've probably never heard of PLCs.
computer sold expensively. I have seen PLCs with embedded Windows
and Linux. In what language you think software for PLC is written?
> To present an alternative to your statement from above:
> There is a lot of software in a factory.
> Lot of it is written in IEC 61131-3. (Often it is interfaced to Scada Systems.)
assembler to scare idiots. IOW configuration script for small fraction
of software in factory. You can't write anything really active in it.
For example how you write variable frequency drive in IEC 61131-3?
> But I'm not interested in that.
>
> My question particularly pertains to methods of using C++ in the
> automation industry with regards to patterns, frameworks, practices,
> uses, etc.
> Think of it like this: with the rise of platforms like the
> Raspberry Pi, Beaglebone Black, Wandboard, Udoo, Odroid, etc. the
> use of C++ in industrial hardware and embedded projects is more
> viable than ever before.
sector and rarity of good C++ specialists that majority is in C.
However if a device works then there's no need to rewrite it to
other platform or in other language.
> But the use of C++ for such embedded projects will be quite
> different from a "normal desktop program".
Too lot of embedded work, too few specialists.
Wouter van Ooijen
Jan 28, 2015, 2:52:13 PM1/28/15
to
jono...@googlemail.com schreef op 28-Jan-15 om 5:15 PM:
Different in what sense? The platforms you mention are Linux-level
systems, suited to heavy work, but not so much to fast (ms and faster)
real-time work. The methods to program such systems don't differ that
much from desktop systems.
For programming hard resource-constrained systems (small memory, not a
lot of CPU pwoer to spare, hard real-time requiremenst) C++ can (and IMO
should) be used, but in somje aspects not as it is used on a desktop.
For instance:
- no heap (unpredictable timing)
- no exceptions (see http://www.voti.nl/blog/?p=40 for more explanation)
- no RTTI
- (depending on the hardware) no floating point
Most of the standard and third-party C++ libraries don't adhere to these
limitatins, so they are not useable. Unfortunately, this is seldom clear
in advance.
Some C++ features can, when used correctly, be a big asset in such a
resource-constrained situation:
- templates (but note that the wrong use can spell a disaster)
- constexpr
Wouter van Ooijen
systems, suited to heavy work, but not so much to fast (ms and faster)
real-time work. The methods to program such systems don't differ that
much from desktop systems.
For programming hard resource-constrained systems (small memory, not a
lot of CPU pwoer to spare, hard real-time requiremenst) C++ can (and IMO
should) be used, but in somje aspects not as it is used on a desktop.
For instance:
- no heap (unpredictable timing)
- no exceptions (see http://www.voti.nl/blog/?p=40 for more explanation)
- no RTTI
- (depending on the hardware) no floating point
Most of the standard and third-party C++ libraries don't adhere to these
limitatins, so they are not useable. Unfortunately, this is seldom clear
in advance.
Some C++ features can, when used correctly, be a big asset in such a
resource-constrained situation:
- templates (but note that the wrong use can spell a disaster)
- constexpr
Wouter van Ooijen
jono...@googlemail.com
Jan 28, 2015, 3:39:17 PM1/28/15
to
Unfortunately no reply here has hit the nail on the head yet.
Taking about constraints of some embedded systems is all fine, but it's quite shallow when compared to "real" meat-and-bone topics such as the actual design of the system.
How do you use C++ efficiently to do it?
Something that might go in the direction I was asking about, might be:
http://apfw.sourceforge.net/
To quote from the site:
"The development of the framework started when we realized that a lot of embedded software projects start with creating fundamental services such as kernel abstraction, startup handling, simulation of missing (because still under development) hardware, implementation of design pattern and other stuff. All these things were similar in most projects but re-implemented. The problem is that this work doesn't actually add value to the product! The final user has no immediate benefit from a kernel abstraction!"
see also http://apfw.sourceforge.net/tutorials/ApFwCookbook.pdf
Possibly also the Boost Meta State Machine (MSM) or Boost Statechart might be useful in an embedded industrial context...
Taking about constraints of some embedded systems is all fine, but it's quite shallow when compared to "real" meat-and-bone topics such as the actual design of the system.
How do you use C++ efficiently to do it?
Something that might go in the direction I was asking about, might be:
http://apfw.sourceforge.net/
To quote from the site:
"The development of the framework started when we realized that a lot of embedded software projects start with creating fundamental services such as kernel abstraction, startup handling, simulation of missing (because still under development) hardware, implementation of design pattern and other stuff. All these things were similar in most projects but re-implemented. The problem is that this work doesn't actually add value to the product! The final user has no immediate benefit from a kernel abstraction!"
see also http://apfw.sourceforge.net/tutorials/ApFwCookbook.pdf
Possibly also the Boost Meta State Machine (MSM) or Boost Statechart might be useful in an embedded industrial context...
Paavo Helde
Jan 28, 2015, 4:01:45 PM1/28/15
to
jono...@googlemail.com wrote in
news:69e9e11f-811a-426e...@googlegroups.com:
> Unfortunately no reply here has hit the nail on the head yet.
>
> Taking about constraints of some embedded systems is all fine, but
> it's quite shallow when compared to "real" meat-and-bone topics such
> as the actual design of the system. How do you use C++ efficiently to
> do it?
An oblig car analogy :-) How do you use welding to design your car? Well,
you don't. You design your car beforehand, and if your design prescribes
welding, then you use welding for actually making the car.
Same here. The design is based on actual requirements for the system and
can be done on paper or for smaller projects in your head, or in some more
formal system if required. After that C++ or some other language can be
used for implementing the design in software (though in reality there will
likely be more iterations as there is very little chance to get the design
exactly right at the first time).
C++ is very versatile and can be used for implementing different kinds of
designs, but how it is done depends on the design, not the other way
around.
HTH
Paavo
news:69e9e11f-811a-426e...@googlegroups.com:
> Unfortunately no reply here has hit the nail on the head yet.
>
> Taking about constraints of some embedded systems is all fine, but
> it's quite shallow when compared to "real" meat-and-bone topics such
> as the actual design of the system. How do you use C++ efficiently to
> do it?
you don't. You design your car beforehand, and if your design prescribes
welding, then you use welding for actually making the car.
Same here. The design is based on actual requirements for the system and
can be done on paper or for smaller projects in your head, or in some more
formal system if required. After that C++ or some other language can be
used for implementing the design in software (though in reality there will
likely be more iterations as there is very little chance to get the design
exactly right at the first time).
C++ is very versatile and can be used for implementing different kinds of
designs, but how it is done depends on the design, not the other way
around.
HTH
Paavo
Scott Lurndal
Jan 28, 2015, 4:05:56 PM1/28/15
to
This isn't a classroom.
What is your goal for asking these questions?
What is your goal for asking these questions?
jono...@googlemail.com
Jan 28, 2015, 4:14:22 PM1/28/15
to
On Wednesday, January 28, 2015 at 10:01:45 PM UTC+1, Paavo Helde wrote:
> jononanon wrote
Yes true. But realize this also: if you don't know good techniques, you can design as much as you want... it'll just come across as a wish-list of requirements; and nothing will come of it.
On Wednesday, January 28, 2015 at 10:05:56 PM UTC+1, Scott Lurndal wrote:
No, but seriously: I'm simply asking about good techniques. Recommend to me a book, framework, methodology, technique, ...
As far as I can see... everyone seems to be "rolling their own" in the embedded domain. (??)
> jononanon wrote
On Wednesday, January 28, 2015 at 10:05:56 PM UTC+1, Scott Lurndal wrote:
> jononanon writes:
> >Unfortunately no reply here has hit the nail on the head yet.
>
> >Unfortunately no reply here has hit the nail on the head yet.
>
> This isn't a classroom.
>
> What is your goal for asking these questions?
Teasing you.
>
> What is your goal for asking these questions?
No, but seriously: I'm simply asking about good techniques. Recommend to me a book, framework, methodology, technique, ...
As far as I can see... everyone seems to be "rolling their own" in the embedded domain. (??)
Öö Tiib
Jan 28, 2015, 5:39:05 PM1/28/15
to
On Wednesday, 28 January 2015 23:14:22 UTC+2, jono...@googlemail.com wrote:
>
> Yes true. But realize this also: if you don't know good techniques, you
> can design as much as you want... it'll just come across as a wish-list
> of requirements; and nothing will come of it.
Requirements specification is not product of design. Do you want to learn
>
> Yes true. But realize this also: if you don't know good techniques, you
> can design as much as you want... it'll just come across as a wish-list
> of requirements; and nothing will come of it.
basics of software development process using industrial automation as
example?
Jorgen Grahn
Jan 29, 2015, 4:57:47 PM1/29/15
to
On Wed, 2015-01-28, jono...@googlemail.com wrote:
interesting perhaps, but credible rather than incredible.
...
There seems to be two groups of people who think about "embedded"
in one of two ways:
A. Mostly tiny, very limited systems, and often hard real-time
requirements. (A few systems are big and general.)
B. Mostly as big and as full-featured as servers. Mostly run Linux.
(A few systems are tiny and specialized.)
I'm in group B, and you seem to be in group A. I have no idea which
group is "right", but I know hundreds of people who work in (B) and
one or two who work in (A).
But the Raspberry Pi, Beaglebone and so on that you mention -- those
are really on the "big and general-purpose" end of the scale. The
smartest way to use them IMO is to write Linux drivers for your
peripherals, and then do the application logic as normal Unix
programming. Then plain, standard C++ is a good candidate language,
and there won't be a lot that's "embedded-specific" about the code you
write.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
> On Wednesday, January 28, 2015 at 4:51:08 AM UTC+1, 嘱 Tiib wrote:
>>
>> There are millions of lines worth of software in a factory.
>> Lot of it is written in C++.
>
> I'm sorry... but your brief reply is incredible on so many levels,
> that I don't know what to say.
To me it just seems like an obviously true statement. Not very
>>
>> There are millions of lines worth of software in a factory.
>> Lot of it is written in C++.
>
> I'm sorry... but your brief reply is incredible on so many levels,
> that I don't know what to say.
interesting perhaps, but credible rather than incredible.
...
> My question particularly pertains to methods of using C++ in the
> automation industry with regards to patterns, frameworks, practices,
> uses, etc.
>
> Think of it like this: with the rise of platforms like the Raspberry
> Pi, Beaglebone Black, Wandboard, Udoo, Odroid, etc. the use of C++ in
> industrial hardware and embedded projects is more viable than ever
> before.
>
> But the use of C++ for such embedded projects will be quite
> different from a "normal desktop program".
I think it's the same old problem we run into over and over again.
> automation industry with regards to patterns, frameworks, practices,
> uses, etc.
>
> Think of it like this: with the rise of platforms like the Raspberry
> Pi, Beaglebone Black, Wandboard, Udoo, Odroid, etc. the use of C++ in
> industrial hardware and embedded projects is more viable than ever
> before.
>
> But the use of C++ for such embedded projects will be quite
> different from a "normal desktop program".
There seems to be two groups of people who think about "embedded"
in one of two ways:
A. Mostly tiny, very limited systems, and often hard real-time
requirements. (A few systems are big and general.)
B. Mostly as big and as full-featured as servers. Mostly run Linux.
(A few systems are tiny and specialized.)
I'm in group B, and you seem to be in group A. I have no idea which
group is "right", but I know hundreds of people who work in (B) and
one or two who work in (A).
But the Raspberry Pi, Beaglebone and so on that you mention -- those
are really on the "big and general-purpose" end of the scale. The
smartest way to use them IMO is to write Linux drivers for your
peripherals, and then do the application logic as normal Unix
programming. Then plain, standard C++ is a good candidate language,
and there won't be a lot that's "embedded-specific" about the code you
write.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Pavel
Jan 29, 2015, 10:59:52 PM1/29/15
to
platform and what it provides in terms of OS, programming interfaces,
C++ implementations, hardware capabilities, drivers for the devices of
your interest and the of industrial automation app you are trying to create.
jono...@googlemail.com
Jan 30, 2015, 2:52:05 AM1/30/15
to
On Friday, January 30, 2015 at 4:59:52 AM UTC+1, Pavel wrote:
> you might get more useful answers if you describe your particular target
> platform and what it provides in terms of OS, programming interfaces,
> C++ implementations, hardware capabilities, drivers for the devices of
> your interest and the of industrial automation app you are trying to create.
Basically I'm thinking of applications that can leverage a lot of C++'s powers.
> you might get more useful answers if you describe your particular target
> platform and what it provides in terms of OS, programming interfaces,
> C++ implementations, hardware capabilities, drivers for the devices of
> your interest and the of industrial automation app you are trying to create.
Things like a generic framework, for controlling automatic vacuum cleaners and similar robots. But it should be so well-designed generic that I can easily transfer it to a small off-road vehicle.
Or (probably simpler) a cocktail machine, where I can design input-recipes in a text-based from; and load them via the webserver-interface.
Or a framework for automatic modern washing machines. It should work with different hardware-types, have a nice user interface, allow the loading of washing-steps in a text-based form (that you load over the machine's webserver).
Or a Drone project.
Or a Mars Rover. (except that I do NOT have the requirement that it must work on Mars!). Yes I think that's a good example.
A generic Rover framework. One that is good enough that I can adapt it to become e.g. an automatic lawn-mower.
Stuff like that...
Basically I'm looking for the C++ book, that you'd recommend the junior C++ team-members of a Mars-Rover team should read...
... with the aim of doing really great software-architecture work and creating a superb and easily-maintainable system.
Basically the book that a world-class C++ programmer might write, after dedicatedly playing with a Beaglebone Black for a year, and focusing strongly on hardware-related themes such as timers, concurrency, states, safety-concept, maintainability, hardware-extensibility, ... and also including ways of tackling low-level requirements such as : recurring tasks, messaging, and message-passing, signals, callbacks,
and handling it with nice patterns.
I've just realized... such a book does not exist yet.
I guess I'm finished and will just wait and see what happens in the future...
I'd love to see a C++ group playing with Beaglebone Blacks, doing blog-posts on these things... and a vibrant community...
Because: just being able to get a light to blink with some C-code is far away from organizing an industrial or embedded project. I'm sure that leveraging C++, one can really do some great things in this area.
PS: the whole internet-of-things theme is also interesting in this respect. I want to run C++ code in gadgets and not use crazy stuff like javascript (https://tessel.io/).
David Brown
Jan 30, 2015, 3:06:59 AM1/30/15
to
too great. I have worked on embedded systems with 2 GB ram running
Linux - and systems with 32 bytes of ram (yes, /bytes/ - not KB, MB, or
GB). In a fancy washing machine you will have a powerful board
controlling a touch screen - but you will also have tiny processors
controlling pumps and motors.
What you want is like asking for a container that is suitable for the
pencils on your desk, but should be easily adaptable to shipping cars
across the pacific and collecting moon rocks.
Wouter van Ooijen
Jan 30, 2015, 4:53:13 AM1/30/15
to
jono...@googlemail.com schreef op 30-Jan-15 om 8:51 AM:
> ... with the aim of doing really great software-architecture work and creating a superb and easily-maintainable system.
Sorry, there is no silver bullet, and likewise there is no one book that
will teach you how to do a such a very difficult thing the right way.
There are lots of books, talks on youtube, blogs, articles, etc. on this
topic. Read and apply as much as you can, and learn from it. In the long
run your exeperience might help the industry a little step further.
> Basically the book that a world-class C++ programmer might write, after dedicatedly playing with a Beaglebone Black for a year, and focusing strongly on hardware-related themes such as timers, concurrency, states, safety-concept, maintainability, hardware-extensibility, ... and also including ways of tackling low-level requirements such as : recurring tasks, messaging, and message-passing, signals, callbacks,
> and handling it with nice patterns.
World-class C++ programmers tend to know their limitations and focus on
more limited fields. Start by listening to every youtube talk by
Stroustrup, then broaden you reach by listening to the talks of guys
that appear at the same conferences. (Scott Meyers, Herb Sutter, ...)
Wouter van Ooijen
> On Friday, January 30, 2015 at 4:59:52 AM UTC+1, Pavel wrote:
>> you might get more useful answers if you describe your particular target
>> platform and what it provides in terms of OS, programming interfaces,
>> C++ implementations, hardware capabilities, drivers for the devices of
>> your interest and the of industrial automation app you are trying to create.
>
> Basically I'm thinking of applications that can leverage a lot of C++'s powers.
>
> Things like a generic framework, for controlling automatic vacuum cleaners and similar robots. But it should be so well-designed generic that I can easily transfer it to a small off-road vehicle.
>
> Or (probably simpler) a cocktail machine, where I can design input-recipes in a text-based from; and load them via the webserver-interface.
>
> Or a framework for automatic modern washing machines. It should work with different hardware-types, have a nice user interface, allow the loading of washing-steps in a text-based form (that you load over the machine's webserver).
>
> Or a Drone project.
>
> Or a Mars Rover. (except that I do NOT have the requirement that it must work on Mars!). Yes I think that's a good example.
> A generic Rover framework. One that is good enough that I can adapt it to become e.g. an automatic lawn-mower.
>
> Stuff like that...
>
> Basically I'm looking for the C++ book, that you'd recommend the junior C++ team-members of a Mars-Rover team should read...
There should be no junior on such a team.
>> you might get more useful answers if you describe your particular target
>> platform and what it provides in terms of OS, programming interfaces,
>> C++ implementations, hardware capabilities, drivers for the devices of
>> your interest and the of industrial automation app you are trying to create.
>
> Basically I'm thinking of applications that can leverage a lot of C++'s powers.
>
> Things like a generic framework, for controlling automatic vacuum cleaners and similar robots. But it should be so well-designed generic that I can easily transfer it to a small off-road vehicle.
>
> Or (probably simpler) a cocktail machine, where I can design input-recipes in a text-based from; and load them via the webserver-interface.
>
> Or a framework for automatic modern washing machines. It should work with different hardware-types, have a nice user interface, allow the loading of washing-steps in a text-based form (that you load over the machine's webserver).
>
> Or a Drone project.
>
> Or a Mars Rover. (except that I do NOT have the requirement that it must work on Mars!). Yes I think that's a good example.
> A generic Rover framework. One that is good enough that I can adapt it to become e.g. an automatic lawn-mower.
>
> Stuff like that...
>
> Basically I'm looking for the C++ book, that you'd recommend the junior C++ team-members of a Mars-Rover team should read...
> ... with the aim of doing really great software-architecture work and creating a superb and easily-maintainable system.
will teach you how to do a such a very difficult thing the right way.
There are lots of books, talks on youtube, blogs, articles, etc. on this
topic. Read and apply as much as you can, and learn from it. In the long
run your exeperience might help the industry a little step further.
> Basically the book that a world-class C++ programmer might write, after dedicatedly playing with a Beaglebone Black for a year, and focusing strongly on hardware-related themes such as timers, concurrency, states, safety-concept, maintainability, hardware-extensibility, ... and also including ways of tackling low-level requirements such as : recurring tasks, messaging, and message-passing, signals, callbacks,
> and handling it with nice patterns.
more limited fields. Start by listening to every youtube talk by
Stroustrup, then broaden you reach by listening to the talks of guys
that appear at the same conferences. (Scott Meyers, Herb Sutter, ...)
Wouter van Ooijen
Scott Lurndal
Jan 30, 2015, 11:24:03 AM1/30/15
to
Wouter van Ooijen <wou...@voti.nl> writes:
>World-class C++ programmers tend to know their limitations and focus on
>more limited fields. Start by listening to every youtube talk by
>Stroustrup, then broaden you reach by listening to the talks of guys
>that appear at the same conferences. (Scott Meyers, Herb Sutter, ...)
I wonder if these guys, who write about C++, have actually written
>World-class C++ programmers tend to know their limitations and focus on
>more limited fields. Start by listening to every youtube talk by
>Stroustrup, then broaden you reach by listening to the talks of guys
>that appear at the same conferences. (Scott Meyers, Herb Sutter, ...)
real-world production applications in C++?
The old (and insulting) expression "Those do can, do, those who can't, teach"
comes to mind :-).
jono...@googlemail.com
Jan 30, 2015, 11:55:41 AM1/30/15
to
Just found this:
http://accu.org/index.php/conferences/accu_conference_2008/accu2008_sessions#C++%20for%20Embedded%20Systems
Slides:
http://accu.org/content/conf2008/Vollmann-embcpp08.pdf
(http://www.vollmann.ch/de/presentations/index.html)
Also:
http://www.artima.com/shop/effective_cpp_in_an_embedded_environment
http://accu.org/index.php/conferences/accu_conference_2008/accu2008_sessions#C++%20for%20Embedded%20Systems
Slides:
http://accu.org/content/conf2008/Vollmann-embcpp08.pdf
(http://www.vollmann.ch/de/presentations/index.html)
Also:
http://www.artima.com/shop/effective_cpp_in_an_embedded_environment
Wouter van Ooijen
Jan 30, 2015, 12:02:41 PM1/30/15
to
Scott Lurndal schreef op 30-Jan-15 om 5:23 PM:
That obviously bait, but there is a lot of (unavoidable) truth in it:
those who are full-time coders don't have time to spare to be good
speakers or authors, and vice versa.
But Strustroup and Meyers are good communicators, and they listen very
carefully to what the full-time coders ask, so they are worth reading
and listening to.
And me? I am a teacher...
Wouter
those who are full-time coders don't have time to spare to be good
speakers or authors, and vice versa.
But Strustroup and Meyers are good communicators, and they listen very
carefully to what the full-time coders ask, so they are worth reading
and listening to.
And me? I am a teacher...
Wouter
woodb...@gmail.com
Jan 30, 2015, 2:50:12 PM1/30/15
to
out of him and Scott Meyers. Chandler Carruth is
knowledgeable and funny also.
>
> And me? I am a teacher...
my teachers.
Brian
Ebenezer Enterprises
http://webEbenezer.net
Öö Tiib
Jan 30, 2015, 3:52:05 PM1/30/15
to
to help others to gain skills to learn and to think ... or to apply that
knowledge and skills in practice. We engineers should cooperate with
teachers more tightly perhaps ... instead of joking.
Pavel
Jan 31, 2015, 1:19:56 AM1/31/15
to
at https://www.youtube.com/watch?v=fj_d9NUiL-o and http://arduino.cc, in
particular http://arduino.cc/en/Reference/Libraries for the C++ libraries they
provide. This might get you in contact with the people who also thinks C++ might
be useful at machine control/industrial automation/robotics.
Two words of caution though:
1. It is not accidental that the most of machine control applications are
written in languages you call "crazy" (you mentioned JavaScript but there are
lots of others, in particular at some point in the past Forth was very popular,
LISP was used a lot, too. IMHO the common feature of these languages is the
virtual machine capable of compiling and executing code in target environment.
The ability to create such an environment cheaply (a typical full-fledged Forth
target-side environment was well under 10KB of code and LISP environments were
not much fatter) was apparently a critical requirement. Obviously nowadays more
more computational resources are available on the embedded side but functionally
this requirement is still there. Especially robotics and AI applications can win
tremendously from the code's being generated or sent to the environment, and
then being compiled and optimized "on the fly". Unfortunately, C++ might be the
least suitable language for even simply dynamic loading of compiled code to the
working application, let alone on-target compilation.
2. From my experience, early introduction of framework is a very common design
mistake. A good framework can IMHO only be developed by summarizing real
experience from multiple applications. Essentially, only after writing many
"essentially same" pieces of code *and putting them to production, after all
fixes that often change lots of models* you will find reasonable abstractions to
reuse. Still any new occasion might require lots of re-doing (in the
abstractions). An attempt to use a freshly-baked framework for a seemingly
pliant task is often a waste. Useful abstractions get crystallized gradually. In
some way a framework can be naturally seen as a set of constraints and rules and
hopefully we can agree that it is harmful to start constraining designs early
before building enough use cases (in our case, applications) that prove that the
rules/constraints would be indeed reasonable. It is like coming to a foreign
country and starting writing laws for its inhabitants without living among them
for a long time.
Long story short, my advice would be to develop your 1st, 2nd and maybe 3rd
*non-trivial* (this is important) application right on top of the API provided
by your platform of choice, then study the resulting code for similarities. If
the results are not crying for the framework, postpone the framework and get
back to it after developing / studying few more non-trivial applications.
-Pavel
Jorgen Grahn
Jan 31, 2015, 3:22:27 AM1/31/15
to
On Fri, 2015-01-30, Scott Lurndal wrote:
> Wouter van Ooijen <wou...@voti.nl> writes:
>>World-class C++ programmers tend to know their limitations and focus on
>>more limited fields. Start by listening to every youtube talk by
>>Stroustrup, then broaden you reach by listening to the talks of guys
>>that appear at the same conferences. (Scott Meyers, Herb Sutter, ...)
>
> I wonder if these guys, who write about C++, have actually written
> real-world production applications in C++?
Don't know about the others, but Stroustrup shows clear signs of
> Wouter van Ooijen <wou...@voti.nl> writes:
>>World-class C++ programmers tend to know their limitations and focus on
>>more limited fields. Start by listening to every youtube talk by
>>Stroustrup, then broaden you reach by listening to the talks of guys
>>that appear at the same conferences. (Scott Meyers, Herb Sutter, ...)
>
> I wonder if these guys, who write about C++, have actually written
> real-world production applications in C++?
having been in the trenches (see e.g. the last few chapters in
TC++PL 3rd ed). When he had time for that, I don't know.
Jorgen Grahn
Jan 31, 2015, 3:40:05 AM1/31/15
to
On Sat, 2015-01-31, Pavel wrote:
...
> From my experience, early introduction of framework is a very common
> design mistake. A good framework can IMHO only be developed by
> summarizing real experience from multiple applications. Essentially,
> only after writing many "essentially same" pieces of code *and putting
> them to production, after all fixes that often change lots of models*
> you will find reasonable abstractions to reuse. Still any new occasion
> might require lots of re-doing (in the abstractions). An attempt to
> use a freshly-baked framework for a seemingly pliant task is often a
> waste. Useful abstractions get crystallized gradually.
>
> In some way a framework can be naturally seen as a set of constraints
> and rules and hopefully we can agree that it is harmful to start
> constraining designs early before building enough use cases (in our
> case, applications) that prove that the rules/constraints would be
> indeed reasonable. It is like coming to a foreign country and starting
> writing laws for its inhabitants without living among them for a long
> time.
>
> Long story short, my advice would be to develop your 1st, 2nd and
> maybe 3rd *non-trivial* (this is important) application right on top
> of the API provided by your platform of choice, then study the
> resulting code for similarities. If the results are not crying for the
> framework, postpone the framework and get back to it after developing
> / studying few more non-trivial applications.
Quoting it to fix the formatting. I agree wholeheartedly, and you
formulate it well.
It took me a decade of programming to see it that way. Sadly, too
many never learn, and start any major project by writing a framework
or abstraction layers which then turn out to be a bad fit for whatever
the application needs to do :-/
...
> Two words of caution though:
[...]
> From my experience, early introduction of framework is a very common
> design mistake. A good framework can IMHO only be developed by
> summarizing real experience from multiple applications. Essentially,
> only after writing many "essentially same" pieces of code *and putting
> them to production, after all fixes that often change lots of models*
> you will find reasonable abstractions to reuse. Still any new occasion
> might require lots of re-doing (in the abstractions). An attempt to
> use a freshly-baked framework for a seemingly pliant task is often a
> waste. Useful abstractions get crystallized gradually.
>
> In some way a framework can be naturally seen as a set of constraints
> and rules and hopefully we can agree that it is harmful to start
> constraining designs early before building enough use cases (in our
> case, applications) that prove that the rules/constraints would be
> indeed reasonable. It is like coming to a foreign country and starting
> writing laws for its inhabitants without living among them for a long
> time.
>
> Long story short, my advice would be to develop your 1st, 2nd and
> maybe 3rd *non-trivial* (this is important) application right on top
> of the API provided by your platform of choice, then study the
> resulting code for similarities. If the results are not crying for the
> framework, postpone the framework and get back to it after developing
> / studying few more non-trivial applications.
formulate it well.
It took me a decade of programming to see it that way. Sadly, too
many never learn, and start any major project by writing a framework
or abstraction layers which then turn out to be a bad fit for whatever
the application needs to do :-/
jono...@googlemail.com
Jan 31, 2015, 4:15:29 AM1/31/15
to
http://arobenko.gitbooks.io/bare_metal_cpp/
Real-Time C++ (by Christopher Kormanyos)
http://www.springer.com/computer/communication+networks/book/978-3-642-34687-3
This last book seems very interesting. It uses C++11 and the author, Kormanyos, has also contributed to Boost.
Öö Tiib
Jan 31, 2015, 12:08:30 PM1/31/15
to
incompetent ears (and usually we sell to incompetent ears). It sounds
easy to extend and to reuse and so it sounds like good investment.
Therefore we should always mention making or extending frameworks in
visionary discussions. However in real work we should ignore it, if
later asked for then we can extract some "framework" out from existing
product.
Martijn Lievaart
Feb 8, 2015, 3:16:02 PM2/8/15
to
On Thu, 29 Jan 2015 21:57:34 +0000, Jorgen Grahn wrote:
> But the Raspberry Pi, Beaglebone and so on that you mention -- those are
> really on the "big and general-purpose" end of the scale.
<plug> and the Arietta G25, it's awesome! </plug>
> But the Raspberry Pi, Beaglebone and so on that you mention -- those are
> really on the "big and general-purpose" end of the scale.
M4
izmirli
Feb 14, 2015, 4:03:29 AM2/14/15
to
look at the books ;
Real-Time_C_Efficient_Object Oriented_and_Template_Microcontroller_Programming.Chris Kormanyos
Interfacing with C++ Jayantha Katupitiya Kim Bentley.
Real-Time_C_Efficient_Object Oriented_and_Template_Microcontroller_Programming.Chris Kormanyos
Interfacing with C++ Jayantha Katupitiya Kim Bentley.
Haddock
Feb 15, 2015, 8:55:50 AM2/15/15
to
We were using the Sematech CIM Framework back then. It defines static class relationships for a shop floor control system where the material is transferred in carriers from machine to machine. It was quite useful although the real hard park is in the dynamic interactions where this framework from Sematech says nothing about.
Couldn't find much about it anymore, though. I only found this:
http://dl.acm.org/citation.cfm?id=262809&dl=ACM&coll=DL&CFID=626945930&CFTOKEN=18855310
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1561475&url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F3468%2F33148%2F01561475.pdf%3Farnumber%3D1561475
Maybe you can find it on their homepage: http://public.sematech.org
-- Haddock
Couldn't find much about it anymore, though. I only found this:
http://dl.acm.org/citation.cfm?id=262809&dl=ACM&coll=DL&CFID=626945930&CFTOKEN=18855310
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1561475&url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F3468%2F33148%2F01561475.pdf%3Farnumber%3D1561475
Maybe you can find it on their homepage: http://public.sematech.org
-- Haddock
Dan George
Feb 23, 2015, 10:24:04 PM2/23/15
to
Quintus Francis Cerimon Fitzwalter
Aug 11, 2022, 12:04:23 PM8/11/22
to
I think that this programming language is very useful and many things are written in C++ not. For example I want to build my own ecommerce website and it will be in C++ for sure.
Sabina Babington
Aug 11, 2022, 1:19:43 PM8/11/22
to
C++ for online store? I think it was good in the past, maybe, but in 2022 most of the successful ecommerce projects work on Python. Anyway, you can double check with https://intexsoft.com/ as they are the leading agency in web development for enterprises and both small and big businesses. I feel even curious what they will recommend in the end of the day.
0 new messages