There are addition boundaries in my work which require translation when finding the appropriate place for a piece of logic. These layers are C#, C++, Embedded C, & VHDL. The C# & C++ layers are connected using managed C++. The C++ & Embedded C layers are separated by a USB cable. The Embedded C & VHDL layers are separated by the connection between the microcontroller and the FPGA.

I try to keep as much as possible in the C# layer, but due to speed, timing, & the need to connect to the real world, some things need moved down the line closer to the hardware.

How about refactoring tools that can move code between layers, when the layers are written in different languages.

I don't think C++ is less "agile" than other languages. The current problems are lack of decent tool support for refactoring (though it might be harder than doing it for lava or C#) and legacy... Legacy, being it developer's or tools is the greatest problem in C++.

I'm still working with C++ and I find always refreshing some of its features. The problem is to deal with monolithic programs that must be maintained (without a decent battery of regression tests) and 7 year old compilers and tools.

PS: Think about why does so many new C++ code uses char * instead of std::string?

I agree with most posts here. Better refactoring/testing/building tools would go a long way to provide agile development environments using C++ as an implementation language. The primary goal of agile is to keep the feedback cycle as small as possible.

To determine whether code I'm going to write will work I need to be able to test it. If my testing tools require a lot of work to write my tests my response time increases.

To test my code I need the ability to build the code. If the build tools require too much time then my response time increases.

If it takes a lot of time and effort to refactor then I can't test my refactoring quickly enough and my big picture of the design (in my head) might get out of sync with the small refactoring I just made.

Language complexity can get in the way but this is easily solved through knowledge and experience. It might take a long time to acquire the appropriate knowledge and experience but, then again, nothing comes for free!

> I don't think C++ is less "agile" than other languages.> The current problems are lack of decent tool support for> refactoring (though it might be harder than doing it for> lava or C#) and legacy... Legacy, being it developer's or> tools is the greatest problem in C++.> > I'm still working with C++ and I find always refreshing> some of its features. The problem is to deal with> monolithic programs that must be maintained (without a> decent battery of regression tests) and 7 year old> compilers and tools.> > PS: Think about why does so many new C++ code uses char *> instead of std::string?

I guess you gave the answer to that above: "legacy" developers and tools...

Many programmers write essentially C in C++, i.e. not using the advantages of C++, such as the standard library.

The reason for this may be several: Some programmers just haven't updated their knowledge, and keep writing C. It doesn't exactly help that some C++ courses start by teaching C, and barely get time to go into the improvements in C++. Some may use compilers that doesn't support more modern C++ (although all popular platforms have support for std::string).

> I guess you gave the answer to that above: "legacy"> developers and tools...> > Many programmers write essentially C in C++, i.e. not> using the advantages of C++, such as the standard> library.> > The reason for this may be several: Some programmers just> haven't updated their knowledge, and keep writing C. It> doesn't exactly help that some C++ courses start by> teaching C, and barely get time to go into the> improvements in C++. Some may use compilers that doesn't> support more modern C++ (although all popular platforms> have support for std::string).> > Regards,> > Terje

Yes, many times I see decent developers working differently when using java and C++. With C++ they structure the code with classes, but, they get big and too much interdependent , e.g., they don't know how to work with interfaces in C++. Also they use the unfortunate "StdAfx.h" approach that is encouraged by M$ tools.

In java you see then using modern design techniques like design patterns and even TDD!

"But hey, " - I say to them - "you have CppUnit (http://cppunit.sourceforge.net) and it provides a decent support for TDD in C++!" It isn't worth the effort. They need a total recycling to get working alright. If I was in charge, no veteran C++ developer would start a project without reading The Stroustup! And note that he isn't agile, he just teaches the language as it is supposed to be used.

PS: std::string was available about 10 years ago, but, even today you see people coding with char * in new projects. They say that std::string isn't performant ;->>

> > PS: std::string was available about 10 years ago, but,> even today you see people coding with char * in new> projects. They say that std::string isn't performant ;->>

There are many reasons why us old farts don't use STL. My excuse is I just havn't got around to learning it yet. Saying it has been around for 10 years is pushing it. My 1996 copy of "STL Tutorial and Reference Guide" by Musser & Saini mentions <bstring.h>, but dosn't have anything about namespaces, let alone the std namespace. If memory serves me right, the Standard Library became standard in 1998. Going back a little farther a book called "Advanced C++" by Namir Clement Shammas in 1992, goes through how to build your own template library. Due to the fact that my C++ books were becomming obsolete before reading them, I stopped buying C++ books for a while. I only started buying C++ books again in the last couple of years.

During the time when I should have been keeping up with the changes in C++, I was wasting my time with x-windows, java, win32, MFC, ActiveX, DCOM, ActiveX, VB, ATL, etc. Throughout this time my C++ codeing style pretty much followed the OOP style I learned in the early 90s & the C libraries I learned in the 80s. Then along comes C#, which is what I have mostly used since 2001.

When I did try reading Musser & Saini, it was like trying to read a foreign language, and I had more pressing things to learn.

After reading Essential C++ by Lippman, I replaced most of my C library code in the project I was working on with STL. Then a year goes by, my C++ books are at home and I need to do some quick modifications. I can't remember how to do things the C++ way, so I revert back to using <stdio.h>.

Using C# and reading Agile and Patterns books has greatly influenced the style of my C++ code.

Once in a while I pull my Stroustrup, Vandevoorde/Josuttis, & Alexandrescu books off the shelf, but then get side tracked and they just go back on the shelf.

Looks like my C++ books will stay on the shelf a while longer, since I have "Refactoring To Patterns", & "Working Effectively With Legacy Code" sitting here waiting to be read.

> > PS: std::string was available about 10 years ago, but,> > even today you see people coding with char * in new> > projects. They say that std::string isn't performant> ;->>

Unless they have measured, and found this, I'd think this is just superstition. There's no reason that std::string can't be just as efficient as hand-coding your own string code (but without the tedium of doing that - I've done it when I used C, and I don't miss it. :) ).

Mine has been a similar experience. I started learning C++ around 1996 or so (and had learned C before that). Later, I went back to school, and had Java there for a few years. When I was done, and started reading up on C++, again, I found two things:

1) It wasn't your granddaddy's C++ anymore: :) a lot had changed.

2) I kind of had to "deprogram" myself, after having learned Java. Since everything is a class in Java, then for a while, I continued like that in C++. So if I needed some utility functions, I made a class with static member functions. Having read up on C++, again (Stroustrup, Meyers, Sutter, etc.), I realised that this wasn't necessary: I could just make them free functions in a namespace...

However, to its creadit, it was first when I had Java at school that I really "got" OO. I had read Stroustrup (2. edition) earlier, and tried to use it to learn C++, and found that difficult (especially if you don't know OO, like I didn't. The book started with a "Tour of C++", and I fell off already there, because it mentioned things like support for OO and generic programming, and I didn't know what either of them meant. :) ). It's a good reference, but I wouldn't recommend it for learning C++ (however, I understand the 3. edition is better in this respect, too). Had I started today, I'd preferred "Accelerated C++", which starts with C++ as a high-level language, i.e. using the standard library, etc. Stroustrup is kind of a book that may be useful as a next or n'th book, having got the basics of both C++ and OO.

> After reading Essential C++ by Lippman, I replaced most of> my C library code in the project I was working on with> STL.

Sounds good. :)

> Once in a while I pull my Stroustrup,> Vandevoorde/Josuttis, & Alexandrescu books off the shelf,

Good books. :)

> Looks like my C++ books will stay on the shelf a while> longer, since I have "Refactoring To Patterns", & "Working> Effectively With Legacy Code" sitting here waiting to be> read.

*g* Both highly recommended. I read both recently, and is currently re-reading Fowler's "Refactoring". That's also a gem.

I'll probably revisit GOFs "Design Patterns" again, too, and I think I'll make a list for myself of the refactorings and patterns in these books (as well as the techniques in "Working Effectively with Legacy Code"), because I discovered that I didn't know them well enough. It's my experience that in order for refactoring and design patterns to be useful, you have to at least know about them and their intent, so that if you're in a situation were one may be useful, you may recognise it, rather than "reinventing the wheel".

I think that one thing is central for a language to be agile: the practitioner must be agile also. One of the main things I've learned in my humble agile path (a bit less than 2 years) is that one has to be ready to improve always. If we want a more agile C++ then we must first of all get coding our programs right. I'm trying and in many ways I find C++ more agile than other newer languages.

> > If memory serves me right, the Standard Library became> > standard in 1998.>> Right.>> > I only started buying C++ books again in the last> > couple of years.>> Mine has been a similar experience. I started learning C++> around 1996 or so (and had learned C before that). Later,> I went back to school, and had Java there for a few years.> When I was done, and started reading up on C++, again, I> found two things:>

My background is much more humble. I started working in C++ in 98 and it was with Bruce Eckel's book "C++ Inside & Out". It was my second language after Turbo Pascal, in the procedural style... I've read it from start to end, always improving my style as I went. Now I'm going through Stroustup "The C++ Programming Language" 3rd ed and it is adding up. With it and with some nice libraries (e.g., boost, CppUnit, etc) I'm getting even more agile in a sense of having more power, of getting fast feedback from what I code and of having decent unit tests of my code that help me get faster the right design and eliminate dependencies in each component and class as I implement the overall project.

So, alas, I think C++ is agile yes. If programmers and tools get to level with the language and we leave legacy C style coding practices, I think we'll have an agile language as much as many others.

As an example of a C++ tool that would be great I think that compile as you code like eclipse does for java, so that we don't have to explicitly hit the 'X' key to have the error feedback. Another is for the C++ standard lib being supported natively by dev environments. I.e., if you debug a program you'd get std::map instances presented in a friendly way. Yet other is decent refactoring support, as you have out of the box for java in Eclipse...

What I need is a hard core C++ book, but on an intersting topic. It is hard to read a book like "The C++ Programming Language: Special Edition" by Stroustrup or "C++ Templates" by Vandevoorde, because they are so far removed from what I am interested in.

For example reading "Physically Based Rendering" by Matt Pharr is a lot more appealing then reading "The C++ Programming Language".

Back in the 80s I was reading OO books by Peter Coad and others, they typically made sence, but I could not connect the ideas with what I was doing. Reading "Learning C++" by Tom Swan did not help much. A very understandable book, but still no connection in my mind to the code I was writing. The book that made the difference was "Graphical User Interfaces With Turbo C++" by Ted Faison. The book presented a complete working GUI, and by the time I had morphed the code into the style of GUI that I wanted, I had a very good idea of how to do OOP in C++.

The problem with templates & STL is, I have never seen them used much in books on topics that I am interested in.

The same goes for books on agile programming. The examples are extremely boring.

When I pick up books on interesting topics like "AI Application Programming" by Tim Jones, all the example code is in C.