Re: C coding

And I thought RPGers were easily offended - good grief Erik - don't take it all so seriously.

I do not personally think that C is a good language for business applications which was the point of my remark. But mostly I was coming from the perspective of Bjarne Stroustrup's comment that "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off".


On 2014-02-13, at 6:37 PM, Erik Olsson <erik.eo.olsson@xxxxxxxxx> wrote:

If someone thinks of C as mainly a vehichle to help you shooting yourself
in the foot then you should probably go into some business. That is just
ignorant and moronic. The language at number 1 for feb 2014 in the TIOBE
index, really? Remind me, where is RPG IV again? I guess the leaders of
North Korea think they are the centre of the universe too.

A word on portability. Well, on a 1-100 scale where 1 is most portable and
100 the least I guess RPG IV is around 100 whereas ANSI C is well in the
top 10. And the ILE C version is not particularly portable. Just looking at
the runtime reference for 6.1, it does not differentiate between C99 and
C89 (snprintf for instance), it's all categorised as ANSI. How is that for
portability? z/OS - another lovely IBM OS - for instance clearly let's the
developer choose the C level (apart from the ISO date flag on strftime that
is always available, guess that's a bug).






On 13 February 2014 19:55, Marc Hunter <marc@xxxxxxxxxxxxxxxx> wrote:

ouch.

Something you could try is defining the string parm in the RPG procedure
definition as follows:

D Parm * value options(*STRING)

Then in the C/C++ code you can do this:

extern "C" int DoSomething(char * szParm)
{
string myStringParm = szParm;

// move on into OOP world here...

It keeps the RPG relatively simple, and the char *'s are converted to
strings as early as possible. A few extra copies of the data, but in
most cases the simplicity is worth it (imo).

Marc


On 2/13/2014 9:43 AM, Tim Bronski wrote:

Yes, but the statement was the attempt to create a c++ string from a
parameter passed from....an RPG program!

On 2/13/2014 6:36 PM, Marc Hunter wrote:

While I empathize, and certainly C++ also allows you to shoot yourself
in the foot, the code shown is philosophically (imo) a mix of C and C++
in that it uses char *s. Assuming both variables are strings then I
would code it as follows and avoid dipping into 'dangerous' char *
territory.

partName.insert(0, userName.substr(start, len));

(If I'm understanding the objective correctly)

Marc

On 2/13/2014 9:02 AM, Tim Bronski wrote:

On 2/13/2014 5:23 PM, Jon Paris wrote:

I would have said that C was brilliant if your aim was to shoot

yourself in the foot and C++ does a better job of protecting you.

Hi Jon, I would have let that slide but I've just finished tracking

down

a bug where c++ was using a different overloaded string function than
the one intended. Here's what the statement should have been:
partName.insert(0, &userName[start], len);
but instead it was
partName.insert(0, userName[start], len);

This compiles fine but the result was heinous...the c compiler would
have caught that one.

--
This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L)
mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.

--
This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L) mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.

Jon Paris

www.partner400.com
www.SystemiDeveloper.com