No exceptions, no STL

[Melzzzzz]

Rant: my new job at embedded programming ;)
So I am now C/C++ programmer...

--
press any key to continue or any other to quit...

[woodb...@gmail.com]

On Monday, June 11, 2018 at 3:20:45 PM UTC-5, Melzzzzz wrote:
> Rant: my new job at embedded programming ;)
> So I am now C/C++ programmer...
>

Probably if we had static exceptions:
https://www.reddit.com/r/cpp/comments/8iw72i/p0709_r0_zerooverhead_deterministic_exceptions/

you could use both exceptions and STL. My hope is
that these will be available before the committee
formally adopts them.


Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net

[Ian Collins]

On 12/06/18 09:40, woodb...@gmail.com wrote:
> On Monday, June 11, 2018 at 3:20:45 PM UTC-5, Melzzzzz wrote:
>> Rant: my new job at embedded programming ;)
>> So I am now C/C++ programmer...
>>
>
> Probably if we had static exceptions:
> https://www.reddit.com/r/cpp/comments/8iw72i/p0709_r0_zerooverhead_deterministic_exceptions/
>
> you could use both exceptions and STL. My hope is
> that these will be available before the committee
> formally adopts them.

For once I agree with you :)

--
Ian.

[Jorgen Grahn]

On Mon, 2018-06-11, Melzzzzz wrote:
> Rant: my new job at embedded programming ;)

Because of policy decisions, or technical limitations?

I can imagine avoiding dynamic allocation, so e.g. malloc(),
plain operator new, std::vector would be unusable ... but
std::array would still be ok and useful.

Then there was the infamous Embedded C++ standard, which
disallowed things like namespaces ...

> So I am now C/C++ programmer...

Well, there are worse fates.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[David Brown]

On 12/06/18 12:13, Jorgen Grahn wrote:
> On Mon, 2018-06-11, Melzzzzz wrote:
>> Rant: my new job at embedded programming ;)
>
> Because of policy decisions, or technical limitations?
>
> I can imagine avoiding dynamic allocation, so e.g. malloc(),
> plain operator new, std::vector would be unusable ... but
> std::array would still be ok and useful.

Even seemingly innocent classes like std::array can pull in a range of
extra code. It is not easy to use bits of the STL without getting a
whole pile of extras - including malloc, exception handling, printf
functionality, etc. There are other libraries available that can be a
better choice for more resource-constrained systems.

Of course, it all depends on what sort of embedded programming it is -
it could be anything from a small 8-bit microcontroller with 16K flash
to a massive multi-core system that is embedded in a box.

>
> Then there was the infamous Embedded C++ standard, which
> disallowed things like namespaces ...
>

The "Embedded C++" standard was an abject failure. The theory was that
it should support all features of C++ that did not lead to extra code
space or run time. This is, of course, a pointless idea - C++ already
has the goal of zero overhead for features that you don't use. If you
want to avoid the overhead of multiple inheritance, don't use it. The
only parts of C++ that can lead to extra code (mostly as static tables)
even when you don't use them are exceptions and RTTI - and compilers
generally let you disable these.

Lack of namespaces was just the most famous example of how thoughtless
EC++ was.

>> So I am now C/C++ programmer...
>
> Well, there are worse fates.
>

Indeed - you could be a Windows programmer :-(

[James Kuyper]

On 06/12/2018 08:05 AM, David Brown wrote:
> On 12/06/18 12:13, Jorgen Grahn wrote:
>> On Mon, 2018-06-11, Melzzzzz wrote:

...

>>> So I am now C/C++ programmer...
>>
>> Well, there are worse fates.
>>
>
> Indeed - you could be a Windows programmer :-(

Speaking of which - I've taken on a new project. The position
description said:

Requirements:
• C++ software programming experience
• Windows and Visual Studios 2015 working knowledge.
• Bachelor’s in Computer Science, Software Development, Computer
Engineering or Software Related Field of Study
• Minimum of two years’ experience as a C++ coder

Desired:
• Prior experience with M&S software coding.
• Prior experience with building M&S environment/terrain generators.
• Qt Graphical User Interface (GUI) Software experience.
• Five years of relevant experience desired.

Apparently not all of the "requirements" were actually required - six
years of C++ experience is the only thing I have which matches anything
on either of those two lists. I only wrote code for Windows for less
than a year, in 1995, and that wasn't my main task at the time. I had
some experience on DOS systems before that, but most of my career has
involved Unix-like systems. My BS was in Physics. I've written only a
couple of small GUI programs, one in VMS Fortran, and another in IDL -
I've never used Qt.

Would anyone care to recommend some texts I should study to cover the
other items on those lists?

[Melzzzzz]

On 2018-06-12, Jorgen Grahn <grahn...@snipabacken.se> wrote:
> On Mon, 2018-06-11, Melzzzzz wrote:
>> Rant: my new job at embedded programming ;)
>
> Because of policy decisions, or technical limitations?

Don't know yet. Will see, if I can do anything about it ;)

[Melzzzzz]

Heh, I looked this job because of Linux+C++ ;)

[woodb...@gmail.com]

On Tuesday, June 12, 2018 at 7:05:39 AM UTC-5, David Brown wrote:
> On 12/06/18 12:13, Jorgen Grahn wrote:
> > On Mon, 2018-06-11, Melzzzzz wrote:
> >> Rant: my new job at embedded programming ;)
> >
> > Because of policy decisions, or technical limitations?
> >
> > I can imagine avoiding dynamic allocation, so e.g. malloc(),
> > plain operator new, std::vector would be unusable ... but
> > std::array would still be ok and useful.
>
> Even seemingly innocent classes like std::array can pull in a range of
> extra code. It is not easy to use bits of the STL without getting a
> whole pile of extras - including malloc, exception handling, printf
> functionality, etc. There are other libraries available that can be a
> better choice for more resource-constrained systems.

I don't think you get malloc or printf if you use std::array.
But in general, can't argue with that.

>
> Of course, it all depends on what sort of embedded programming it is -
> it could be anything from a small 8-bit microcontroller with 16K flash
> to a massive multi-core system that is embedded in a box.
>
> >
> > Then there was the infamous Embedded C++ standard, which
> > disallowed things like namespaces ...
> >
>
> The "Embedded C++" standard was an abject failure. The theory was that
> it should support all features of C++ that did not lead to extra code
> space or run time. This is, of course, a pointless idea - C++ already
> has the goal of zero overhead for features that you don't use. If you
> want to avoid the overhead of multiple inheritance, don't use it. The
> only parts of C++ that can lead to extra code (mostly as static tables)
> even when you don't use them are exceptions and RTTI - and compilers
> generally let you disable these.
>
> Lack of namespaces was just the most famous example of how thoughtless
> EC++ was.
>
> >> So I am now C/C++ programmer...
> >
> > Well, there are worse fates.
> >
>
> Indeed - you could be a Windows programmer :-(

Hmm. I'm a Windows programmer to some extent. It's
not the end of the world, but I'm glad to be able to
work primarily on other platforms.


Brian
Ebenezer Enterprises - Was Eisenhower the last decent President?
http://webEbenezer.net

[Jorgen Grahn]

On Tue, 2018-06-12, Melzzzzz wrote:
> On 2018-06-12, Jorgen Grahn <grahn...@snipabacken.se> wrote:
>> On Mon, 2018-06-11, Melzzzzz wrote:
>>> Rant: my new job at embedded programming ;)
>>
>> Because of policy decisions, or technical limitations?
>
> Don't know yet. Will see, if I can do anything about it ;)

If it was me, I'd hope it's the latter. Very limited systems have
their charms. (And on the other hand, people tend to dislike when
you try to change their stupid decisions.)

[Richard]

[Please do not mail me a copy of your followup]

James Kuyper <james...@alumni.caltech.edu> spake the secret code
<pfonmu$bp3$1...@dont-email.me> thusly:

>Would anyone care to recommend some texts I should study to cover the
>other items on those lists?

I'll give it a shot.

>Requirements:
>* Windows and Visual Studios 2015 working knowledge.

There used to be books on VS, before the web was used to look things
up, but generally your best bet now is to rely on the MSDN documentation
in order to get the details. Use a tailored google search to avoid
stuff from the "Microsoft Community" sites. IMO, those community
"answers" are worthless for developers. Stick to the MSDN
documentation or even use the built-in help links (which just invoke
the web browser to a URL now anyway).

Aside from familiarizing yourself with keyboard shortcuts and menus,
etc., the big difference here is going to be the build sytem. If
you're using CMake, then you won't care about how VS organizes stuff
because you'll be generating project/solution files from CMake.

Otherwise, the basics are:
- A solution file (*.sln) is a bag of projects. Commit this file.
- A solution options file (*.suo) is custom options you have set for
your solution, like which project should be started when you launch
the debugger. Do not commit this file. Later editions of VS put
stuff in a .vs folder. Similarly, do not commit this folder.
- A project file (*.vcxproj) is a bag of source files along with
commands for how to build them into a target: library (static or
dynamic) or executable (console of Windows subsystem).
- In C++ projects, the view of files in the Solution Explorer is not
necessarily 1-to-1 with the organization of files on disk. While
this is typical, it is not required. The *.vxproj.filters files
hold the mapping from files on disk to files in the Solution
Explorer. Commit these files.
- Per-project user settings are stored in *.vcxproj.user files; don't
commit these files.
- All compile flags and options for a target and the corresponding
source files are found through the Properties item on the context
menu for the item (project or file) in the Solution Explorer pane.
- VS defines a bunch of variables for a solution and a project that
allow you to parameterize the compiler options. You will see these
in the settings as $(SolutionDir).
- VS organizes the build into different settings for every combination
of "Platform" (e.g. Win32 and x64) and "Configuration" (e.g. Debug,
Release). When changing settings through the Properties dialog,
make sure you have the correct setting for Platform and
Configuration from the drop-down menu or you will be confused why
your changes aren't taking effect. The most common use case is to
select "All Configurations" and "All Platforms" so that the settings
are applied uniformly.
- While the Properties dialog box is open, you can click on items in
the Solution Explorer pane to switch the settings shown to you in the
Properties box. This is a little unexpected because the Properties
dialog box is modal.
- Bags of common compiler settings can be parameterized into "Property
Sheet Pages". This is more of an advanced thing, but helps you keep
funky settings consistent between files and projects.
- Dependencies between targets are manipulated through the
"References" folder in Solution Explorer. Use "Add Reference..."
from the context menu on the References folder to setup
dependencies between targets.
- If your Solution has lots of targets, it can be useful to group them
into "Solution Folders" just for organizing purposes. It is
cosmetic only and has no bearing on how/when projects are built.
Solution Folders are recorded in the .sln file, so they persist in
source control.

>Desired:
>* Prior experience with M&S software coding.
>* Prior experience with building M&S environment/terrain generators.

This sounds really market specific -- "modeling and simulation
environment/terrain generators"? Any chance your new position is with
Rockwell Collins? :-) I don't have specific advice here.

>* Qt Graphical User Interface (GUI) Software experience.

In my experience, once you learn one GUI toolkit, they are all the
same more or less. Qt has some things that make it a little funky
like the moc processor that generates signal/slot boiler plate code
for wiring up the events (signals) emitted by UI elements with the
handlers (slots) that process the events. Unless you want to be
disgusted, don't dig into the Qt implementation too deeply :-).
However, unlike VS there are good books out there for Qt. Ones I have
read and would recommend are:

"C++ GUI Programming with Qt 4" by Jasmin Blanchette, Mark Summerfield
<https://amzn.to/2JBCCV8>

"Advanced Qt Programming: Creating Great Software with C++ and Qt 4"
by Mark Summerfield
<https://amzn.to/2t3TkFB>

The titles are self-explanatory. Both have Amazon "Look Inside"
previews. You probably won't need the advanced book unless you need
to really dig into the model/view framework used in Qt.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Öö Tiib]

Note that the exception propagation scheme like described in that
document was how these were usually implemented in nineties.
Most of the FUD and nausea about how inefficient those are have
its roots in that time.

[woodb...@gmail.com]

On Tuesday, June 12, 2018 at 5:31:59 PM UTC-5, Öö Tiib wrote:
> On Tuesday, 12 June 2018 00:46:29 UTC+3, Ian Collins wrote:
> > On 12/06/18 09:40, woodb...@gmail.com wrote:
> > > On Monday, June 11, 2018 at 3:20:45 PM UTC-5, Melzzzzz wrote:
> > >> Rant: my new job at embedded programming ;)
> > >> So I am now C/C++ programmer...
> > >>
> > >
> > > Probably if we had static exceptions:
> > > https://www.reddit.com/r/cpp/comments/8iw72i/p0709_r0_zerooverhead_deterministic_exceptions/
> > >
> > > you could use both exceptions and STL. My hope is
> > > that these will be available before the committee
> > > formally adopts them.
> >
> > For once I agree with you :)
>
> Note that the exception propagation scheme like described in that
> document was how these were usually implemented in nineties.

Was that in ++C implementations? Was it 1998 ++C standard
that required dynamic exceptions? I guess we will be going
back to the future.
.

[Melzzzzz]

On 2018-06-12, Richard <legaliz...@mail.xmission.com> wrote:
> [Please do not mail me a copy of your followup]
>
> James Kuyper <james...@alumni.caltech.edu> spake the secret code
><pfonmu$bp3$1...@dont-email.me> thusly:
>

>>* Qt Graphical User Interface (GUI) Software experience.
>
> In my experience, once you learn one GUI toolkit, they are all the
> same more or less. Qt has some things that make it a little funky
> like the moc processor that generates signal/slot boiler plate code
> for wiring up the events (signals) emitted by UI elements with the
> handlers (slots) that process the events. Unless you want to be
> disgusted, don't dig into the Qt implementation too deeply :-).

Well, you don't have to use moc and qt's signal/slot
, you can override application event function and take over ;)
I did that back in 2000 with one project.

[Ian Collins]

I've never seen a ++C implementation...

--
Ian.

[guinne...@gmail.com]

On Tuesday, 12 June 2018 16:09:35 UTC+1, James Kuyper wrote:
> On 06/12/2018 08:05 AM, David Brown wrote:
> > On 12/06/18 12:13, Jorgen Grahn wrote:
> >> On Mon, 2018-06-11, Melzzzzz wrote:
> ...
> >>> So I am now C/C++ programmer...
> >>
> >> Well, there are worse fates.
> >>
> >
> > Indeed - you could be a Windows programmer :-(
>
> Speaking of which - I've taken on a new project. The position
> description said:
>
> Requirements:
> • C++ software programming experience
> • Windows and Visual Studios 2015 working knowledge.
> • Bachelor’s in Computer Science, Software Development, Computer
> Engineering or Software Related Field of Study
> • Minimum of two years’ experience as a C++ coder
>
> Desired:
> • Prior experience with M&S software coding.

Unless you've previously worked for Marks and Spencer (https://www.marksandspencer.com/), I don't see how you can obtain this.

;-)

[Chris M. Thomasson]

On 6/11/2018 1:20 PM, Melzzzzz wrote:
> Rant: my new job at embedded programming ;)
> So I am now C/C++ programmer...
>

I have been there... No STL and no exceptions... However, POD's all day
long! ;^)

[Juha Nieminen]

I have to wonder if a hard rule like "no STL" is throwing the baby away with
the bathwater. After all, what's commonly referred to as "standard template
library" consists of much more than dynamic data containers like std::vector
and std::map.

For example, arguably std::sort() is part of the "STL", and if you need to
sort a large amount of elements as fast as possible, it's probably going to
be more efficient than most custom implementations.

Of course, I suppose, it depends on how much RAM you have to work with in
your embedded system. If you have 2 kB of RAM available, then that does
severely limit what you can do (and, perhaps, using C++ might not be the
best possible option, unless you have a C++ compiler for it that can
strip away most of the extra stuff and really optimize for size).

Most embedded systems that are used nowadays have RAM sizes in the megabytes.
I'd say that in these cases "no STL" is an actual example of premature
optimization. Know your tools, use the most efficient tool of the task
at hand, and only if it turns out that you are really running out of RAM,
then consider replacing that standard tool with something custom.
(For example, std::vector with a one-time reserve() call, which doesn't
get reallocated after that, ought to be just fine in most situations,
even with relatively tight RAM constraints.)

[Ian Collins]

On 13/06/18 21:47, Juha Nieminen wrote:
> Chris M. Thomasson <invalid_chr...@invalid.invalid> wrote:
>> On 6/11/2018 1:20 PM, Melzzzzz wrote:
>>> Rant: my new job at embedded programming ;)
>>> So I am now C/C++ programmer...
>>
>> I have been there... No STL and no exceptions... However, POD's all day
>> long! ;^)
>
> I have to wonder if a hard rule like "no STL" is throwing the baby away with
> the bathwater. After all, what's commonly referred to as "standard template
> library" consists of much more than dynamic data containers like std::vector
> and std::map.
>
> For example, arguably std::sort() is part of the "STL", and if you need to
> sort a large amount of elements as fast as possible, it's probably going to
> be more efficient than most custom implementations.

The phase "No STL" is nonsense, especially to those of us who used the
origin STL back in the 90s. If someone were to tell me I couldn't use
"the STL" I would just go ahead and use std::array, std::unordered_map
and all the containers and algorithms that weren't in the original STL.

:)

--
Ian.

[bol...@cylonhq.com]

A lot of times the STL and std::string is the only reasom people use C++ over
C. I've seen plenty of C++ code with not a user defined class in sight. Take
out the STL and string and it would be plain C.

[woodb...@gmail.com]

I'm coming from an east const/Hebrew perspective:
http://slashslash.info/2018/02/a-foolish-consistency/

https://www.reddit.com/r/cpp/comments/80k8hc/a_blog_rant_on_east_const/

.

Brian
Ebenezer Enterprises - In G-d we trust.

https://github.com/Ebenezer-group/onwards

[James Kuyper]

On 06/13/2018 05:11 AM, guinne...@gmail.com wrote:
> On Tuesday, 12 June 2018 16:09:35 UTC+1, James Kuyper wrote:

...

>> Speaking of which - I've taken on a new project. The position
>> description said:

...

>> Desired:
>> • Prior experience with M&S software coding.
>
> Unless you've previously worked for Marks and Spencer (https://www.marksandspencer.com/), I don't see how you can obtain this.

In this context, it refers to "Modeling and Simulation". Obviously, it's
too late to gain "prior experience", I'm just looking for ways to make
up for that lack of experience. I've always had a vague interest in M&S,
and some of my hobby programming has involved M&S, but nothing that even
approaches the level of sophistication of the simulations I'll be
working on shortly. I've done no serious study of the field.

[Ian Collins]

The STL formed the basis of the standard library in '98. The STL as was
is no more.

--
Ian.