Summary
When it comes down to it, C++ does only one thing wrong, it tries to be everyone's language.
Advertisement
Most reasonable complaints I have heard, and made, about C++ comes down to the same basic flaw, it tries to be the general purpose language. This is what makes the language so darn hard to use.
So how do you fix it? Well I think the specification should be split up. People writing C++ for PC's, really don't care about portability to embedded controllers! The problem is that you can't rely on the specification to give you anything concrete, not even a filesystem. I mean seriously, just because a handful of embedded micorocontroller programmers want to use C++ (incidentally most don't use true C++), does that mean the rest of us have to suffer?
So what is the solution? Well the standard should fork the specification into different branches. If I were designing my own language (which I am) I would encourage different specifications to branch off of a shared core specification (which I will do).
What I would want from C++ would be a core specification, and a sub-specification for PC's, and another for embedded microcontrollers. Unfortunately the committee is ignoring this, and we have the needs for these specifications being filled inadequately by Microsoft's Managed C++, and EC++. EC++ is a subset of C++, which is unfortunately the wrong way things should be going. If there is going to be an EC++ which is a subset of C++, then why is C++ continuing to be under-specified? I think C++ should allow EC++ to satisfy the embedded controller market and focus on supporting the machines where there is still substantial use.
Imagine the possibilities of C++ specification which integrated a linear memory model, 32 bit word size, threads, a filesystem, etc. I think C++ is spelling out its own demise, by refusing to modernize.
What you refer to is kind of what Sun does with Java: there's J2SE (standard edition), which is basically for PCs. And there's J2ME (micro edition) for phones, and JavaCard for smartcards, and J2EE for enterprise.
I tend to believe that the power in today's desktop computers are that in tommorrow's embedded system.
The technology we apply to PCs will eventually be applied to the embedded systems.
And the gap is not so large. Embedded CPUs such as ARM are already 32-bit, the memory amounts to ten of megabytes.
The fact that C++ is not so popular in the embedded systems as in deskop applications, in my opion, is due to the lack of powerful compilers. And this fact of lacking of powerful compilers are due to lack of intention from the main compiler vendors, I guess.
So, It's not the language itself should be blamed here, but the vendors.
As much as I love the language (and tried to persuade other people to love it) it's frustrating not having standard libraries for the basic things, like iterating over all files in a directory or creating a thread. That's one good reason why C# or Java people are more productive. Trying to explain to people why it isn't easy to do these things is frustrating, because the reason is that the C++ standard goes for the lowest common denominator, which is probably something that schedules the rinse cycle on your washing machine.
Yes, I know Boost tries to fill the gap, but man, those guys overgenerize everything. Generally, a given program is likely to be either Unicode or ASCII, but the standard i/o libraries are templates parameterized by char type. Extremely clever, but ultimately dumb, because this then becomes the problem of the user of those libraries. Much slower compile times, and error messages that cause people to write message parsers.
> The ill comes from that fact that C++ classes are modeled > after C struct, which is valued based. > > All copy constuctor/assignment problems come from this > valued based semantics. Java is so clean compared with C++.
I don't think this is a problem - there are very useful idioms that can be based on value-semantics (like RAII or smart pointers). Also, if you think Java is clean look at the generics in Java 1.5.
> The ill comes from that fact that C++ classes are modeled > after C struct, which is valued based.
Well, at least you have the choice ;) Value semantics are very nice for physical things like vectors and complex numbers, if you have overloading (of course). The rules are actually fairly straightforward, once you accept you have to take responsibility for specifying a class's copying. The main issue is that the standard library doesn't give you much more than generic containers. IMHO, the simplified generic model of C# or Java prevents the overuse of generic algorithm stuff; C++ really isn't a functional language.
The forking should be done as libraries, the core language and core development tools should remain the same.
The problem I have is the information overload due to all the languages & tools I need to learn. If I could just use Eclipse with C++ & C# for everything I would be happy.
I use C# for web & desktop applications. Since .NET dosn't do everything I need to do on Windows I write some code in C++. I then wrap it in managed C++ so I can use it in my C# applications. I have been fumbling around with the layers between external electronics and the desktop for years and still do not have a good solution. This stuff was easy in the days of MSDOS. To do this properly I need to use the Microsoft DDK or some other expensive alternative to write device drivers. If I worked in a place where time means money then we would purchase these layers. Then comes the microcontroller(s) in the external electronics which requires addtional expensive tools for working with a primitive version of C. Then comes the FPGA for which we use schematic entry to program, but everyone else uses VHDL or Verilog. An alternative is SystemC, which means more expensive tools and another variation on C++.
A lot of the stuff listed above could be done with open source tools, but it would be nice if I could get some work done instead of spending all my time learning how to use the tools and languages.
From what I read in books like "Practical FPGA Programming in C", progress is being made on programming tools for hardware. Techniques for writting your application in C, testing it on the PC, then using timing constraints to automatically distribute the application between hardware synthesis & microcontroller code are available.
What all this programmable hardware means for most people is handheld devices, whose funtionality constantly morphs to suit the user and task at hand. For instrumentation types like me it means more programming and less custom hardware.
More comments regarding doing the forking in the libraries as opposed to forking the language.
.NET is a good example of forking at the library level. I use Visual Studio, C#, and most of the same libraries when doing web applications, desktop applications, services, and other application types. The main differences are in a few target specific libraries. Now just extend this paradigm to everything programmable.
Also all the libraries need to be language independent where possible. If I want to use C++, Lisp, Forth, F#, or whatever, I should not have to learn new libraries.
The problem with Boost & STL is they only work in C++. Hopefully .NET 2.0 and the new improved managed C++ will help eliminate some of the restrictions on using standard C++ in .NET. Mono should help eliminate the Windows lock in aspects of .NET.
C++ should be a team player in everything programmable. I am no language expert, but I assume that this has more to do with the development tools and libraries and not so much the language itself.
I was just thinking, my previous comment about the libraries being usable in all languages is irellevent to the current discussion.
I would be happy if I could just use C++ or C# for everything. Being compatible with other languages is only needed for collaborating with others who insist on some other language being the universal language.
I disagree. I use C++ pure in embedded software development with minor exceptions like ISR routines. Today embedded systems are 32-bit and have a large amount of memory available. And if they don't have, it an 8-bit processor with 128 kbyte ROM, 64 bytes RAM; you don't need C++ here.
I know about an embedded OS (eo3s) where C++ is "used" right after about 100 asm lines of code after system start.
And what is "true C++" ? hmmm ? If its a general purpose languague, what is "true C++". There is no true C++. If I like to make a function a template, I do. If I like to make a function global, I do. Use namespaces ? I do. U can anything do with C++ on embedded systems if you are willing to understand why it does things it does. No Languague is perfect, but C++ is very flexible and gives you no additional costs if you don't ask for.
Well I miss some things in C++ but this will change, I'm sure.
A career ago, someone tried to create a better C++ and it was marketed as the Microsoft Component Object Model or COM. COM solves many of C++'s shortfalls and is in part specification and technology. One problem with C/C++ is memory management. COM solves memory management with reference counting. COM also specifies that callees shall allocate memory and callers shalt free thou memory. As an aside I would like to point out that this is quite empowering. Of course this requires that we know the directionality of function parameters. COM's Interface Definition Language solves this by providing attributes for parameters that identify directionality. ADA also has directionality attributes. Enough of this nonsense. COM is a better C++ in many ways but it is quite obvious that Virtual Machines and Runtimes are the better solution. This said, is there a way to add a portable infrastructure to C++ for things like memory management, reflection, dynamic instantiation and the like. Could we have standard configurations that force us to follow idioms that result in better code?
I only miss properties like C#/Delphi instead of the verbose java getter/setter syntax.
The main problem is in 'no standard library for present day apps': XML processing, SQL interfacing, REST web applications.
I tried Java and C# but PHP (combined with Apache) lets me write nice portable programs that can be used in any browser and with any database.
Only C#/PHP let you start with simple programs and then extend to real applications (just like the old C programs for processing files etc...). PHP is more focused on webbased smal l programs, so easier to graps than dotnet...
Flat View: This topic has 15 replies
on 2 pages
[
12
|
»
]
Previous Topic
