Weekly Edition
Return to the Development page
| |||||||||||||||||||
ACC 0.5 released
Hi, We are pleased to announce the release of AspeCt-oriented C (ACC) V 0.5, formerly known as AspectC. Besides some new features, the ACC 0.5 release also includes a set of experimental weave adapters that help integrate aspeCts in the build process of large C-based software projects. For more details and download, please visit http://www.aspectc.net. Highlights of ACC V 0.5 include: o ACC demo at AOSD'07 this week (Wednesday & Friday) o A set of experimental weave adapters to integrate ACC into large builds o Debugging support and improved error reporting o A set of course assignments applying ACC in the curriculum of a 3rd year Operating Systems course (available from our web site). We appreciate feedback and support for AspeCt-oriented C. Regards, ACC Team www.aspectc.net March 12, 2007 (Log in to post comments)
ACC 0.5 released Posted Mar 13, 2007 16:56 UTC (Tue) by ronaldcole (guest, #1462) [Link] My first impression, after beginning the tutorial and reading up to the malloc() example, is that it's not obvious from reading the main code that malloc() has effectively been revised and extended. I would have to examine the other source files of the entire program to discover which of the "naked" libc functions I see in the main source have been "encumbered". I really don't see this as an actual benefit to me, a C programmer. It tastes just like syntactic sugar for all the xmalloc() wrappers ever written, which at least gave a visual clue in the source that a wrapper was checking the return value.
ACC 0.5 released Posted Mar 13, 2007 19:19 UTC (Tue) by phiggins (subscriber, #5605) [Link] This is pretty much *the* problem with aspect-oriented programming. It enables you to get a high level of reuse for certain constructs that are traditionally very hard to abstract (such as tracing, logging, and performance timings), but you can no longer look at the code and tell what it's doing. And I don't mean in the sense of "I can't translate this Java code into the native instructions that will ultimately get run in the virtual machine in my poor little head," but that fundamental logic changes may be getting inserted into the program generated from this source file by code that lives in other files that I know nothing about.
It would be very powerful for one or two people working on a project by themselves who also know about each aspect that is getting applied. They could take advantage of the full power that aspects offer. However, on large projects, I don't think they're ever going to see use outside of the niches they have already found, such as database transaction management, logging, tracing, and profiling. Basically, functions where the aspects don't change the meaning of the program (DB transactions are an exception).
ACC 0.5 released Posted Mar 13, 2007 17:07 UTC (Tue) by mmarq (guest, #2332) [Link] Ok.. without having to post a long disclaimer, i just wat to say that i belive C cames short in many "aspects".
.- Concurrency: Today CPUs with CMP and specialiazed SMID/MIMID exucutions units, could take great advantage of a language with native concurrency support, http://en.wikipedia.org/wiki/Concurrent_programming_language ...
.- Logic: If a hardware programming language has to have a good chance of being adopted to programme BIOSes and firmware, in my layman view, a closer to the metal programming than the kernel, would benefit greatly, i belive, by adopting also a "logic" paradigma. http://en.wikipedia.org/wiki/Logic_programming
.- OO: The Aspect paradigma( included in C as ACC in this tread), and perhaps with strong prototyping also (lock easy!?) http://en.wikipedia.org/wiki/Prototype-based_programming
.- *Easyer* sintaxe and simplified semantics: Since FOSS is about to give a layman a change at least in an entry level, a more "readable" language derived from the yet most adopted C/C++ paradigmas would be gran...
So having exposed the above, i belive a possible conclusion is , that by extension and or retrofitting an extensible multiparadigma language, derivatives for best fitting for a particular role can be constructed... i belive!
.- From D; extending concurrency, logic and aspect with (prototyping ?), and excluding Garbage, it could or could not be build a *very good* language for kernel and firmware programming ? *[Dernel ?]
.- From D; extending concurrency with (transactions ?) and (actor model ?), logic and aspect or other OO, it could or could not be build a *very good* language for application programming ? *[D+ ?]
*IN THE END IS UP TO DEVELOPERS*, but i belive D is a very good point of start, is extensible , is multiparadigma, and was build with practical programming point of view in mind and not as a Lab specific problem solving solution.
The idea is replace C/C++ alright, but in a way that the *sun* can evolve without having to kill his *father*.
ACC 0.5 released Posted Mar 14, 2007 1:12 UTC (Wed) by djabsolut (guest, #12799) [Link] The idea is replace C/C++ ...It irks me to see C and C++ put in the same category, ala "C/C++". Yes, C++ contains almost all of C, but that not mean that it is the same language. Far from it. Writing code using normal C++ features (classes, inheritance, templates, operator overloading, smart pointers) not only increases the readability, but the amount of functionality per line of C++ code is (on average) 2.5 more than for 'C'.
ACC 0.5 released Posted Mar 14, 2007 10:23 UTC (Wed) by sdalley (subscriber, #18550) [Link] And, unfortunately, the cost of maintenance for equivalent functionality in C++ vs. C also increases by a factor of 2.5 or so. Since maintenance is typically 80% of the total effort in a software project, this is a very important consideration. See this really interesting and thought-provoking paper http://www.leshatton.org/IEEE_Soft_98a.html for supporting data.
It would be interesting to see some hard data on the development/maintenance effort required of C-library-based Gnome vs. C++-based KDE.
ACC 0.5 released Posted Mar 14, 2007 16:21 UTC (Wed) by tjc (subscriber, #137) [Link] I'm less than half way through it, but so far this paper is very interesting -- thanks for the link!
ACC 0.5 released Posted Mar 14, 2007 16:39 UTC (Wed) by gnb (subscriber, #5132) [Link] >It would be interesting to see some hard data on the>development/maintenance effort required of C-library-based Gnome vs. >C++-based KDE. That's a rather different comparison, though: the paper seemed to be focused on the value of OO as a design approach with the choice of implementation language being seen as rather secondary. Gnome v. KDE would far more about choice of language - gtk+ has objects and an object hierarchy and so forth, it's just implemented in C with copious preprocessor (ab)use rather than in C++.
ACC 0.5 released Posted Mar 15, 2007 1:47 UTC (Thu) by djabsolut (guest, #12799) [Link] An interesting paper, though it has several limitations. It was written in 1997 (and cites earlier studies), before the current C++ standard was solidified via ISO standardisation. Due to more language features C++ takes longer to learn than C, and hence there is doubt about the veracity of the claim in the paper that "both systems were the work of the same experienced staff with expert language skills in both languages". It has been observed elsewhere that people familiar in one particular language tend to keep their styles when writing in another language. Futhermore, the size of the comparison is rather limited, raising the question about the statistical significance of the differences. The paper also focuses on the OO aspect of C++, while the language has more features than that. Two primary examples are templates and operator overloading. The former enables considerable code re-use via seperation of methods and data structures, while the latter makes the code considerably easier to read. (Granted, the template facility can be abused in C++, resulting in incomprehensible compilation errors.)
Interesting concept. Posted Mar 13, 2007 20:25 UTC (Tue) by jd (guest, #26381) [Link] We now have C, C++, ObjectiveC, ObjectiveC++, C# and D. These, in turn, IIRC, descended from B and BCPL.The main benefit of C is simplicity. Little overhead, lots of flexibility, more-or-less direct access to raw capabilities. Unfortunately, that is also its weakness. Code works close to the raw performance, when it works. When it doesn't work, it can be hellish to find out why, because there is so much power at the programmer's disposal. The alternatives to C trade off some of the power and compactness in order to improve reliability and code safety, on the premise that no single program needs all the power, so losing what you don't (or perhaps shouldn't) use is no big deal. The theory is good but flawed. You don't know which facility is going to be needed in any given program until you get to that point. That's the whole premise behind software engineering - the details of exactly how something is done is one of the last decisions. To choose a language that forces you to make implementation decisions as part of the specification process contradicts the entire approach. (Which explains why nobody ever actually uses software engineering methods in practice. It's not that they don't work, it's that they don't work with the tools programmers end up using.) Another problem is that program methodologies are lagging behind real-world technologies. We are in the era of hyperthreaded CPUs, hard realtime and multi-threaded applications, clustered (ie: LAN) systems and grid (ie: WAN) systems. We have Mobile IP and Mobile Networks. Multicast and anycast are becoming more fashionable. Mobile processes are being experimented on. The days of programming as a single, static blob are drawing to a close. There is no programming language out there that allows for formalism, compartmentalism, mobility, parallelism, predictability and performance. Generally, you can pick one or two from the list, three at best. That's not going to cut it in today's generalized programming world. It's fine if you want to write something to control a nuke reactor or an aircraft. I'd hope you'd use a specialized, finely-honed tool for such work. But in a world that is mostly based on reusable software and hardware and where everything is commodity, then the programming languages MUST be designed with those considerations in mind. They aren't. So, for now, I'll stick with C. It may not be great at anything, but because it is simple, I can make it great at whatever I need it to be great at. I can't do that with any other dialect, to the best of my knowledge, and that's just too limiting.
Why limit yourself? Posted Mar 14, 2007 8:55 UTC (Wed) by niner (subscriber, #26151) [Link] Nearly every language has the ability to interface with C code. So there is no either/or. You can even use some very high level scripting language for the general structure while using C for performance intensive tasks thus using the best apects of any language.
Off topic C/C++ rant Posted Mar 14, 2007 14:29 UTC (Wed) by felixfix (subscriber, #242) [Link] It took me a while, as a long time C programmer, to realize what I disliked so much about C++. In C, you have malloc() and free(), and nothing to help you; if you free twice or forget to free, or forget to malloc, you lose. In C++, it didn't really improve, it simply added two new ways of hosing yourself, with two new and two release (is that the right name? I do so little C++ nowadays that I may be wrong :-). Not only do you still have to remember to apply free/release/release exactly once for every malloc/new/new but you also have to keep the two new/release pairs straight. I never quite figured out how that was supposed to be an improvement, let alone having so many more keywords and ways to do things that you pretty much need to have a reference book handy at all times. I figure if it's come to that, I may as well use a different purpose-designed language instead.
Off topic C/C++ rant Posted Mar 18, 2007 19:59 UTC (Sun) by nlucas (subscriber, #33793) [Link] Much of the things I deslike in C++ are the stupid compromises made to make it more compatible with C, but you do get a lot more.
In the case you mentioned, that is just a simple use of one the most used idioms on any object oriented language: RAII [1] - aquire resources on the object constructor and release them on the object destructor.
If you follow that idiom, you can do something like this:
void func( ... )
and you don't need to remember to unlock the file, nor release any resources, because that is automatically done on the function exit (by invoking the lock destructor). This will work even if an exception is raised.
The same with your malloc/free new/delete case.
You can use C++ just like C, but you don't get all the advantages.
[1] http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Init...
|
|||||||||||||||||||