|
Future of straight C dev on Win & Linux GUI
Less than a year ago I've bought Petzold and later
15 or so Win32 dev books and it seems to me that I
did it at the last moment. These kinds of books
just disappeared over the year an now there's only .Net!
(and the new and improved C# Petzold).
What do you guys think about future of C development on
Windows and Linux?
After 10 years on Mac, I switched to Win because after
several attempts to learn and use Java or C++ I just
gave up, and since new Mac is so Objective I decided
to bite the bullet and move on to Windows and over the
year I have built my library so I could link it to 8 MB of C
source code created for Mac. I am not over yet, but I am
close and now I am thinking about Linux.
Is Linux GUI development also C++ or something even
worse? Is it time to start buying books or downloading
pdf's before it's too late. And does anyone know which
toolkit and environment should I use in the sense of
latest politics on Linux GUI scene if all I want is just
to convert my library to Linux and use my old but virtually
bug-free source code.
VPC
Tuesday, December 23, 2003
Won't objective C link to C? And something seems horribly wrong if there is no C-based Unix UI (though I assert my ignorance on the topic). Is there really any platform you can't program in C on?
Keith Wright
Tuesday, December 23, 2003
C(++) development will certainly keep declining on all platforms, it's inevitable. There's no upside strong enough to bring it back. That's the future, deal with it.
Ain't no buffer wide enough.....
Tuesday, December 23, 2003
www.wxwindows.org
end of thread
don't kid yourself
Tuesday, December 23, 2003
"C(++) development will certainly keep declining on all platforms, it's inevitable"
I don't see this. As the great Alec Guiness said in "Smiley's People":
"Expand, define ..."
Basically let's hear some rationale for this statement. I think C and C++ will be around for a gazillion years.
It is the closest thing to a machine independant assembly language around, and IMHO will always be the most valuable tool for those who really understand how to use it.
Mitch & Murray (from downtown)
Tuesday, December 23, 2003
"C(++) development will certainly keep declining on all platforms, it's inevitable. There's no upside strong enough to bring it back."
Err....the entire open source platform, a platform making huge inroads industry wide, is based on C/C++, largely due to the fact that there is great "cross platform" abilities of C(++).
Apart from .NET (Windows) and Java, there are no credible alternatives to C(++).
Dennis Forbes
Tuesday, December 23, 2003
C++ is definitely going away, it fact it is almost gone now. I predict that it will finally disappear for good one year to the day after the last QWERTYUIOP style keyboard is built.
Dennis Atkins
Tuesday, December 23, 2003
>> www.wxwindows.org
>> end of thread
But that is C++, not C.
VPC
Tuesday, December 23, 2003
>> Won't objective C link to C?
Maybe, but if I am to create my library to use native
Mac OS X API calls, I would need some really good
knowledge of Objective C.
>> And something seems horribly wrong if there is no
>> C-based Unix UI...
As I looked to Gnome and KDE they are all C based
with API libraries in C++ whatever that means.
Well, examples where all in C++
VPC
Tuesday, December 23, 2003
I thought gnome was written in C?
Anyway, there is still a gap between assembly language and the byte-code-interpreting / jit-compiling languages. Its covred mostly by C++ these days but as long as there is C++ , straight C will also be supported.
By the way, future in what sense? Job availabillity?
Eric DeBois
Tuesday, December 23, 2003
"Maybe, but if I am to create my library to use native
Mac OS X API calls, I would need some really good
knowledge of Objective C."
Really? And why is that?
Dennis Atkins
Tuesday, December 23, 2003
>> By the way, future in what sense? Job availabillity?
No. Books, examples, forums, experts giving advice
on usenet etc.
As I said above, I am almost done with Windows port
and now I am researching my Linux options but it seems like
it is all C++. I just wanna know where to start looking.
Is there anyone here doing GUI on Linux?
VPC
Tuesday, December 23, 2003
Check it out dudes. I am at the bookstore today and there is a huge fat tome in the special cover facing outward prize position in the high level computer books section where they have Design Patterns and the bundled AoCP and that sort of thing. What is this new 2003 release that is so phat? Why something called "The Art of Assembly Language". This is really the super ultimate reference on assembly it looks like with just all sorts of information and advanced techniques even I never heard of. Apparently there are these extremely high level assembly languages available nowadays that border on the expressivity and parsimoniousness of LISP.
And next to it, another recent release on programming the 68HC11. Gosh, brings up the memories.
So... is C being displaced by a return to pure Assembly Language programming? Is this the next big thing?
I say it just might be, based on the huge number of people I know who are working with embedded processors and writing in Assembly because they can.
Dennis Atkins
Tuesday, December 23, 2003
>> Really? And why is that?
I suppose that's how it's done. You know of an
example in C? Something that creates and handles controls
on the window?
It would be great if I could go Cocoa native and keep my
old code.
VPC
Tuesday, December 23, 2003
The GTK+ widget library[1] for Linux (and now Windows) can be used from (and is written in) plain C. It still uses objects, it just does them without an object-oriented language. But for most GUIs I just use Python[2] and PyGTK[3], its much easier than C or C++.
[1] http://www.gtk.org/
[2] http://www.python.org/
[3] http://www.pygtk.org/
Tim Evans
Tuesday, December 23, 2003
Yeah I can manage OS X window handles in C without using Objective C.
Dennis Atkins
Tuesday, December 23, 2003
Thanks for GTK.
Is there a "Petzold" or some sort of "must have" book for GTK?
VPC
Tuesday, December 23, 2003
>> Yeah I can manage OS X window handles in C without
>> using Objective C.
Please, can you point me to some example or FAQ or
whatever.
All the books that I've seen where ObjectiveC.
VPC
Tuesday, December 23, 2003
Serious Dennis? Or was that sarcasm? I have a hard time telling anymore what with all the idiots on the board.
Tuesday, December 23, 2003
No I'm perfectly serious. If you want to program direct to the native OS X API, you have two major api sets you can choose from and they now have identical functionality (although at one point they did not). One set is based on C, the other Objective C. Both come supported in the free development environments. One is called Cocoa and the other is called Carbon. So, if your goal is to run close to the metal in C and C++, you can use Carbon. If you prefer to use a mixture of C, C++ and Objective C, then you may use Cocoa.
Dennis Atkins
Tuesday, December 23, 2003
Havoc Pennington's GTK+/GNOME application development was very good, but it was for GTK+1.2. In general, you can just download a good application and read its source.
Using pyGTK and libglade you'll be remarkably productive and wonder how on *earth* you *ever* wrote guis that used pixels and the like to layout components.
Michael Koziarski
Wednesday, December 24, 2003
C/C++ will never go away, but eventually I think they'll inhabit a niche much like assembly language does today. C/C++ will nearly always be faster (in the proper hands) than higher-level languages like the .NET languages, Java, etc. However the extra development time required for C/C++ will mean that it only makes sense to use for *really* time-critical sections of code, device drivers, etc.
Of course it's a lot easier than assembly, so I don't think the niche will ever be thaaaat small. :)
John Rose
Wednesday, December 24, 2003
I meant to mention something about ever-increasing processor speed in my last post.
John Rose
Wednesday, December 24, 2003
Objective-C isn't the only way to do development on the Mac. In fact, it's not even the most popular. The Carbon environment (a first-tier API, with some of Cocoa implemented in Carbon and visa-versa), is an object-oriented C-based API. Apple stopped shipping their C++ framework for it recently (this same framework has been discontinued and brought back a few times now), and Metrowerks just put out a new OS X specific version of their C++ framework.
Lally Singh
Wednesday, December 24, 2003
If you like GTk try this:
http://www.wxpython.org/
Gives you a rich client GUI that (a far as I've seen) works without changes across Windows, Linux, *BSD, and probably others.
Tom Hathaway
Wednesday, December 24, 2003
From what I've seen of the open source types, there's a real predjudice against C++. It's plain C or nothing, particularly for GUIs.
Which, to my mind, is another plus in the Windows column. I don't think I could survive another plain C project without going completely insane.
Chris Tavares
Wednesday, December 24, 2003
"www.wxwindows.org end of thread durrr"
Have you ever actually tried using wxWindows? The documentation is terrible.
It's nothing close to what can be found in MSDN. Maybe things have improved since I tried using it.
Don't be so flippant and arrogant. wxWindows has been around for over 10 years, I think, and it still hasn't gained any real adoption.
Warren Henning
Wednesday, December 24, 2003
>> So, if your goal is to run close to the metal in C and C++,
>> you can use Carbon.
Somehow I felt that carbonizing gives you almost nothing
and takes away compatibility with System 7, 8 and most
flavours of 9.
Carbon apps look like second class citizens under X, and
MS IE is a good example.
On the other hand learning Win32 API and using old code
and old language seemed like an easier stuff for me.
The same thing is with Linux. If all it takes to convert my
app to another OS is one year of some moonlighting,
then it's worth it. Learning new API and new language
and new style of doing things was little too much for me.
>> I don't think I could survive another plain C project
>> without going completely insane.
Some people like it some hate it. It is true that most
C projects are done in "classic" procedural way, but if
you read the books about programming you see there
a lot of talk how you should separate your app into
different parts, like three-tyre buzzword or to separate
biz logic from UI and DB and then you see that almost
no one is doing it.
My approach is to build GUI library as if I am doing it
for someone else, so everything is separated from it
and my attitude to that code is different.
There is a part where I call OS APIs and where I need to
consult a lot of documentation for almost any line of
code that I write. Concentration and focus to the highest.
Then there is part of low-level biz logic where you need
concentration, but you don't need any manual or OS API
for that. And there is final part that you can write with
only one hand while talking to someone over the phone.
I think the answer is not to mix these parts in the same
structs/classes, sources or even headers. And if all you
do is passing function pointers to your own low-level
library then what can go wrong? Somehow I feel that C
is excellent for that kind of separation if you can discipline
yourself a bit.
But like I said, seems like people prefer OO languages
which force you to use their own style of separation of
code and that is OK with me, as long as there would be
option to continue with my own way. I was getting
impression that in few years no one will use straight C for
anything but Unix CLI mini-apps, device drivers and as
something kids are supposed to learn at school.
Am I wrong?
VPC
Wednesday, December 24, 2003
Yeah you're wrong. first off, Win32 has a lot less compatibility with os 7 than Carbon apps do. I mean, duh, right? What iknd of poitn are you saying you prefer Win32 because it gives you better Os 7 compatibility? You're not an actual programmer right? It's like you're saying you don't want a rowboat because you wouldn't know what to do with the waterskis.
Dennis Atkins
Thursday, December 25, 2003
This reminds me of an interview I did last month. The applicant has listed extensive experience in implementing graphics libraries. So I asked him "Pick a couple of your favorite line drawing algorithms and briefly describe for me their algorithm." He said, "Well there's one where I used stepwise refinement and another where I used recursion." "Really? A recursive line drawing algorithm? Did you find it was efficient?" "Yes, it used many fewer lines of code." "Could you show me the algorithm in pseudocode?" "No because there's a nondisclosure." "Here's some paper, show me a recursive algorithm to calculate n factorial." "What's n factorial?" "Well if n is 3, n factorial is 3 times 2 times 1. Seven factorial is 7 times 6 times five times four times three times two times one." "You could optimize that by not multiplying by that 1 and by doing a shift instead of multiplying by two." "Yes, just show me the code to calculate it recursively." "Let me spend some time thinking about that and I'll email you the answer this evening."
Dennis Atkins
Thursday, December 25, 2003
>> Win32 has a lot less compatibility with os 7 than Carbon
>> apps do.
Sorry if I wasn't clear enough.
Like any Mac OS 9 developer I was at the crossroads.
I had to do something, because things are changing as you
now.
My options:
1. Do nothing, sell Classic app to new OS X crowd and
continue support to people still using Performas 10 yrs old.
2. Carbonise - easy thing to do, but lose 75% of Mac market.
3. Learn Cocoa & Objective C, maybe give up after 6 months of wasted time and look at the options again. Somehow I
cannot make it with OO languages.
4. Learn something else, but try to keep C and 90% of
the code from the old app, grow potential market 10 times.
I've chosen the 4th option. And I enjoy learning Win32 API
very much.
And now please forgive me, but I have to post some of my
code here to show you something about compatibility of
System 7 and Win32.
hRsrc = FindResource(dtGData->hInstance,
MAKEINTRESOURCE((int)ditl_ID), TEXT("DITL"));
if (hRsrc)
macDialog->DITL_handle = LoadResource (dtGData->hInstance, hRsrc);
...
ditlPtr = LockResource (macDialog->DITL_handle);
macDialog->last_fldno = *((short *)(ditlPtr));
SwapShortEndians (&macDialog->last_fldno);
...
If you know what DITL is - great, you can see what am I
doing and why I've created lots of header files so I can
use things like EventRecord and &qd.gray.
VPC
Thursday, December 25, 2003
> 1. Do nothing, sell Classic app to new OS X crowd and
continue support to people still using Performas 10 yrs old.
Some people did that. OS X people in general don't buy classic apps though so its not a good move except as part of retiring a product.
> 2. Carbonise - easy thing to do, but lose 75% of Mac market.
Why would that be? Plenty of code bases compile on a range from 7-X. 75% of the Mac market is still on System 4-6?
> 3. Learn Cocoa & Objective C, maybe give up after 6 months of wasted time and look at the options again. Somehow I
cannot make it with OO languages.
Objective C takes maybe 1 day to learn. Cocoa is indeed different but it's just yet another api, something developers have to learn new ones all the time. I'm mainly on the PC and know little of Mac, yet developing Cocoa apps is a similar level of difficulty as scripting Python. Time to learn Cocoa plus time to develop a new app is less than to develop a new app in C using a familiar api.
> 4. Learn something else, but try to keep C and 90% of
the code from the old app, grow potential market 10 times.
Switching to windows to grow warket share is a valid business decision. It has nothing to do with the three phantom points in which you try to blame apple for your decision.
BTW, your code makes little sense to me and I do know what a DITL is. Did you cut and paste it from somewhere?
Dennis Atkins
Thursday, December 25, 2003
>>the three phantom points in which you try to blame apple
>> for your decision.
I did not blame apple for anything. I will continue to
support my app for Classic.
The point is, now I have lots of code that linked to my
MacToolkit.lib produces Mac application, and same sorce
with same resources (DITLs for example) linked with my
WinToolkit.Lib would produce Windows application.
We managed to turn this "C dev on Win & Linux" into
"Mac API choices". We better stop now. It's Christmas.
VPC
Thursday, December 25, 2003
Considering the number of companies that ported their code from Mac to Windows, surely, there are forums where you'll get more information on what it looks like, how they did, etc.
BTW, can someone sum up the different API sets available today on the Mac? I'm a big lost with carbon, cocoa, etc.
Frederic Faure
Thursday, December 25, 2003
Carbon is a thread safe, opaque structurized version of the old ToolBox, with lots of new stuff added. But by making some changes, you can get a codebase that compiles as a Classic app or as one that runs on 8,9 and X. 8 assuming that the carbon library is present, which is no big deal since its free and stable.
Cocoa is the descendent of the NeXTStep api and is quite different. But the newer features in Cocoa due to developer request, were ported back to Carbon. And much Carbon functionality has been ported over to Cocoa. Cocoa's big advantage is that the development envirenment for it that comes free is the most sophisticated of the lot.
And then there's the Java toolkit you can use to write your applications, but I am not sure if it is more like Carbon or Cocoa or what.
And there's Applescript, which is still around and apparently some people manage to write entire apps with thought I don't know how they manage it.
Those are the free ones apple gives you when you buy a copy of OS X, or you can pay $20 and get a CD with the development tools separately, or you can download all them for free.
There's also the C++ framework that comes with CodeWarrior.
And there's a few other popular application frameworks like RealBasic, and wxWindows, the Python gizmo that complies standalone stuff and seems to have access to the whole Carbon api and so forth.
Dennis Atkins
Thursday, December 25, 2003
> linked to my MacToolkit.lib produces Mac application, and same sorce with same resources (DITLs for example) linked with my WinToolkit.Lib would produce Windows application
OK, well that's the way to do it.
I'm just extremely skeptical that the move from toolbox to win32 is less complex than the move from toolbox to carbon.
Dennis Atkins
Thursday, December 25, 2003
Getting back to the original post...
It's a bit risky to draw certain kinds of conclusions from the book business.
The biggest market (in terms of volume) is going to be the current "new" thing. Each publisher has to put out their own version of the new thing to be competitive. The number of sales for a given title peaks early.
Books are published in runs. If the stock is running low and there is a (apparent) market for it, additional runs will be printed.
A book seller does not want to sit on a big inventory.
Book sellers can return over stock (I think) but there is a limited period in which they can do so (otherwise, they are stuck with it).
There is a limited amount of real estate for books. It makes more sense to display a book about the current new thing than one about something there is no industy buzz about.
Computer publications are understood to have a short life time (generally). Deservedly so in many cases because much of it is "me too" crap.
Anyway, C and C++ (the latter to some extent) will be around for a long time since there are not many alternatives with respect to portability.
njkayaker
Monday, December 29, 2003
> Anyway, C and C++ (the latter to some extent) will be around for a long time
This is Joel's "different worlds of software development".
For business logic, C++ is rapidly dying, roundly trounced by Java and C#. People routinely shake their heads and ask why you'd ever use C++ again (using C is already unthinkable).
For infrastructure (kernels, device drivers, OS libraries), I agree with this poster; C will be around for a long time (C++ I am not so sure about).
I am amazed at how much of the Linux GUI code (KDE and GNOME applications) is done in C/C++.
Portabella
Monday, December 29, 2003
 Recent Topics
Fog Creek Home
| 
