Slashdot Mirror
C Alive and Well Thanks to Portable.NET
rhysweatherley writes "So C is dead
in a world dominated by bytecode languages, is it? Well, not really.
Portable.NET
0.6.4 now has a fairly good C compiler that can compile C to IL bytecode,
to run on top of .NET runtimes. We need some assistance from the community to port glibc in the coming months, but it is coming along fast. The real
question is this: would you rather program against the pitiful number API's that come with C#, or the huge Free Software diversity that you get with C? The death of C has been greatly exaggerated. It will adapt - it always has."
...stop telling me things are DYING, maybe let me know when they're DEAD.
Isn't C++ widely portable while giving mast if not all of the features of C# (except for being interpreted)
I'm not a programmer.
Is this a good thing or bad thing is alive?
Coming soon... Communix.org. Put your blood, sweat, and tears into this Unix variant so that it can benefit your fellow comrades. No pay, long hours, and the glory of the state awaits you.
Remember when punch cards went obsolete?
C is still alive and kickin' in the NIX community I'd say. It seems it's really just Windows where other languages (C++, C#) seem to be taking over. Just because C isn't being used much in the Windows world doesn't mean it's dying ot is going to die anytime soon.
Buckethead
C?
Yeah, just kill it off already... I wanna go back to using Commodore 64 BASIC.
READY.
PRINT ""+-0
All the advanced language features of C with all the speed of an interpreted VM!
Can I get them to compile asm to java bytecode next?
Sorry - someone had to say it!
A little planning goes a long way...
With all the memory leaks in the .NET framework (I'm talking about the MS version of the .NET framework here) why would anyone, in their right mind, want to turn their C code into something that runs like crap?
Free Firefox news reader.
C lives on; driven by an insatiable unreasoning swarming hunger. Until the day when the seventh seal is broken, the sun dies, and all the languages are at last bound to it's dark will. Then all of man, in the Doom of our time, will writhe in agnoy for a thousand years of darkness until the, strongly typed, Rapture casts the dark empire back into the pits of hell, and scatters the damned to the winds.
QUOTE: The real question is this: would you rather program against the pitiful number API's that come with C#, or the huge Free Software diversity that you get with C? The death of C has been greatly exaggerated.
.NET API's are by no means 'pitiful in number', and they can be embraced, extended, and overridden as desired. C *can* adapt, but the point of a C# based desktop system or development platform is not solely to exclude C, but to bring the benefits of managed code to other system consumers. C could adapt, but not without a lot of overhead and fundamental changes that really is the point behind C#. I'm sure we'll be in a backwards-compatible, C-friendly world for a long time to come, but there's no reason to bash something new and different because it is new a different. That's just FUD.
Now what a spin. The
Be very, very careful what you put into that head, because you will never, ever get it out. -Thomas Cardinal Wolsey
FORTRAN and COBOL are still in wide use, even if they aren't as popular as they once were.
Mea navis aericumbens anguillis abundat
C has it's problems. You could complain about C all day, the problem is, it's the best thing we have right now. One of the problem with modern languages is, you can't write an operating system in them. One of the problems is half the new languages are scripting perl/python like langauges and the rest compile to byte code. Maybe C would go away if there was a compiled langauge that wasn't largely controlled by one company that produced fast code and was portable. The closest thing to that besides C is C++.
An interesting trck, but it has been thought of before...
.Net bridge won't help you if there's some native feature of the device with no Compact.Net library support.
A more interesting question is why you wouldn't rather just use C on these various devices, which by their nature are constrained and lend themselves to code that squeezes all you can get out of them.
A C to
And then of course there are the number of devices that support Compact.Net... wouldn't you be better off finishing up that C->Java compiler so you could write bytecoded C for things like the blackberry or sidekick or Treo?
Seems kinda astroturfy to me.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I prommised myself that I will never program in C again. And so far, almost a year now, I am sucseeding in this! I even think that I already forgot what * and & are meaning. In the past, I have programmed many different projects in C, including a very complex embedded system. But when I have the change I will use a modern language like Python. Maybe it is slow(er), but the total time spend is so much less. But that I do not have to tell that to /. right?
In the meantime I'll just risk being labeled "old-fashioned" and compile C straight to binary
And its done by someone with a new technology to get people talking about it. Look at all the debates and forum chatter that got sparked off by intels "Bluetooth is dead". "C is dead", "CISC is dead"....
,"Apple is dead".
When technologies really do die, its when noone gives a damn about them, and so noone will be writing a story about it.
It seems to me (even with my limited knowledge of programming and software engineering) that when such statements are made about the death (or undeath...mmm...CZombie...."HEADERS....HEADERSSS") , the idea that C# has its place in fitting in with the .NET framework, C has its place in things like...say...stuff like the Linux kernel (though that isn't near its only use), Java and it's being cross platform, etc is totally ignored.
Just because you can hammer in a screw if you try hard enough doesn't mean the screw driver is dead.
When you hear someone declare "X is dead" it usually means they have a vested interest in X actually dying, and wish to further that belief. Either that or it's more like a mafia situation where a statement like "X is dead" is more of a prediction with a strong likelihood - it all depends on the power of the speaker.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Summary of argument to date (translated from geek-speak):
> Queens English is so dead.
> Yo, it's all about Ebonics.
> Dude, Southern Drawl is *soo* slow... Surfer speak is a way better language.
> Like, Valley Speak is, like, the best networking dialect to know!
> Well, if you want a job with a blue-chip company, go with Chicago Twang.
> I hear that they're porting the Queens English libraries to Chicago English, btw.
> See? Queens English is not dead...
Dialects, people... just dialects. Try to see things in the broader scheme of things. (punny, eh?).
I think it's a bit silly to say that C is "dead." As a Christian, I won't write anything in C (obviously), but it's hard to call a language "dead" when there are billions of lines of C code out there and running everything from ATMs to nuclear power plants. What language do you think that your Linux kernel or your Windows XP internals are written in? How many processor-intensive image processing systems are written in C, and do you think that these systems are going to be ported to Java or BASH? C isn't going anywhere anytime soon. It has its problems as a language but it still remains a powerful tool if your particular belief system is compatible with its philosophy.
It's just pining for the fjords.
I'll start worrying when I see entire OS's and their requisite device drivers written completely in a bytecode language.
*shrug*... bring it on.
if we could only get a compiler that does what I think I'm doing instead of what I actually told it to do....then we'd have something
http://cat.nyu.edu/~meyer/jasmin/
We need C like we need more buffer overflow vulnerabilities!
Let the miserable wretch die, or overhaul it to be type safe.
There are some things that are better buried.
However, you should check News.Google.com frequently in case the world ended and no one told you.
I have never used, and will never use this bytecode languages running on VMs. I won't the minimum distance between my program and the machine instructions. Currently, C is the best language for this purpose.
Unfortunately, a lot of CS courses are teaching people the importance of "managed code" and "strong typing" etc. I say to hell with that. If I feel like messing up with memory at AF345F12:BA231DCE then I shell do so. I don't want to hide behind "type safety". I know what I am doing.
I have no faith in these OO language crap either. The real world maybe OO, but once your code is compiled, it is going to run us a sequence of statements: i.e., like an imperative language. Not to say that people have not tried to build processors which had OO machine code, but none of them caught on. I work mainly with the Intel architecture. It's not natively OO.
Long live C
Indefinitely Detained US Citizen
There are a huge number of applications that have very stringent time constraints, especially in real-time control. Other than coding in assembly, there isn't any other language out there that is as efficient (both size *and* speed count) as well optimized C code.
As an example, our lab works with humanoid robots that run in a 5ms control loop, which means that the next command (computation of inverse dynamics, etc.) has to be ready in that timeslice. If you want to do fancier stuff like machine learning and AI, you'll have to squeeze in many more operations into that tiny window. Sure, additional processors are a plus, but you still need very fast and memory efficient code.
"In mathematics, it's not enough to read the words -- you have to hear the music"
I know. I killed him. I ran him down in my PHP-mobile while drag racing with those Ruby punks on their friggin crotch rockets. At least C++ had the sense to step out of the way. I guess they were arguing about how their half-witted brother C# knocked up his half witted twin sister, Java, and produced some hideous premature birth thingy who they called Mono. I would have turned around and hit C++ had I not blown a module and had to stop. Those Ruby punks gave me the bird, but you wait and see. I got this new Zend nitrus which knock the socks of those badboys but I don't know how plug it in. Anyone got the number of a good mechanic?
...is like saying too many busses will eliminate sports cars.
The C design paradigm (low level, varied environment, highly optimized, developer control) is intended to solve an entirely different class of problem than Business runtimes (higher level, standard interface, managed resource, developer handholding). The two aren't in competition much at all.
Nor do I think much about trying putting a racing-wheel on a bus either. We already have C# and "Managed C++", both which can look quite a bit like C, if you want them to. All you have to do is ignore that they're fundimentally different in the way they treat resources due to the underlying runtime or lack thereof. (Which is like equating a bus to a sports car, ignoring the size and speed issues.)
Does this include *all* of C? How do they compile the following C features into VM bytecode?
- Pointer arithmetic
- Hardcoded type sizes instead of using sizeof() (i.e. assuming sizeof(int) == 4)
- Lax rules for casting
- And so on
When can I get an f77 to IDL compiler so I can watch an atmospheric simulator die on Windows? ;-)
So now you can write C code and it compiles for .NET. Does that mean it works for MONO as well?
Or we can look at it like this: "Wouldn't it be better to have many different toolkits that allow string concatenation and tokenization than one standard library of string functions?"
Or maybe this: "Isn't it great that we have several different native APIs for threads, processes, and IPC depending on underlying platform, five different and incompatible implementations for cross-platform usage, and no way to easily switch between implementations after the project is underway?"
And next shall we talk about databases? Or maybe sound processing? Or regular expressions? Hmmm...
The thing that C zealots fail to recognize is the need for clean, standardized APIs (NOT implementations). If you write code that uses strncmp(...), aren't you glad that you don't have to worry if the C implementation is the BSD libc or glibc or MS Windows' C library? Don't you wish the same could be said for the user interface libraries -- for example being able to swap out the Qt or GTK+ implementations at compile or link time? Or the database libraries? (ODBC? Don't make me laugh.) But you can't because each implementation has its own interface even though a button is a button, a checkbox is a checkbox, a database connect is a database connect, a regexp is a regexp, etc.
This is what .NET gives; Not the mandated implementation, but much better it gives the recommended interface. If the C folks get it together and standardize more than just things like printf(...) and linked lists, you will get no end of gratitude from me and the gratitude of folks who are tired of reinventing the wheel and solving problems that were adequately solved twenty years ago. Unless that happens, you're gonna see more and more people moving to things like .NET and Java, warts and all.
POSIX was a good start, but it has stagnated and is showing its age.
- I don't need to go outside, my CRT tan'll do me just fine.
Miguel de Icaza - this person is annoying. Many people write to me and tell me they suspect he is a Microsoft mole. Whatever: he's the guy who said Clippy is a good idea. Go figure.
.NET is totally uninteresting, Mono is even more uninteresting, C# is an abomination, and Miguel de Icaza is totally irrelevant.
What the world has right now is the following:
1. Native assembler. This is always a fall-back.
2. C. Great for writing operating systems. Capable of inline assembler as well, so efficiency is very high.
3. C++. I have my doubts. And I think its prevalence would not be as great were it not traditionally so difficult to use the next language on the list.
4. Objective-C. What Alan Kay always envisioned, but in compiled form. As long as we are using GUIs with widgets and gadgets, this will be the premier choice.
5. Java. Not native, but eminently portable.
In the context of the above, I am sorry, but
Thompson, Ritchie, Cox, Gosling - these are great computer scientists. de Icaza is a fart.
There are python bindings for kde, as well as many others.
Please use [ informative / summarizing ] SUBJECT LINES
Flame me here
You could compile it to machine code and run it native, or you could compile it into any number of intermediate languages and run it with an interpreter.
.NET is the systems thats really stuggling.
Why would you do the latter? For what advantage?
C isn't dead, C++ isn't dying.
C# is nothing more that Java language and .net is nothingmore than Java platform. That's fact.
;-)
.net on projects and i am realy surprised by /. post that claim "portability" to other OS ! MS has clearly put this point in front of the world : .net will only be available on MS OSes. This means that the complete specifications will never be available. Hence you can never claim to be "compatible" with it as you can not raise your complience level to one that enterprise require for support reasons.
;-)
Did Java kill C since nearly a decade it is here ? No ! So there is no doubt that a windows only platform (.net) can kill a multiplatform language !
If there is a platform that has deprecate C/C++ in lots of enterprise developpment it is more Java itself. Ey guys, look at the realworld !
Java has replace lots C/C++ developement just because it is much easier to setup and to maintain with an "average" skill (you got plenty of free & free solutions as well as bullet proofed comercial solutions that fits every needs).
Java is also the key to open the server side OS. Because by choosing Java enterprise can shift to any supported OS they want depending on their TCO for instance. And there Linux win in most situations here !
So Java offer OS choice and Linux OS solution
Personally, i've worked with
I do not realy understand people working on mono (which is a nonsense by the way), why don't they go and help FSF's classpath project instead if they want a realy free implementation of some advanced language & VM ? Ey, FSF ! Know those guy
So if you want to help Linux to get a truly independent, full GPLed & fully compatible solution : Go and help FSF's CLASSPATH PROJECT ! They do need your skills !
Please don't. Yes C++ as a language has compilers for many platforms which are pretty much compatible, but the degree of compatibility of these compilers don't mean much since the compatibility of an application is a totally different story. An application written in C++ will be using some kind of library, for DB access, for GUI, for network operations etc... Most of the times, these libraries are not cross platform. Or they have to be extended with platform spesific code. It has been discussed in /. many times, check it out yourself. Cross platform GUI, cross platform libraries, and there is almost always a catch in all the solutions. .NET i just don't believe MONO guys can keep up with it. C# 2.0 and longhorn will be a huge step forward for .NET technologies, and i don't thinkk MONO team can find resources to keep up with MS. .NET.
The story may change if you are writing C++ code that can stay in some kind of boundy, without using much library code, but unfortunately, i did not have that chance.
IMHO, java is really successfull in cross platform software development, without much work i can make java software work on another platform.
If C# had the same future, i'd be really glad, since i like it too, but as Microsoft works harder and harder on
Don't get me wrong, i loved the work they've done, but the result will be a platform inferior to java 1.5 and
So i'll be using C++ for platform spesific, high performance apps, C# for windows apps that require rapid development, and JAVA for cross platform. That's my 2 cents...
Of course you'd also have to disassembly every library MSOffice uses and every library those libraries use which includes the NT kernel. So by the time you're done, you'd be running Windows in a JVM just to run MS Office.
I hated MVS. I hated COBOL. I hated ASSIST. I most DEFINITELY hated JCL. All due to the restrictions from those damn virtual punch cards. Column 8 my ass.
Slashdot is proof that Sturgeon's Law applies to mankind.
It's all just a horrible conspiracy to gradually shift hardware and software towards a centrally controlled, inaccessible quagmire of unbreakable digital rights management and spyware! run for your lives!
man.. I'm so sorry, it seems you are going to Malbolge
JVM doesn't have any pointer operations ... IL does .
...
Which means you get a set of pointers which play nice
Quidquid latine dictum sit, altum videtur
... if I had an equivalent set of class libraries. Haven't actually seen one for C++, but Cocoa for Objective C is pretty good and there is an ObjC++ compiler.
The way I see it, the benefit of garbage collection is nearly canceled by the lack of stack variables and guaranteed destructor calls. I want to just declare a "Socket" variable in the middle of my function and have a guarantee that the socket will be closed when the block is existed in whatever way. finally or with just don't cut it. Say, I use 2 sockets, 1 file, a mutex and a temporary hash table entry at different points in a function. Imagine the mess of nested blocks, especially since Socket.close can actually throw an exception!
By contrast, memory management problems in C++ can be mitigated by destructors, reference counting and containers that automatically free members. Not ideal, but usually doesn't disfigure your code.
Now add other things missing from Java and/or C# - preprocessor, templates, multiple inheritence, operator overloading, unsigned types - and the new languages are really not that compeling for large projects that need heavy-duty, "dirty" features to manage complexity and can afford a regression suite that runs under Purify to fix memory corruption or leaks.
I know Java 1.5 has generics and C# has some more of C++ features compared to Java, but the matter of fact is that both languages are still tradeoffs compared to C++ in terms of productivity and stability rather than a clear step forward.
I would like to see a language that preserves as many features of C++ as possible while adding garbage collection, memory safety, language-based security and guaranteed binary compatibility between platforms/OSes. I don't think managed C++ is "it". Why can't a VM support multiple inheritence? Any pointers?
Claiming C is dead is plainly stupid. Languages are tools, not religions or whatever. Languages have their weaknesses and their strengths.
Fortran is extremely good for producing high performance number crunching code (it forbids array overlapping, and thus several assumptions can be made by the compiler). C is very low level and I would hardly chose another language when writing an operating system, it is also a fairly general purpose language, good for many things. If I am writing a GUI-app I would surely pick an object oriented language such as C++, Java or Objective-C. If I write a 3d engine, I'd like performance and an object oriented approach and I would chose either C (combined with self discipline) or C++.
The portability of Java and other byte code languages is surely appealing, but they usually produce a terrible user experience since the applications produced tend to have a user interface compliant with the developer's OS (mixed with the language's own HI guidelines). A Java app written by a Windows developer would probably look like a Windows app, even on a Mac, and the other way around. Consistency in user interface is very important I think, so my hope is that people write code according to the MVC principle, and thus ease porting of the application to other platforms. Just to note, I'm not condemning Java, it is a very useful language if you want an internal application that is to be deployed on different systems. Say that the graphics departement (using Macs) and the economics departement (using Windows) both need access to some internal database or application, then clearly Java is the way to go.
Anyway, select your language after the task at hand and write code with discipline!
"Civis Europaeus sum!"
Instead, you guys should look at uClibc - a small, fast, and sleek implemention of glibc, that is finding its way into more and more devices every day.
We are talking about an order of magnitude smaller code footprint here people.
If you want the embedded world to jump on to this bandwagon - uClibc is the only way.
Who's the retard who submitted this?
Well, couple years ago i was really keen on becoming a 100% C++ writer and ditch my C habits entirely.
Due to the nature of most of my projects, like 90% of my time was spent writing wrappers for all sorts of C-style API interfaces.
Finally i gave up and embraced the zen - pick the right tool for the right job. Being proficient with all sorts of tools helps too.
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org Errors found while checking this document as HTML5!
C is a gift from the Gods.
C++ is a gift from the Devil.
The specifications are really quite nice...from what my friend said and the articles I read said...
... it's an early version... it's not ready for prime time... Mono might be the way of the future, Microsoft will NOT be the future.
You get faster compiles because you arn't linking to so many things... less duplication... easier to work on... less learning to have same capability,
easier to optimize a new platform... high level functions offer greater possibility for automatic optimization/ better error checking.
Please use [ informative / summarizing ] SUBJECT LINES
Flame me here
I have been doing Windows development for quite some time now. Both low-level and applications(these days).
.Net C compiler. If you are writing applications its better to use Java or C# anyday. C code does become unmanageable(pun intented) as the project size increases. You need all of encapsulation and inheritance to avoid nightmares of one huge gorilla staring at you!
.Net. But not for anything big.
C will not die becoz,
Most of the real high performance stuff is still written in C. Take Windows drivers for example. The only other option would be C++, but then when it gets down to that level you try to squeeze out every bit of performance. What I have noticed it that when you look at the complexity of writing a Windows device driver, the relative complexity of C versus C++ becomes a non-issue in most cases.
You cant write OS/drivers in bytecodes.
But:
There is no point in a
Maybe i exagerated when i said no point. Maybe for small projects, components that need to interoperate with the rest of
Life is just a conviction.
even in the windows world, i'm still seeing *FAAAR* more c/c++ work than anything else around.
of course, i work in embedded, so i'm not necessarily in a position to judge windows. in my world, C still rules the roost, and probably will for a loooong time.
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
Can I compile the kernel with this Portable.Net stuff? Since the most important thing I can think of that is written in C is the Linux kernel I guess it's a good thing that this Portable.Net stuff is here now C is dying. Otherwise we would never be able to cuild a new kernel, I guess!!
Imagine ... compiling C on an 386 (or arm4 or ppc) , copying it over to an IA-64 and getting all the 64 bit arithmetic pipelines running full speed ..
... and portability
This is a good thing for people who want a Sandbox for C
Guess what language Portable.net is written in
Quidquid latine dictum sit, altum videtur
C# may have a pitiful set of APIs for general work but it is very good for SOAP messaging, particularly "advanced" SOAP work such as messages with WS-Security headers, WS-Addressing for SOAP intermediaries. AFAIK, there's no royalty-free equivalent for Java yet; dunno about the elder languages.
.NET + the MS IDE thingy (Visual Studio?) is good for web services, much better than anything for J2EE that mortals can afford. I've seen demonstrations of coding web services for .NET live, in real time in front of a critical audience and they work.
In general, C# +
Maybe a good mix is C#/.NET for web-service wrapper calling this new C/.NET for business logic?
Imagine getting a NullReferenceException instead of a Segmentation Fault ? ... it's as simple as that
Quidquid latine dictum sit, altum videtur
C code cannot travel. It compiles native code which is by nature unverifiable (none can say if this code is a virus or a new cool calculator)
But compiling C in some verifiable (managed) form where a runtime can verify it, your C app is now capable of travelling, running in OSes or CPUs you never knew at compile time, tested and integrated in applications at runtime (where neither you or target app knew each other at compile or link time).
Anonymous Reports: ... :) :) ... ... pointer security. How do you stop some moron from pushing an arbitrary integer on the stack, popping it as a pointer, and then walking off where he doesn't belong? The answer is the bytecode verifier. :) :)
Chatlog
[04:22] <rhysw> 2 years ago, I was working on a virtual machine that could run C. Like, real C. Not pansy fixed up clean C, but the nasty pointer stuff.
[04:22] <ajmitch> ooh
[04:23] <ajmitch> how well did it work?
[04:23] <rhysw> I called it "Jindalee", after the place where I lived
[04:23] <rhysw> It worked pretty well except for one thing
[04:23] <rhysw> The VM was very efficient, but also *very* funky in its design. Writing a C compiler for it was a total bitch.
[04:24] <rhysw> But now that I have treecc, and 2 years of IL knowledge under the cap, I may be able to dust it off and build a very nice VM.
[04:24] <ajmitch> excellent!
[04:24] <ajmitch> i guess it'll require deep C & CS knowledge to hack on?
[04:25] <rhysw> No more than needed for pnet, actually. The core funky idea is easy enough to understand.
[04:25] <rhysw> Best of all, the entire engine is under 100k in size.
[04:25] <ajmitch> hmm, ok, i should see if i can understand it
[04:25] <rhysw> ok - I'll lay it on you and twist your brain a bit, shall I?
[04:25] <ajmitch> alright
[04:26] <ajmitch> my brain's already fairly twisted from trying to debug & polish this python app
[04:26] <rhysw> Keep in mind that this is the original Jindalee, not the new one
[04:26] <ajmitch> sure
[04:27] <rhysw> VM's like Java have a problem
[04:27] <rhysw> But what if there was no way to do that (push int, pop pointer)? Then there would be no problem, right?
[04:28] <ajmitch> sure..
[04:28] <rhysw> So, I created an engine with two stacks, instead of one. You can push integers on one stack, but only pop pointers from the other. Viola - no way to cast an int to a pointer and circumvent security. And no bytecode verifier needed either.
[04:29] <ajmitch> funky
[04:29] <rhysw> exactly - no one else had done that.
[04:29] <ajmitch> surprising
[04:30] <ajmitch> so how'd code in the vm go interfacing to system libs?
[04:30] <rhysw> it was kinda icky
[04:31] <rhysw> anyway - I may dust it off if I get some time
[04:32] <ajmitch> do so, please!
[04:33] <ajmitch> even if you just put up a tarball of it somewhere
[04:33] <rhysw> it needs a lot of cleaning up first, but it may make an appearance in the near future
[04:33] <ajmitch> you've done some amazing work with pnet, this'd be a great help as well
[04:34] <ajmitch> got any ideas on how to get more coders involved?
[04:37] <rhysw> i wish i did - it would certainly solve my depression problem
Actually it sounds from your own description that you got banned from the project for being an asshole. The fact that you have an axe to grind doesn't lend you much credibility to indict the whole project...
C was last heard saying, " I have already given my best, and I have no regrets at all".
C is a procedural language. .NET is an OO platform. Really using .NET in a C program requires a lot of pointerarithmetic, which will make the C source not that readable.
.NET have to adapt the OO paradigm set for .NET in one way or the other, OR it requires serious compiler efforts (Eiffel) or just plain slow code (creation of objects behind the scenes and then call the method of choice). Finding static methods which do the same as the methods in stdlib and stdio is doable and will work, the real pain begins when a lookalike method of a stdlib or stdio routine is not static in .net, so a whole object has to be created.
.NET language like VB.NET or C#. How is the C program presented to C#? As 1 class with a very big pile of methods?
All languages on
That will not always work in all cases.
And what about interlanguage operability? An assembly in IL can be referenced from any
Never underestimate the relief of true separation of Religion and State.
When I want to solve a program I choose the language I will use, taking into account the abstractions and facilities it offers.
- Convert digital photographs and GPS track logs into annotated photo albums and trip maps
- Examine the availability of 4500 URLs cited in computer science research papers.
- To create the diagrams and the index for my book Code Reading: The Open Source Perspective.
In all the above cases, I needed a typeless language with a rich set of operators, functions, and libraries to minimize the time I would spend to convert my ideas into code. Ruby and Python would have served me equally well.- the *BSD sed implementation.
- The socketpipe zero-overhead network pipe tool.
- The Outwit Windows-Unix shell integration tool suite.
- The fileprune backup file prune utility.
- A device driver for interfacing with my home's alarm system.
In these cases, I did not require any fancy data structures or framework APIs, but I did want tight integration with the underlying system, absolute efficiency, and minimum-fuss portability. For code that will be executed billions of times on tens of thousands of systems, spending some additional effort to provide the absolute efficiency and reasonable portability that are possible in C, is a proposition one should take into account.#include "/dev/tty"
I suspect that when people talk about the popularity of a language fading, they are really talking about the percentage of developers using it.
:)
This doesn't really tell anyone if the number of people using the language has changed. Given the explosion of programmers in recent years, be they professionally trained, or weekend dabblers, it is likely that they are using the current faddy or new languages, like Java, C# or VisualBASIC (not meant as flamebait; I use them myself when engineering requirements suggest them). This for the most part because their emphasis is on making pretty UIs and not any of the more traditional processing or server applications.
This 'explosion' of users with new languages doesn't mean that the old Fortran, Cobol or C applications will immediately be re-written in BoltsN.Nuts or whatever the latest and greatest is. These people will, quite sensibly, plod along with the tried and tested and will probably even continue developing within these skillsets.
The requirements for these skills may well have stayed the same, while the requirement for GUI apps and amateur (some calling themselves professional) developers has increased.
Before anyone can say a language is dying, lets see the figures. For all we know, these dying languages could even be growing (in numbers, if not percentage). Besides which, who should really give a damn?? If it works for you, use it. If it doesn't, but you're not harmed by it, live with the fact that the Borg haven't yet asssimilated us all
"The real question is this: would you rather program against the pitiful number API's that come with C#, or the huge Free Software diversity that you get with C? The death of C has been greatly exaggerated. It will adapt - it always has."
No - that's not the real question; it's: 'Oh no, not yet another C-like language!?'
What's the point, actually? C# is not something new, it's just an attempt to 'get the colour exactly the right shade of pink'. The truth is - C (the language) is precisely what it should be. So perhaps it would be nice to protect the more inept programmers against themselves, but that is simply a question of the runtime- and development environment, or perhaps some improved libraries.
As I always say: a good programmer can write good code in any language, and a bad programmer will not write good code in any language; it's as simple as that, really. This is because good programming is about good coding and debugging practice, both of which are independent of whichever language you use.
...what language are all these VM's written in?
Read the mailing list archives ... there seems to be enough reason to kick this guy...
( I remember Miguel Kicking a guy out of the Mono lists just because he was working with the Portable.net team... IIRC, one the Qt# guys)
It's a common misconception that you need a ton of API's. up to a few years back, I also fell for the DEVStudio GUI builder, the MFC framework, and the libraries that orbit it. After 5 years of trying to get a hold on the beast, I met someone who had stepped back from all frameworks, and went back to ordinary console C and C++. I walked his footsteps, and my apps got reduced to 15% of their original size. Okay, the dummy users needed a few days more to learn the app, but with solid documentation, this was not an issue. And after 2 months, some RealBasic nutcase wrote a GUI wrapper on top of it in 1 week. Perfect !
When will I end this grieving ? When will my future begin ?
you spend too much time in front of a computer screen.,
look.
all slashdot suscribers.
every 45 minutes, get up and walk around.
outside.
don't think you know.
write Montreal.
Love,
robin.
I was just wondering where I could get a C compiler.
I am in the computer engineering program in college and the focus of the program is still C, so until you get the universities to stop supplying new programmers who will want to use C (what they were primarily taught) C is not going to die for quite some time.
Portable.NET 0.6.4 now has a fairly good C compiler that can compile C to IL bytecode... Like C, only slower. ;-)
gcc g++ .. and so on for windows.
Basicly gnu is coming.
Gnu C is being protected from some of the old faults and they create errors. Ie buffer overflows turn up in the complier it is nice fun building a windows program with Gcc when you get past the microsoft difference then code starts turning up faults.
There! It moved!
"would you rather program against the pitiful number API's that come with C#"
.net framework ?
Did this guy at least had a look at the
____
nico
Nico-Live
If the C folks get it together and standardize more than just things like printf(...) and linked lists,
Are there lists of some sort in a standard C library? I could use those in the near future.
C is a brilliant language. It's beautiful and elegant. I don't need validation from any other entity to legitimize the *world's most successful computer language* that most of the major apps on this planet have been written in.
This whole story is a big troll, and if you're not a serious programmer, you wouldn't know it.
Boo hoo... built-in string boundary checking in newer languages. If anything, C is the catalyst for a plethora of invaluable programming habits that today's programmers seem to take for granted.
I know the quote was wrong, and thus the entire discussion is senseless. But still, there are things to say about a language dying: (computer) languages do not die. Period. All of the languages ever invented are still used somewhere. People still use FORTRAN, COBOL, C64 BASIC and all kinds of other weird languages.
Besides, why would one of the most powerful and widely used and known languages (C) die? It is like saying noone uses a normal screwdriver anymore, just because they own a battery-powered one. Sometimes you just use the normal one, because it is easier, faster and it just works.
-- The Internet is a too slow way of doing things, you'd never do without it.
I just started learning C 2 night ago
"exaggerated.\n");
BTW,
I think it is very ontopic to point out the bug fixing policies of pnet/c. I am one of the *few* people who even uses pnetc and one of the *fewer* people who reports bugs on it. It would suprise me if anyone has reported more.
So, My complaint is ontopic, IMHO.
Introspection is the key to understanding
Don't worry, it'll come with time.
Perl is written in C. I wounder what the jit for java is written in.. C++ maybe? Or fear could it be C?
C is small, fast and not as bad as people think.
I used to love C, but then I found something much better: Assembly language; pure and clean machine code. It has lots of advantages:
Michael, Michael, Michael... just as full of sh*t as ever... we both know why you were banned from the project. Does attempted blackmail ring a bell? How about repeated harassment of the developers?
/. folks who you really are, *sshole!
No, bug reports aren't harassment, but I'll tell you what is. Proposing something new, and totally irrelevent to the DotGNU project (as per its stated goals and mission) every ten seconds, then not writing ANY of the code yourself, and finally bitching constantly about none of the DotGNU hackers dropping everything to implement your umpteenth million off the wall idea, is most definitely harassment. You harassed Rhys so much he almost left the project completely just so he wouldn't have to deal with you anymore. It's no wonder he didn't want to deal with your bug reports, no matter how valid they may have been.
By the way, you forgot to mention that you were unbanned from the project. You forgot to mention that, as a result, the ban on you in the #dotgnu irc channel was lifted. You forgot to mention that as soon as you learned of this you joined and then proceeded to spam the #dotgnu channel. Next time why don't you try telling all these nice
Rich
I'm not a C# programmer, but looking at the documentation it looks strikingly similar to java. Is the inclusion of the letter "C" just a marketing gimmick to make C# seem like a C or C++ successor? Seems like that to me. Espically since the non-programmers I talk to are under the impression C# is a C variant.
BTW, can you please post a list of project's you've contributed to. I don't want anyone messing with the memory at AF345F12:BA231DCE on my machine.
Sure, but this helps only if you can assume that those compiled C and C++ binaries are already installed on the user's computer. The main point of "compile once, run anywhere" is to be able to distribute a compiled program that will run anywhere. Of course in DotGNU, we don't define "anywhere" as narrowly as the Microsoft monopolists do:
Unlike Microsoft's C compiler, whose output will only run on i386-based Microsoft Windows systems, our compiler turns portable ANSI C code into a truly portable executable that will run any platform that has a CLR ("Common Language Runtime"), regardless whether the system is 32-bit or 64-bit, little-endian or big.
Or is it because of some form of hatred towards C#
No. It's because there's a lot of C code out there that people might want to use from C# and other modern languages. Throwing that C code away and re-implementing in another language would be a waste of time.
ahem Michael..please note the difference between applications in bytecode lanaguages and OS components in non bytecode languages..you might appear more intelligent than your current post..
./ actually think!!!
Will someone at
Don't Tread on OpenSource
I really don't think C is dead. I've been working with C language since 1994 in Unix environment and it is a natural language to write applications to that environment. I feel that byte code languages are really cool but I believe that there is still a lot of work to be done in the interpreters.
Ronaldo Faria Lima
E-mail:ronaldo@ronaldolima.eti.br
Home page: http://www.ronaldolima.eti.br
"Most of the times, these libraries are not cross platform"
Well, duh, the claim is c++ is portible not "all libraries that c++ uses are portable"
Having said that I would say that there are degrees of cross-platform-ness. Java being much closer to the ideal than c++.
This thread is about the C support for DotGNU Portable.NET. When Miguel saw the original code from Rhys, long before Mono existed, he said something along the lines of "wow, you're way ahead of me", as was to be expected, since Rhys was already an experienced compiler hacker. Several months later, after Miguel had started Mono, when (one-sided) attempts at cooperation were made, he basically told Rhys that his code was worthless (Rhys was living off his savings so he could work full-time hacking on a Free Software project, and Miguel knew this... hence, Miguel is an *sshole in my book). After repeated attempts at cooperation were shot down due to the hostility coming from the Mono camp, Mono's PR Blitzkrieg caused this very sad state of affairs, where you say "Mono might be the way of the future" in a thread about DotGNU Portable.NET.
DotGNU Portable.NET is still going strong, despite a serious lack of much-needed volunteers. With as much as 1/100th the number of volunteers, DotGNU Portable.NET has managed to not only stay in the running, but to lead in important areas like portability, C->IL support, and C#->JVM support. Unlike Mono, DotGNU will never pay MS for licensing if they try to enforce any of their api patents. Simply by setting a configure option when building the pnet C# library, you can remove those parts of the library which are not safe from MS patents. Additionally, the alternative api development project (still in skunkworks on the design phase) will provide a patent-safe Free(dom) Software (and much better designed) alternative to the MS apis for managed code to use.
DotGNU is the GNU project's answer to the need for Free(dom) Software for webservices, and DotGNU Portable.NET plays an important role in that effort. DotGNU Portable.NET provides a portable, compatible, runtime and library to make migration away from MS.NET reasonably easy. The C support makes it easier for Free(dom) Software hackers to use existing Free(dom) Software in their managed code applications and libraries. Ximian's just trying to make money, and if ethics gets in the way of that, ethics goes out the window. Mono is most definitely not the future; DotGNU, however, is.
Rich
Uh, you can't run bytecode on a raw machine. /.
Yes you can. There are several java-bytecode hardware microprocessors.
C and Assembler are what make the computer world run.
false. C and assembler are 20%-100% faster to execute, but 1000%-10000% slower to develop in.
You can't make Java in Java.
Yes you can. *and* you can make csc in c# (see here)
C turns directly into executable binary (or object files then linked into executables). Java cannot.
Look up gcj.
I suppose that if you were insane enough, you could make a bytecode to opcode converter, but then you lose 100% of the point of the langauge, probably a lot of the efficiency, and at that point you may as well use C.
As we were in the subject of python, look up psyco.
Man, this is the highest density of crap in the same paragraph I have ever read in
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
It's like comparing the importance of your spinal cord to the importance of your kidneys. They both kick ass and serve a particular purpose; in many cases they complement each other wonderfully. And let's not forget that Python and Java both use C as an extending languge.
Way to completely miss the point of language independence.
I am very small, utmostly microscopic.
C++ is perfectly portable if you don't use platform dependent libraries. You seem to be blaming the language because people develop platform dependent stuff for it! If your goal is to port stuff to another platform then obviously you start off with that in mind.
There's plenty of platform dependent Java code out there, or stuff that doesn't port properly.
In this world nothing is certain but death, taxes and flawed car analogies.
C's only strengths are speed and easy access to hardware.
String boundary checking SHOULD be a feature of any modern language -- or do you enjoy buffer overflow exploits?
There was a programming language called B. Anyone still use that?
In this world nothing is certain but death, taxes and flawed car analogies.
It's nice to see that some programmers can approach issues like this one without resorting to intelligence-sapping extremism. I wish I had a mod-point for ya.
You're right. C# is Java with some relatively minor changes. I think that C# is an improvement over Java, but whether the improvements are significant enough to really justify what MS has done, to fork out a new language, that is certainly debatable.
However whether C# is new or not, and whether it's an improvement or not isn't really relevant. What matters is that we need to make it easy for app developers to create portable apps which will run not only on the Microsoft Windows system but really anywhere. That's what the word "portable" in "DotGNU Portable.NET" stands for.
On the one hand, the article here is misleading. The slashdot news story it cites claims 'c' is dying, but the article that news story cites does not. So the cited story got twisted on slashdot.
So now we have a new slashdot story running with the mistake...
The majority of CPUs in today's world are not running desktops.
Things with C
Linux
compilers
Automotive
engine controllers
ABS controllers
Airbag controllers
Memory seat controllers
etc...
Calculators
desktop BIOS and chipsets
Cell phones
etc...
Most code written to run on the hardware is written in C. So the contention being refuted is faulty in the first place.
C# whips the tar off of Java (and most non-optimized C code) in most benchmarks. Why? Because it's running on Windows only for these benchmarks. Anyone remember IIS running faster than Apache because of MS taking advantadge of undocumented platform APIs?
Do you think C# on Linux/BSD/*nix is going to be near as fast as C# on Windows? Think again. It may eventually catch up, but not before it gets a reputation for being dog slow. (See Java as an example).
C is really fast. If you know how to optimize it, nothing can beat it (except assember or some special Fortran routines, if it works for you project). If you ~don't~ know how to optimize C really well, Java (anywhere) and C# (on Win32) can be as fast or faster. Usually is much faster, these days.
Java runs, with very little effort, on every major OS and platform out there. (And yes, I do this for a living). I work at SAS (http://www.sas.com) and we ship the same codebase on Win32, HP-UX, HPi, Linux, Solaris, AIX, etc. The advances in the Just In Time compilers has made a huge difference in performance. (There are some differences in the major J2EE environments, but even that is addressable and minor compared to an entire product port).
Yes, it's still true that a programming guru can write some smoking C code, but Joe Sixpack Programmer usually can't beat Java's performance. And yes, I'm talking big number crunching. At a prior job (at a biotech), we crunched Big Numbers (two month runs on a grid of machines) and Java did a very respectable job. We spent our time improving algorythms (from a bio point of view, not a C/ASM point of view).
The C#/Mono crowd is spending a lot of mindshare in making sure that MS's latest language will run anywhere, and that's great. I am glad they are doing it and applaud the effort.
But Java is far and away the fastest true cross platform language out there right now. It's got the best cross platform enterprise environments available. If you are looking the most speed ~and~ portability, the King isn't dead yet. :)
Agile Artisans
I learn up on C. All my text books have to say about pointers to void is: "Don't do it. No self-respecting person would half-ass their way through a problem with a hack like that. It's so bad, this is all we're going to say on it."
Looking at code in the real world.... Well that's something totally different. It's like getting out of kindergarden armed with the certainty that people would never lie, because it's wrong, and walking into the world championship of poker. Because void * might not be every bit as common as bluffing in poker, it's not far off.
The article is referring to the recent claim that Miguel said that "C is dead". The problem is that it's quoted out of context and is getting rehashed so much that people are gonna forget that it was never actually said.
This article implies a great deal, but the reality is that Miguel never said C was dead. He said that to him C was dead, meaning that he intended to focus his programming time on C#. Pretty reasonable statement given that he's in charge of a project that's porting it to linux.
Surprisingly to the language zealots among us, Miguel is allowed to write code in whatever language pleases him.
-Tom
Having seen side by side comparisons of J#, C# & VB running on
* C is mature and stable. Yup, there are some bad design decisions, but using C isn't quite like riding the current version of Java -- new idea, whoops, let's change that, oh wait, let's extend that...
* There are good development tools for C. There is a good set of tools that have been built up over the years for analyzing and debugging C.
* C doesn't impose a lot of resource overhead. I'm all for having safe languages, but Java is just plain fat when it comes to memory usage, and encourages a lot of practices (like rapid destruction and creation of objects) that tends to cause a serious CPU hit as well. Safe and *efficient* languages have, as a general rule, flopped in the marketplace.
* C runs on everything. There are awfully few platforms for which there isn't a C compiler.
There are a lot of Java apps out there. Yet, in my day-to-day use of my computer, I don't use a single Java-based program. Not one. I use a small number of perl and python scripts, a couple of bash scripts, and a vast quantity of C code. The C alternatives are faster and more memory-efficient. Plus, I've tended to come to believe that the average Java programmer experience level is lower than than of the average C programmer (simply because lots of Java people *started* coding with Java which puts an upper bound on experience).
I admit that Java can be neat for some things (rapid application development/prototyping, lightweight distributed and network-using apps). It's generally not the sort of thing that sits on my desktop, though.
It may be that more Java code is written each day now than C code, but since so much Java development is vertical market or custom development, I suspect that the overwhelming majority of lines of code *used* by people is C.
May we never see th
I didnot know the existence of the dotGNU project till this post. Whereas Mono had been relatively well known. Going through the project page, the first reaction I had, was that there is no clear boundaries about where dotGNU ends and Mono starts (or otherwise). For example, both dotGNU and Mono have a C# compiler. Now how would a future contributor decide on which one to contribute for ?I think it would be very good for both the projects if they could have a simple explaination about what they are trying to accomplish and where (and how) they differ from each other.
Even Windows is still programmed best in C / C++ for shareware applications.
This is my sig.
"Saying C will be killed by a runtime architecture is like saying too many busses will eliminate sports cars" ...in the world of mass transportation.
Take the quote in context, and it actually makes sense.
Insightful? Insightful because you didn't read the original quote, which was completely misquoted, and completely taken out of context.
Jason Lotito
In fact, there are a lot of differences. Mono works fast on i386 and slow on * else - pnet works ~equal (but slower than mono in i386) on all platforms. Mono's c# compiler is written in c# and P.Net one is written in C. Mono is going to have python compiler, P.Net have C compiler. Mono uses GTK# bindings for gui and going to use wine for System.Windows.Forms - will be very compatible with MS but not portable or reliable. P.Net use portable (now windows and X) System.Windows.Forms, but it may be not that compatible with windows, using-native-code apps. There are a lot more of differences. And imagine, if you want to contrigute such project, you are going to be familliar with those things and even small differences may make huge difference to you.
Also, if you want protabe C++ code, all you have to do is draw a firm line in your design between platform specfic and the rest of your code.
Free Mac Mini Yeah, it's
Ok, so I think the writing on the wall reads, "M$ will be requiring code to run through the .NET CLR", if it is to run on Windows.
.NET app? [Ruby was on my mind]
So, in response, we have C compiling to bytecode. But, Longhorn will require bytecode assemblies to be signed; I suppose that could be built into the compiler as well (else wouldn't we lose portability?)
I was thinking along these lines a while back, and thought to myself, "What's to stop somebody from writing an interpreter for any language (I was thinking scripting at the time) that will run as a
What's the impact of doing this, you ask? Well, if the interpreter itself is the signed certificate-backed secure executable, then any little scriptlet or homebrew app could be run without being digitally signed!
To me that allows a fairly obvious circumvention of Palladium, and "trustworthy computing" is out the door.
Flat C code can be packaged into a DLL, C++ code can be made either a COM component for interop or it can be made into a mixed mode assembly module with a proxy clsss. Next.
lazy coder alert.
What? C is not dead because it now supports what? Most people I know have never heard about that "il" things you are mentioning. I assume this is related to .NET... ah, whatever, another moronic article on Slashdot.
I passed the Turing test.
That was a lucid explaination, but what you are missing out is that there are so many implementations of the same thing. It is almost like that people have gone crazy about the specification from Microsoft (this is a rarity in the usually anti-Microsoft open source world). Would it not make more sense if the requirements and the specs are clearly marked out and both the parties decide whether (for eg.,) to do the drawing yourself (as in dotGNU) or rely on other libs(winelib or GTK#) for Mono.
I would say the same about C++ and wxWindows.
As soon as I learned it, I did throw Java out the window.
Compared to Java, C++ is fast as hell!!
We are Turing O-Machines. The Oracle is out there.
Erm, just compile the C code to a shared library, load it into the .NET runtime and interact with it via the P/Invoke machinery. You've never had to compile C to IL in order to run it from .NET.
.NET you'll find that it's mostly just a set of wrappers around the standard Win32 DLLs.
If you look closely at Microsoft
Check out LLVM: http://llvm.cs.uiuc.edu/
:)
It gives the advantages of bytecode compilation (linktime & runtime optimization, JIT compilers, etc) to both C and C++ (using the GCC parsers). In addition it has a powerful interprocedural optimizer, so it generates code that truely thwomps GCC in some cases.
-Chris
Although it's not used by pixar.
We are Turing O-Machines. The Oracle is out there.
would you rather program against the pitiful number API's that come with C#
.NET CLR bytecode (thanks once again for showing your complete ignorance of .NET)...I have written a lot of .NET apps and have yet to find myself needing some functionality not already provided somewhere in the .NET class library. It is (by far) the richest set of application APIs I have ever developed with.
Completely ignoring the fact that no APIs could "come with" C# because C# is just a one of many languages that compiles to
C ?
sure; they both have compiler, bytecode interpreter/jit and class library which are different implementation of one thing. You're right about drawing yourself/relying on other libs. and i guess, they made crazy on specifications because free software still does not have java-alternative, and this was a good chance of getting one.
"An unhandled exception prints a nice stack trace to stderr which makes it easier for you to figure out what went wrong. "
Dr Watson does this.
Only some poor fools in the windows community, and some hopelessly insane Mono developers, along with a cadre of self-styled software journalists and gurus, believe that
11*43+456^2
I used to keep a magic JCL deck in my desk at work. I didn't understand what was written/punched on it. I just knew that it had the right incantations to make my batch jobs run on the center's 360.
Mea navis aericumbens anguillis abundat
Exactly.
My experience has been that the people who are saying "C is dying/dead" don't do any low-level or back end programming.
What's happening is that languages such as Java, C#, and Python are taking over the front-end design because they can be quickly prototypes, but there are still areas where you need speed and efficiency--that's where C comes in.
Starting many projects in C is premature optimization, but there are some where C is just the Right Language(TM) and I don't think that will change in the near future.
Then, of course, we could discuss how Objective-C is alive and well, or how the optimization step for Python is to write the code in C...
Integrate Keynote and LaTeX
Yes C++ as a language has compilers for many platforms which are pretty much compatible, but the degree of compatibility of these compilers don't mean much since the compatibility of an application is a totally different story. An application written in C++ will be using some kind of library, for DB access, for GUI, for network operations etc... Most of the times, these libraries are not cross platform.
Well, they are cross-platform if you are writing a cross-platform application, and they are not cross-platform if you don't.
Furthermore, the kind of cross-platform compatibility people primarily worry about with C++ is for libraries: it is things like regexp libraries or XML libraries that are going to be reused across platforms; GUI and I/O parts of applications are best developed in a platform-specific manner.
Or they have to be extended with platform spesific code.
For some reason, Java marketing has created the notion that cross-platform development matters a great deal, but that is nonsense. Cross-platform development (and sandboxing) matters for browser applets, a market that Java has largely ceded to Flash. For desktop applications and server-side applications, cross-platform applications don't matter at all.
Writing in a cross-platform toolkit and adding a small amount of platform-specific code is actually far superior to the 100% cross-platform approach: it is nearly as easy to port the application between platforms, but the application becomes enormously more usable by following platform-specific conventions and offering platform-specific functionality.
What it comes down to is that C++ is a better language than Java for cross-platform development. C# may eventually supplant C++ in that regard, because C# is simpler and safer, but still offers C++'s access to platform-specific features. But Java's religious insistence on what they incorrectly call "cross-platform" support actually is counterproductive.
IMHO, java is really successfull in cross platform software development, without much work i can make java software work on another platform. If C# had the same future, i'd be really glad, since i like it too,
.NET libraries. But Java's cross-platform support is really not very good: Linux is a second class citizen.
.NET compatibility, you get an independent set of OSS APIs based on Gnome. If you use those, you are creating native Gnome applications. But because Gnome also runs on Windows and OS X, you also get cross-platform support for those applications.
.NET, which works better on Windows but runs on Linux, and Gtk#, which works better on Linux but runs on Windows. The official Java platform only gives you one choice, Swing, which doesn't really integrate perfectly with the desktop on any platform and whose implementation shows a strong bias towards Windows.
.NET i just don't believe MONO guys can keep up with it. C# 2.0 and longhorn will be a huge step forward for .NET technologies, and i don't thinkk MONO team can find resources to keep up with MS.
First of all, Mono isn't trying to achieve Java-style cross-platform support--many of the people working on, and using, Mono have rejected Java because they don't like Java's cross-platform strategy.
In the end, Mono will probably give you cross-platform functionality no worse than Java's, through its
With Mono, in addition to its
In different words, Mono gives you two cross-platform choices:
but as Microsoft works harder and harder on
Microsoft has to be pretty open about the features that come in C# 2.0 and Longhorn. And the way it looks today, OSS will be supporting those features before Microsoft even releases their products.
So when does C++++ (or C+4,C4+ come out?).
Fly me to the moon Let me sing among those stars Let me see what spring is like On jupiter and mars
The problem with C don't go away by supporting it on .NET. The problem with C is its type system and runtime, which are full of holes. One consequence of this is the large number of security problems that C-based system software has (e.g., caused by buffer overflows).
.NET won't fix its problems because its problems are deeply encoded in the language definition and in the programming practices of millions of C programmers who keep grinding out unportable code that happens to work most of the time on the platform they are using.
Unfortunately, those problems aren't fixable with better implementations. We have had safe, error-checking C compilers for many years. The problem is that they impose a significant runtime overhead because C semantics make it unnecessarily hard to do error checking (contrary to C mythology, the flexibility of pointers doesn't buy you anything in performance or expressivitiy). Worse yet, they expose the fact that many C programs rely on unportable or undefined features of the C language.
C isn't dying and it won't be dying. But it should. And, sadly, supporting C on
You are obviously a troll. The 286 does not have a pipeline, idiot. The 80386 was the first Intel processor to use pipelining, but it was severly limited, and was only 5 stages. The i486 was the first Intel processor to really use full-blown pipelining, and was able to execute some instructions in a single clock cycle.
Look here
I'm not a big fan of C#, but I think we should let C die for application development. It just makes you write too much code, has questionable performance benefits, and is ripe with security problems.
I am excited about the CLI, though, because it means I will be able to write "native" code in any number of much better languages!
write a comiler which translates IL to ANSI C? At which point .net would be truly cross platform. Or is this too simplistic? I know that Eiffel compiles to C which can then be compiled using gcc, which runs on many if not most platforms.
THoughts on this?
putting the 'B' in LGBTQ+
Why keep C on life support? C was designed for computing in an era when every
byte mattered and you would store some numbers in 16 bits and others in 32,
depending on how large they would probably get, an era when you would manually
allocate each piece of memory and free it when you were done because you didn't
want to have any allocated that you didn't need, not even until the end of a
block of code, an era when CPU time was so precious that garbage collection
was considered expensive and wasteful, an era when, in short, the computer's
resources were so valuable that you would spend programmer time willy nilly to
conserve them. It's an anachronism, a language that *needs* to fall into
disuse (except for a few inherently low-level tasks like writing bootloaders
and kernels), and the sooner the better. Portability is not the language's
only (or even its most important) weakness! Do you really want to continue
to have to comb your application source for every single malloc and hunt down
the corresponding free, to doublecheck every buffer to make sure you've
checked its bounds every time you read or copy anything into it, and to write
pages and pages of code where a paragraph would get the job done in a more
modern language? Do you really want to have to continue to construct simple
structures like lists *by hand* using pointers, when in other languages
they're a fundamental data type? (Yes, there are libraries now to handle
some of these things, sort-of, but the language just isn't geared that way;
it's geared toward low-level bit-fiddling and going through the programmer's
time like water in order to conserve the computer's resources.)
I know you have fond memories of the language, and surely it was good in its
time, but its time has come -- and gone. Sooner or later you've got to let
it go. Say a nice eulogy and let's get on with our lives now.
Cut that out, or I will ship you to Norilsk in a box.
I've been reading through this post and one thing irritates me. Everyone is acting like C has no garbage collection facilities. While garbage collection is not built into the language, there are several garbage collection libraries that can be linked into C. In fact, most of them merely replace malloc with some garbage collection code and replace free with a do-nothing routine. Linking the garbage collection libraries into the C code automagically sets up garbage collection and will allow you to recompile existing code with garbage collection enabled. Here's a sample library (first result searching 'garbage collector c' in Google):
http://www.hpl.hp.com/personal/Hans_Boehm/gc/
;-) Great comeback.
Why the heck would I want to compile the great and venerable C language down to a script that only runs on the Evil Empires OS?
It took less than twelve weeks for myself and 2 others to write a compiler that would compile C into a JAVA class file. It was a fairly complete representation of the basic language and worked pretty well (ok it's a school project, but still). There's got to be some professional compiler people that have done this too. Of course C is so portable to begin with (when written well) why bother. Just compile it again.
swig
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
Nothing is static. That was my complaint about the standard C library. It is static... stagnant... showing its age.
.NET fixes many of those warts.
This does not diminish the fact that AWT was the first Java GUI API. It had limitations. It was redesigned to be truly cross-platform and dubbed Swing. As far as the API is concerned, I happen to like the Swing library. Is it "THE ONE TRUE GUI API?" Of course not. Nothing is or ever will be. It was the best they could come up with at the time. Now, when someone learns the standard Java GUI API (or just about any other Java API for that matter), they can transfer those skills to other Java projects much more easily than C coders can in C projects.
SWT? A nice start. It is not as complete, does not run on as many platforms, nor is as widely used as Swing. But it shows promise. In five more years, who knows? That's the point. Right now, there is a standard API that everyone knows and other APIs (that aren't drastically different from the AWT/Swing API by the way) being tried out to find better ways of doing things.
Mono's choice of GTK# is in my opinion a bad move. It's also unfortunate that Microsoft hasn't opened up the APIs for the Windows GUI libraries. I understand their reasons for doing it (Microsoft patent threats), but the culture of C is too strong. Instead of writing a new, GUI toolkit agnostic interface API, they intimately tied it GTK.
C and the programming culture it fosters is building on sand; New APIs are constantly (and in my opinion, unnecessarily) being written all of the time, but there's no common base for others to work on nor to use as a base API design reference. Imagine how much more software would be written if folks didn't have to battle over GTK/Qt, MySQL/PostgreSQL/ODBC client libraries, ALSA/OSS, etc.? Would it be so terrible to tell people, "OpenGL is the standard API interface for 2D graphics in C. How you implement the OpenGL layer is up to you, but use the standard header files so that people can just recompile/relink to use a different implementation.
Don't think it's necessary? Let's look at the history of UNIX, the original C program. The API wasn't standardized and set in stone. Different vendors went their own way in an attempt to lock the others out of their turf. UNIX programs commonly became a mess of #ifdef statements. The Windows came in touting a common API for Windows with COM. Any language (well, the common ones... VB, C, C++, etc.) could use these objects. They had a well-defined API. New implementations (eg. Perl for Windows) could be modified to access these objects as well. It didn't matter what language the COM object was written in. It didn't matter what language you were using. Write to the interface and be done with it. COM had warts. Everything does.
The C community on the other hand just sticks its head in the sand and collectively says, "Look! They didn't do it perfectly. They suck! We rule!"
The C community should be saying, "Look! None of us did it perfectly. Let's make our baby better by taking some of their good ideas and incorporating a bunch of our own."
Mono and Java have warts, but at least they're trying. What's C got show for thirty years? Variable length arrays in function declarations? That is the best thing anyone could come up with for C99? Hey folks! There's an elephant in the corner! It's name is "incomplete standard library." I know no one wants to talk about it, but it's there and taking up too much space at the party!
- I don't need to go outside, my CRT tan'll do me just fine.
C++ is very portable if you choose compilers and libraries that are standards compliant and portable, which is now easy.
VC 7.1 (finally), GCC 3.2, the new Intel compiler - these are all very compliant with the standard. And remember that GCC, though not yet well optimized, runs almost everywhere.
The C++ Standard Library, the boost libraries, wxWindows, Qt, + 100 other libraries are all cross-platform.
Now compare this to the huge amount of work required to 'port' #develop from Windows to Mono.
All that's missing with C++ is a processor independent intermediate code, and that's coming in GCC 4. It's called LLVM.
Tom.
Didn't you RTFA? The topic is Portable.Net which works on more platforms than Mono does.
It is now official - Netcraft has confirmed: C is dying Yet another crippling bombshell hit the beleaguered C community when recently IDC confirmed that C accounts for less than a fraction of 1 percent of all languages. Coming on the heels of the latest Netcraft survey which plainly states that C has lost more market share, this news serves to reinforce what we've known all along. C is collapsing in complete disarray, as fittingly exemplified by failing dead last [samag.com] in the recent Sys Admin comprehensive networking test.
You don't need to be a Kreskin [amazingkreskin.com] to predict C's future. The hand writing is on the wall: C faces a bleak future. In fact there won't be any future at all for C because C is dying. Things are looking very bad for C. As many of us are already aware, C continues to lose market share. Red ink flows like a river of blood. FreeC is the most endangered of them all, having lost 93% of its core developers.
Let's keep to the facts and look at the numbers.
OpenC leader Theo states that there are 7000 users of OpenC. How many users of NetC are there? Let's see. The number of OpenC versus NetC posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetC users. C/OS posts on Usenet are about half of the volume of NetC posts. Therefore there are about 700 users of C/OS. A recent article put FreeC at about 80 percent of the C market. Therefore there are (7000+1400+700)*4 = 36400 FreeC users. This is consistent with the number of FreeC Usenet posts.
Due to the troubles of Walnut Creek, abysmal sales and so on, FreeC went out of business and was taken over by CI who sell another troubled OS. Now CI is also dead, its corpse turned over to yet another charnel house.
All major surveys show that C has steadily declined in market share. C is very sick and its long term survival prospects are very dim. If C is to survive at all it will be among OS hobbyist dabblers. C continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, C is dead.
Fact: C is dead
Sigs? We don't need no stinking sigs!
I'm sorry, I assumed he was referring to the x86 platform, which obviates many of your points. Then, I was referring to the initial creation of the language. If Java doesn't exist, you can't make it in itself. The first Java compiler was written in C most likely. I didn't know about gcj, so my fault there. And your last comment and subject line make you a cock. If you ever said that to my face you would be eating your own endtrails in a sort of "comically macabe" way
Slashdot is proof that Sturgeon's Law applies to mankind.
"The real question is this: would you rather program against the pitiful number API's that come with C#, or the huge Free Software diversity that you get with C?"
.NET in the name of the software shouldn't it follow the .NET way? That means no matter what language it is programmed in you can make use of it with another language?
.Net idea (yes I know MS probably wont go around supporting other systems with .Net but they have advertised its cross platform abilities. Another reason why I don't think they will mess with Mono and other such projects.)
.Net will fail in linux. Why? because Microsoft invented it. Thats the only reason. But there is a solution coming along that will probably be accepted by the linux community. perl6 and the parrot engine. From what I have read about the parrot engine, it works almost just lile .Net. Can run any language (After being adapted of course), has a Intermediate Language (its own ASM, like MSIL). Any language can use any libraries in any other language coded for it. I like this technology and it would be great to program for linux no matter what language you want to use.
well, with
That statement is made incorrect if it is not possible to use the C coded libraries from C#.
However, they can (and probably are) be refering to communicating with libraries on the local system written in C. In that case, you can still use the libraries from C# you just have to import them in a "Special" way. Almost the same as making your own headers for the library. Whereas with the C version you migt be able to just use it because the header already exists. This problem has been around with using any library with any other language, so nothing new. Microsoft has done it this way with C++.NET. C++.Net can interface with libraries with little effort.
The solution? Just make a wrapper library in C.Net and use it from C#.Net. Better yet, reproduce the library entirely in the managed language. Linking to outside libraries causes platform dependancy and kinda kills the point of the whole
What I predict:
For 87 cents a day, you can buy a poor /.er a dictionary
How much does it cost to make him use it?
It sounds like you haven't done much server-side web development. One big benefit of Java is that you can write and package applications that will run on multiple server platforms with virtually no modification. For real companies this is a substantial benefit; it means that you aren't locked into a single vendor for your infrastructure.
The absolute best you can hope for with C++ is the ability to recompile successfully on a different server. If the developers actually have access to your platform then you have a chance that their packaging will compile successfully; but this has not been my experience. And since the number of cross-platform libraries is limited a lot of wheels have to be re-invented.
when you post as AC, and it gets modded up?
Best Slashdot Co
... of using it to cleanup things like sockets and files? Could be a huge clean up of my Java code if it works.
I always post as AC.
I like the aesthetic of the voice from the void. The only information it carries with it is its message.
Plus, it's trivial to dribble out stuff that gets modded to +5 when you can start at +2. As an AC, even having something you think worthwhile isn't enough. Their's timing and positioning to consider.
Then there is the positive reinforcement factor. If people see stuff as modded up +5, that's also decent, from an AC, they might be more likely to browse AC's when they're modderating. Which might slightly increase the variance of popular ideology in this venue.
Anonymous isn't just for cowards anymore.
Is that why Unix is so far behind Windows in usability?
Seriously, though: the Unix philosophy emphasises little modular tools over monolithic applications, right? Shouldn't one of the chief advantages of this be that small, non-speed-critical apps can be written in high-level languages? But for some reason just because all the innards and libraries are written in C/C++ (as they should be), many open source coders decide that they should write applications running on top of those innards in the same languages.
Look, just because GTK is written in C, doesn't mean all the Gnome applets need to be! Same goes for Qt and C++. Hell, even Perl would be better! I'm tired of trivial apps causing memory faults. If it were written in a high-level language, I could just go in and fix the errors without having to wade through all this function redirection and reinvention of wheels.
I thought the open source community was supposed to like scripting languages? What's wrong with you guys?
Crush seems to have an awful lot of overhead for an OS language.
Oh, I see that it has unsafe pointers for when you want to avoid garbage collection, right? But wait, doesn't that make it an unsafe language?
And it's nice that you can switch between dynamic and static typing, because I sure as hell wouldn't want type inference in my kernel, but can the safety checks be done statically? I guess not, that'd be undecidable, right?
If Crush has "no primitive types or constructs", what's this "raw core" the Introduction talks about?
Do these guys actually have any idea what they're doing? Designing a modern programming language and designing an operating system are both monumental tasks. I hope they're at least having fun...
0. "I assumed he was referring to the x86 platform"... see #4, below. ... c#. And it compiles itself. Take a look and you'll see what I am talking about. ...); .NET bytecode (like IKVM does) you did *not* lose the point of Java. you just translated your abstractions to another platform.
1. Bootstraping. The c# compiler in Mono is written in
2. Your argument: "the first Java compiler." Tell you what: sometimes, the first XXX compiler is written in XXX and bootstraps itself. Even some of the first C compilers were written in C. Many assemblers before it were written in assembly language.
2a. the word bootstrap comes from "lifting onself by steping on it's own boot straps." magic, eh?
3. (Shrek citation) you and what army? (/Shrek) I was being caustic; you are mentioning being violent. I can dance the dance, too. Just invite me and we'll tango.
4. ok, so I'll take the discussion again, this time from the beginning, let's see if we understand each ohter.
4a. bangular complained that many modern languages were either scripting (like perl or python) or bytecode languages, so you could not write an OS kernel in it (unlike C, C++,
4b. Ambassador Kosh pointed out that python also is a bytecode-language (and altough he did not mention it, perl is a bytecode-language, too)
4c. you said (assuming he [Kosh?] was talking about x86) bytecode could not run in raw machines ; yes it can't run directly in a x86 machine, but it can run in a specialized processor; but -- a JIT compiler, or an AOT (ahead-of-time) compiler (like gcj) can compile bytecode into machine code easily. You have to remember bytecode is just another representation (direct translation) of (some) assembly language.
5. Here starts you succession of mistakes, that lead to my header and footer in the response I wrote:
5a. you wrote "C and Assembler are what make the computer world run". nope. engineering make the computer world run. many applications are still in COBOL, FORTRAN, and lots of it, today is in Java, etc. Down to the wire level, yeah, there is lots of C and assembler, but they are *not* cost-viable to make many commercial systems. just OS-level software (database management systems, etc). And some are not -- SAP DB is written in Pascal; many MacOS programs were, too,...
5b. you wrote "You can't make Java in Java". bootstraping. bootstraping.
5c. you wrote "C turns directly into executable binary (...). Java cannot". wrong.
5d. you wrote "I suppose that if you were insane enough, you could make a bytecode to opcode converter"... no need to be insane; see what's done at transmeta, ikvm, any JIT compiler, etc. etc...
5e. you continued "but then you lose 100% of the point of the langauge" (sic). wrong, the point of a programming language is to show some abstraction in a clear way. p. ex, C++ classes show the abstraction of classes of real-world objects and the operations that can be effected in those objects belonging to those classes... if you translate it into bytecode, machine language *or* database-description to generate some tables in a RDBMS, it's not differente because of the target language; you did not lose the "point" of C++. So, if you get some JVM bytecode and translate it into
5f. you went on "probably" (lose) "a lot of the efficiency", yeah, some of the efficiency, maybe; but you gain other knowledge that you can use to profile-and-optimize better than any hand-optimization. This will absorb most of the cost of the translation, and, in some cases, the dynamic translation techniques can make your program run even *faster* than the native/compiled version!
5g. you ended the phrase with "and at that point you may as well use C". no, you may not, because C is not *very good* at OOP, or functional programming, or whatever other paradigm you need to express the domain of your problem so a compiler can give you an efficient program to run as a response.
6. as you see, from 5a to 5g, you said seven distinct things in your paragraph, all wrong, all in need
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
New England Speak is a wicked pissah!
Anjoo lef' out Brooklyn?!? Wutthufawk? I mean, fuhhhgeddabowdit!
Downmodding is the refuge of the weak. Don't downmod, make a better argument!
This is precisely the kind of thing that separates computer science, that division of mathematics that deals with algorithms and computational theory, from engineering which deals with real-world solutions to real-world implementation problems.
If you think that implementing a program in lisp is going to be so inherently secure that there is no need for hardware-level page protection, you are sorely mistaken. Malicious code exists, even in Lisp.
Outside of C and assembly, nothing is comparable for speed. If you're seeing similar execution times from lisp and Java, then you're doing something so trivial as to be uninteresting or something is wrong with your C implementation.
-Hope
The actual "C" language may be declining in use. However, every single one of the "replacement" languages I've seen mentioned are simply "[subjectively] improved" modifications of C. Personally, I rarely use the higher level versions of C like C# or Java, because my line of work requires me to interface with OpenGL and do very CPU intensive calculations. Pointer math is absolutely required to effectively utilize OpenGL's more advanced extensions such as vertex buffer objects. And you can just forget about optimizing your vector math for CPU vectorization and parallelization, etc... in languages like Java or C#. This is not to say, however, Java and C# do not have their own benefits. When you need to write a small application (perhaps a frontend, or what not) and performance is not important, it's often faster to develop them in a higher level language. It's another instance of "the right tool for the right job". But the low level versions of C won't be dying for a very long time, because there will always be a need for portable, high performance APIs. The APIs that your high level C languages may interface with to perform tasks you simply can't practically accomplish otherwise. And of course the actual system kernel that everything runs would never be practical in a high level language.
The GPL does not grant you patent rights to third
party patents which is what you are implying there.
DotGNU is in no way in any safer ground than Mono
is when it comes to patent infringement. If they
say `you have to pay for our patents' if they have
a case, you will either have to pay or withdraw
your code from the network.
No ammount of GPL can give you rights to someone
else's property. Otherwise fighting patents
would just be a matter of writing a GPL implementation
of the technology in case.
If the Free Software Foundation is fighting
patents that strongly, why did they not fight the
Gzip patent? Or what about the crypto patents?
Or the freetype ones?
http://www.gnu.org/philosophy/gif.html
Instead they played like everyone else:
avoiding patents whenever possible.
You are missleading people with your half-truths.
That's right, because DLLs and COM are platform independant, right? DLLs feel just as at home on Solaris SPARC as they do on AIX as on Microsoft Windows, right?
Actually, there are some very efficient OCaml implementations out there, on par with C. But don't take my word for it...
pb Reply or e-mail; don't vaguely moderate.
Patient: Doctor! It hurts when I stick my finger in my eye.
Doctor: Don't stick your finger in your eye.
Standardization always preceeds implementation. So how long is too long? One year? Two? Six months? It took the STLPort folks 2-3 years for a working implementation after the official spec was published. That doesn't sound too bad to me for a bunch of volunteers.
From the Cygwin mailing list: "data doesn't necessarily return a zero-terminated string, it simply returns a ptr to the raw data. It is only zero-terminated if you call c_str() which is, of course, why there are two functions in the first place."
Do you want a NULL-terminated string? Use
#include <sstream>
Use of the other two is deprecated per the 1998 standard. You couldn't read that part of the spec in the six years that it's been published?
Bah. GCC 3.x has had a ISO-98 standard C++ library for the last two years. STLPort has been around for even longer.
- I don't need to go outside, my CRT tan'll do me just fine.
C/C++ will likely never die. The problem with bytecode based languages is that they're *SLOW*.. I repeat *SLOOOOOOOOOOOOOOOOOW* compared to a good optimized C program.
Now you guys can argue your pants off about how "we've got hotspot" and "hotspot should be just as fast as native", but that's just not the case.
GJC
Gregory Casamento
## Chief Maintainer for GNUstep
The only concept I think you did not understand -- or research -- and that I would really like you to grok is the language-bootstraping concept. The song goes more or less like this: ... there you have compiler-c#-2-binary !!!! ... compiler-c#-1-binary !!! /.esque crowd manners can tire and irritate us... :-)
1. you write the compiler for c#, p.ex., in c#. (remember, you don't have a c# compiler, nor yacc, nor lex, nothing. just vi, for instance)
2. now you try to simplify the compiler you wrote, so it does not use and abuse every single feature of c#, but it uses just a minimum subset of the language, the less the better.
3. now you have compiler-c#-1.cs and compiler-c#-2.cs, you get compiler-c#-2.cs and removes from the compiler the features you did not use to write this version of the compiler. now you have three compilers: 1, 2, and compiler-c#-3.cs.
4. now you sit on a table with a lot of paper and run (with pencil and paper) compiler-c#-3, giving it as input... itself! when you end this step, you have as the result compiler-c#-3-binary, in asm, hex, or whatever you can input directly to your environment to form an executable file.
5. now you do "compiler-c#-3-binary compiler-c#-2.cs", roll the drums and
6. now you do "compiler-c#-2-binary compiler-c#-1.cs" and
7. (checkpoint) "compiler-c#-1-binary compiler-c#-1.cs" and the result *must be* absolutely equal the one in the pass #6 !!! you're done !!!
the critical pass (#4) is not really hard to do, because the compiler writer *usually* knows what code his compiler must spill for some input... is just mechanical work.
ma, no hands!
Ah, and you're right, sometimes
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
The inside story:
Pnet existed before mono. Pnet never gained credibility because the project leader (and story submitter) Rhys Weatherley is a pain in the ass to deal with. This story is an example of his trollish ways. The grandiose statement "C is dead" is a quote out of context. Miguel said something like: "To me, C is dead [for gui applications], except for the mono JIT [that I wrote]."
Mono has succeded because of good leadership. Pnet has failed for lack of it. After two years, mono has achieved and exceeded all of pnet's goals, leaving pnet with an inferior toolset (eg. their IL runtime lacks a JIT and is extremely slow).
Rhys seems to desperately want peer validation in the free software world. In his twisted worldview, he sees Miguel as a power hungry dictator (I kid you not) and literally hates his guts for mono's successes, of who's glory he believes is rightfully his, because he was there first.
In response to mono's achievements, Rhys and his small band of zealots seem to have spun their wheels a bit, biting off several new projects. For example the aformentioned C compiler and also a commitment to develop a native X System.Windows.Forms implementation, as opposed to the mono approach which is reusing the Wine project's winelib.
This is truly ironic considering Rhys absolute uncritical devotion to RMS's free software philosophies. Mono tends to promote Gtk# as the reccomended GUI library of choice. The Pnet SWF implementation will ultimately be a great enabler to proprietary software companies wishing to run their software on Linux. Yes, it will be a license violation. However it will be impossible to stop, because the users will be commiting it, rather than the sw company! No distribution required!
Almost all extant C practitioners would benefit greatly if they gradually abandoned C-style and learned multi-paradigm C++. The world would be a better place.
This is not a troll, and before all of you fundamentalist fanatics pull out your flamethrowers, inform yourselves:
C++ FAQ
C vs. C++
The case for the continued existence of C is tenuous at best.
But it ain't happening any time soon. Nevertheless: D, anybody?
~metal_llama out.
---
move every sig!
I'm going to take dot.gnu more seriously.
.NET.. because I don't know first hand whats up with those libraries... I'm hoping to know though... and from preliminary propaganda, they look wonderfull.
If You're saying it will save us from the microsoft tax... and will provide a framework with the consistancy and automatic optimizability and easyness that will save us from the dependancy hell that we currently have to deal with...
Horrah for dot GNU... I'll look at it before I look at mono.
I'm still a bit sketched about C being in the name..
Note, I wasn't trying to advocate mono or
Please use [ informative / summarizing ] SUBJECT LINES
Flame me here
and remember to pay your $699 licence fee
Java and other bytecode based languages can't hope to achieve the level of performance of C/C++. Both languages have plenty of life left.
Don't kid yourselves.
Gregory Casamento
## Chief Maintainer for GNUstep
Okay... whoever the bum was who modded me down for speaking the truth above. Ahem.. up yours!
BTW, I program in Java too (and several other languages, including ObjC/C) and I know the above from experience. No hype involved, Java *is and always will be slower*. Period.
GJC
Gregory Casamento
## Chief Maintainer for GNUstep
You're right. For some reason I thought both C and C++ had come out in the same year.
That is not true, the original C std. was basically a statement of what was already implemented ... thus. the strncpy() and puts() warts.
STLPort is not a complete environment, if you're compiler doesn't support templates properly (or at all) then STLPort isn't a solution. Also very few implementors do "ports" by taking the entire runtime with them from platform to platform ... mainly because everything you use (Ie. third party libraries) now also need to use the new runtime.
Personally I've dealt with C++ code that's been "in production" for 8-10 years or more.
So now you agree? What you originally said isn't true. std::string implementations on Solaris/NT seem to do the same thing for .data() and .c_str() ... so when moving to Linux say, you can have bugs (it also doesn't help that RogueWave's string type has .data() as the .c_str() equivilent).
I never said "I do", and it doesn't matter if the code still has to run on platforms that still use the older behaviour.
And it was first released in a real product, RHEL 3, in Oct. 2003. You seem to be confused between the real world, and "writing toy apps. in my bedroom". If you think C++ is wonderful, that's fine have your delusions ... and if you don't care that it's been 10 years in the making and there are only starting to be something closer to C++ compilers now, that delusion is also fine. But to suggest that the implementation of the Runtime is as similar across platforms as Java, .net or even python and perl is just obvious and easily refuted untruth.
ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
That was of course the point of STLPort: giving a leg up to incomplete versions. Is it perfect? No. But it allowed many people to write standard code until your main compiler caught up.
Bad template support? Yeah, nothing to be done about that. Just like the fact that there are C compilers out there that don't support the C99 standard.
Congrats about 8-10 years of production C++. Me, I only have 6-7 years.
No, I don't agree with you. Repeat after me:
std::string's
Are you kidding? RedHat Enterprise is, by definition, slow to release new products. It's been available in all standard distributions for far longer than that. I know. I've been using it. So compile on your dev box and put the binary on your production box running RHEL 3. You aren't doing development on your production boxes are you?
You're right. The different C++ vendors had wildly different implementations. This was the impetus for standardization: you couldn't write a program that compiled everywhere. Now it is much closer to that goal, but you still complain because it's not happening fast enough for you.
And for the record, while I was writing toy apps in my bedroom/dormroom in CFront days, I've been working professionally with C++ for 6-7 years. I remember what it was like. This is why I welcome the new changes.
Now, that said, I think C++'s standard library is too small. The stuff at boost is a good next step though.
- I don't need to go outside, my CRT tan'll do me just fine.