Discussion on:

The current state and future of C

to build a Pyramid, you need to start at the bottom and that always takes up more code than the newer code on top.

C++ is still needed to write the browser Operating system and the SDKs that are needed for .NET.

Frankly, this is why we need faster computers, because no one writes from NOTEPAD or editors too much anymore, everything is built from another platform and bloated with unwanted code.

Everyone thinks that Dreamweaver is the best editor out there. But infact, Ultraedit and othe Editors are much better, since you write the code, and not the software.

Even Java! Yes even Java.
Even C#! Yes even C#.
Theyre all dead Dave, Theyre all dead!
Even VB! Theyre all dead Dave, Theyre all dead!

When you have 10 cpus with 6 cores, do you really think procedural language optimisation is the waay to fly? Seriously?

by "When you have 10 cpus with 6 cores, do you really think procedural language optimisation is the waay to fly?"
I am a CS student, learning c++ at the Uni, would like to understand what you mean.
Thank you

is now we have calculators there's no need to teach arithmetic....

Not a lot of time for that assumption myself.

Or why you have to calculate you own change at McDonalds. These kids can't add or subtract.

Several good reasons for learning C++
1. Solid basis in object oriented programming.

2. Most of the other languages out in the real world use a similar structure and syntax. I originally learned Basic IV and Fortran. I did not try to learn C++ until after many years of VB, ASP, and HTML. (2006). I did not have to learn about memory mangagement, pointers, "Address of", "inherits", or any of that stuff. I never had to think about curly braces and semi colons, (the banes of my existence). Now when I program in Java, or C# or even JavaScript I spend more time thinking about syntax and basic concepts than I do in constructing my program. All the advanced real world languages out there utilize the same concepts as C++. Learn the basics and it is easy to extend your programming skills.

3. C++ is not going away anytime soon. If the Dept of Defense has anything to do with it, you will be retired before C++ goes away. They are still converting Fortran apps to C++.

Do the math, maybe the calculator boys on this thread can help. When you come out of Uni, how many years until PC's have a few hundred cores.
The declaritive world is finally being driven upon us, and models will look even more sexy

%-)

The brain or turing machine could be considered a model. But no, I am refering to the super models, thats what IT was made for.
On the bright side, a lot of existing developers will be carrying a lot of procedural bagage, so you may be better equiped for the continual changes.
Get one of your calculator friends to work out if the military will want a impressively slow threaded C solution or a 200 core declaritive solution. Then he can work out how long until we have 200 cores

IT can and does move fast, business lags though, currently by about 50 years in many applications.

You can still get jobs, in Fortran, Basic, Cobol, Delphi, VB6, and you'll still be able to do so for years.
Add in the fact that porting any non trivial code base is a huge investment, even if you don't give it an upgrade in functionality, in which case you business case for doing it is utterly f'ed.
Having huge number of cores to use on a basic CRUD application is a huge waste of effort, parallelisation opportunities are very limited, we have no languages or IDEs that do a good job with it, and on top of that well over 50% of the devlopers on the market wouldn't have a prayer of understanding the concepts anyway, because they didn't do CS, they did VB for dummies.

They don't get client server never mind concurrency.
Last but far from least the main stream OS in business is still windows and it's crap at multi-processing, and would have to be re-written rom the ground up to mdo it, and shift us into emulating what we have now or breaking everything.

Like other's have said the threshold is much more likely to be retirement than graduation.

Whenever it does happen someone who knows how things work has a much btter chance of using them, than someone who just turns on their PC and hopes the guy who wrote the tool they are using did. The latter of course being where the lucrative jobs are for those with the skill and a CS degree in anything being the first hurdle they have to jump to even get a look in.

Ironically CRUD has already been upgraded.

"OS in business is still windows and it's crap at multi-processing"
I think your missing the point... Its not so much that i'm right, than you being wrong.
If you have a porche, why are you riding your tricycle?

Lesson 1: IT changes very quickly.
Lesson 2: Goto lesson 1

I don't have a porsche. Can't fit my familiy in it, I like four doors, it uses way to much petrol, and a decent one is something I can't afford at the moment....

Practical_IT_in_Business.Exe

Repeat
// Do Nothing
Until NotGoodEnough;

Even I don't use GoTo anymore.

It's not so much the language choice as what you have to know to use it. Those things still come in handy for me, I bet they do for you and they will for this guy. By your arguement a few years ago, VB6 from dummies would be CS course material, so he'd have been out of date and clueless when he graduated.


VB6 From Dummies ??? Hmmm queue Freudian slip. LMAO

Microsoft are in the process of working on their declaritive OsloSDK, "D", "M"...
Declaritive CRUD in the form of database processing and Declaritive GUI using XAML.

OOD and UML are a model based approach, and this high level stuff will ofcourse be useful. It looks as though coding will become flow charts and rules around an XAML type display.

- Given that 2 lines of declaritive code can easily equal more than 20 lines of procedural... let the good times roll.

These wizard we'll take care of it for you silver bullet type approaches work really well on werewolves, in terms of applications though they suck.

Less code to write usally turns into less options available, or an entire application stuffed onto one line in my experience.

Cobol was also supposed to be the end of programmers. The manager could write his own app using English syntax without needing to know how to program. Problem was that computers don't comprehend English too well.

Managed environments were supposed to eliminate memory management problems. You don't have to worry about block of memory not getting deallocated because someone forgot to free up the block before destoying the pointer or setting it to point at another object. However, I've run across problems with the garbage collector taking too much time to free up memory, so that when the app runs in a distributed environment memory is exhausted before the garbage collector even kicks in. You're left with one of the following options:

1) forcing the garbage collector to free up memory quicker (not always possible)

2) taking over memory management yourself (back to unmanaged memory).

3) resetting your server every few days (something your network admin is going to love)

4) convince the CEO to add a infinite amount of memory at an extravagant price (might as well look for a new job) or impose a draconian limit on the number of users allowed to use the app (forget about scalability or business needs).

Of course, once a business wants to do something outside what the declarative language allows, all bets are off.

To be fair to the author, he does state that he's coming at this from the Windows angle.

I've worked with C and C++ for well over 10 years mostly developing Windows device drivers but also developing desktop software but like many I've found myself working more and more with languages such as C# over recent years.
Printer drivers written in C and C++ become filters written for the .NET framework. Yes I know filters are still often written in managed C++ but the pull towards C# is clear.

Over recent years I've found most things also becoming much more distributed or web based, if you're in the world of Windows you just can't escape .NET and the languages of MS choice, VB.NET and C#.
As a contractor I go where the work and money is and I can say with confidence that the bulk of freelance and contract roles in the world of Windows are C# or VB.NET based. At the same time however I've found C++ roles to be having a bit of a revival salary rise. It's as if everyone's jumped ship so quickly that it's left a bit of a void which the smart C and C++ contractors are cashing in on.

So is C and C++ dead?
Not even close but the industry has shifted.
There are fewer pure C and C++ roles out there in the world of Windows but as more people move to .NET it'll just increase the value of those C and C++ jobs and developers.
As people point out, .NET is just another layer although a very important layer in Windows, the underlying kernel and core libraries are still written in C, C++ and Assembler.
Of course move away from Windows to Unix/Linux, Mac, gaming systems, smart devices, embedded systems etc and the other technologies that make up the bulk of the industry and .NET becomes a distant memory.
I still enjoy working with C++ but for most of my day to projects C# is just more practical. However I?m always keenly aware that my next project may be better suited to C++ so I?m happy to that skill and secretly I always look forward to the opportunity to dust off my C++ skills...

As c++ is foundation for all language,
We must learn C++ first to start with some other languages,

There are lots of languages where which have nothing to do with C, nevermind C++

we don't have a thumbs down for silly discussion posts

Very valuable comments here!!!
A guy post this link http://www.defmacro.org/ramblings/fp.html.

If Functional Programming is the asnwer, why Alan Kay created Smalltalk?

Ruby is a good example of that. The rule I use is: think functional, then use objects only where state must be maintained. Of course, state can also be maintained in a closure, but OOP syntax is often clearer for that purpose.

You need assembler to run C. Machine code to run Assembler. Micro code to run machine code. (Micro code does the clever caching bits and pieces and pipelining or whatever... architestures change? Well, that is what they used to do.)

To learn anything you need to know some basic concepts.

I got into programming because an intelligence test defined some instructions and asked you do solve problems using them. I did not know what a computer was... many years ago now. When I did read about computers I realised that part of the intelligence test was similar to programming.

So I gave it a go.

I quickly learned that all assemblers were not equal. Some helped and some hindered.

Try doing spherical trig in fixed point math without floating point and you will understand what I mean. Use KDF9 and you will be spoiled for life.

Some instructions are guarded and cannot be used outside of specific hardware modes.

A mainframe OS listing will look very different other assembler because of the way it is built. (Lots of macros, conditional assembly and esoteric instructions for dumping and loading states.)

Knowing the why of what you are doing, and then knowing the how options always helps. You filter out so much noise and nonsense.

Many books out there are almost useless.

No one learning strategy works for all cases. I love really good examples. Reading other people's code always give you a good start when they know what they are doing.

Love programming, hate having to learn frameworks, sigh...

perhaps you have never heard of Nokia and Qt?

But take a look at the percentage of developers using those technologies. Even if the overall number is increasing, the percentage is getting smaller and smaller every year as people move to Web development.

Look, I'm not saying this trend is a *good* thing per se. But it's reality.

J.Ja

QT is a C++ widget set, available for most operating systems.

and, KDE is the only major *x application to use QT. The "licensing change" to QT 4 is what sparked the design change in KDE 4, to allow the bloated KDE 4 to run on top of the bloated windows os.

Qt is not just gui widgets.

Do you think Nokia would buy Trolltech (who developed Qt) and not plan to use it in their smartphone handsets?

Kde on windows started before kde4. It's just that the license change allowed Qt to release low level parts needed for windows, whereas before the community had to develop that themselves.

They've it up to C++ development now.

C, C++, even vanilla Pascal will gothe way of assembly I think. When you need it, you need it, ussing when you don't is uneconomical.

I still and always will believe that you can never be a top class programmer from a technical point of view if you don't know one of them or the other less feature rich but far more flexible languages. They are what's used to add those features, valuable or not.

Hell the mroe control of everythign aspect makes it worth it. But our college though java would be better taught. Go figure, there are almost no companies in Manitoba that use Java. Most use cobol, C++ or VB6.

All my friends from college actually code in VB6, and I do 99% of my code in VBA (same thing basically). But I am the only one from college that actually knew VB6, I taught myself before I even went to highschool. Having a job using VB6, sure makes all that schooling feel useless.

I agree with you that a CS education does you little good in a VB6/VBA position. If you had a decent CS education you should be able to use what you learned to learn C++ on your own. Unfortunately with a "Java education" it's unlikely you learned about pointers and addressing, which you will probably need to know if you're going to do real work in C++, since there will probably be C libraries you'd need to deal with. I don't know if such a thing exists, but it might be helpful to pick up a "C++ for Java programmers" book, because despite the syntactic similarities there are some architectural differences you absolutely need to learn in order to be comfortable with it.

What I recommend to people who want to learn C is they should learn assembly language first. The reason being that you will really understand what C is once you've understood assembly and then moved on to C. This is the course of action I took and it really helped me, because I realized quickly that C was just a high level assembly language. I took up C++ several years later.

There used to be debates about whether it was better to take an "objects first" approach to learning C++, or a "C first" approach. My own opinion is that the "C first" approach is better, because C++ still has its roots in C. Even though there are certain architectural elements from C that are de-emphasized in most C++ work, there's still some C there.

I doubt your CS education would help you with COBOL either. Your knowledge of VB6 would probably help you more with that. COBOL may have changed since I used it (in 1992 I think). One of the things I remembered was that there was no variable scoping. All variables were global, not unlike old style QuickBasic.

Records in COBOL fooled me at first. Even the fields inside the records were global! Records provided a grouping mechanism for variables. That was it. I could say something like "READ (blah) INTO (record)" and have all the fields in it populated, but the fields inside it were addressed globally, like they were stand-alone variables. Aiy!... I did not like COBOL.

And flat out hated the language, that coupled with JCL.

I liked JCL okay for the class, but I wouldn't choose to use it for my work. I always enjoy telling this story though. We learned about the COND command, and I remember it was the strangest part of the language, because it did the opposite of any conditional I'd seen before. I can't remember it exactly, but I think you could have a block underneath a COND statement(?), but it would only be executed if the conditional expression it tested was *FALSE*. That seemed totally ass-backwards. Due to my CS education I was able to "navigate" the COND statement deftly. I would just write the conditional expression out the way I normally would, put a NOT in front of the expression, and then I'd apply some theorem I learned in boolean math to it. I think it was called DeMauvre's Theorem. In any case it worked every time.

It wasn't until I took a course in compilers that I saw a rationale for why COND worked the way it did. It turns out that if you translate an if-else statement into compiled code you have to negate the conditional expression to make it work right. You set up a conditional test in the object code in order to execute the conditional, and once you test you need to branch. It doesn't make sense though to branch if the expression is true. You want to just execute the "true" block that comes right afterward. So the way it worked was if it's true in the source expression, it will be false in the object code and the program counter will fall through to the block of code that should be executed if the source expression was true. Likewise if the source expression was false the expression in object code will be true, and it will branch to the "else" block. Language interpreters do the same thing when they encounter an if-else statement.

I figured what they did with JCL was just simplify it (though it's ham-handed) by taking the expression you give COND and say "If this expression is true then branch beyond the code block."

Each month, they had a featured program, usually a small utility, with the assembler source code. By reading those listings and the article that went with it, I learned the basics. Then I bought a book and continued on.

You're right, knowing asm is a good starting point for C.

When I came through school everyone was required to program apps to accomplish their Chemistry and engineering work so everyone was taught Basic IV. We were taught CS 101 and CS 102. Those of us in majors that utilized more intense calculation were taught Fortran, and Algol. We were exposed to Cobol as a curiosity. Who would have thought that Basic and Cobol would actually outlast Fortran and Algol (Yes I know Fortran is still around on the margins of the world, but it is reletively insignificant compared to VB and Cobol.) I wish C or C++ were around when I was in school. However, I wonder about your advice to learn assembly language and C first. Yes I know you should start at the basics, but when you are working full-time, if you go back that far you are talking about years of playing catch up with technology. I walked away from this field from 1979 until 1992 and have been playing catch up ever since, and it is hard. Just when I think I have caught up, I learn about two or three new things I've never heard of. I think it would be enough for him to learn C++ fairly thoroughly and then extend that knowledge to C# and the other languages out there.

The guy I was responding to wasn't interested in C#. He was wondering about VB, Cobol, and C++.

One of the things I learned early on when I learned programming is it's best to understand a little of what's really going on underneath the language you're using. Maybe that's just me.

The reason I recommended assembly first for C is that I've seen people who've tried to learn C from the HLL perspective and they've thrown up their hands out of frustration and confusion (actually this was in the days of K&R C). But I'm sure you've heard the jokes about how "C gives you enough rope to hang yourself with". This comes out of not understanding what the language is really doing. Yes, it does "give you enough rope", but it becomes less dangerous if you understand the nature of this "rope" you're dealing with. Assembly will help one really get C.

One of the reasons I recommended "C first" is because I know from experience that often C++ projects contain a mixture of C and C++. Part of the reason for this is because a lot of C++ projects were done by people whose first language was C, and they didn't get the memo about creating objects. So they use a C++ API or two, and use the objects provided by them, but they treat the methods they have to create like C functions. This includes the use of pointers. If one gets into MFC (Microsoft Foundation Classes), there are plenty of situations where you have to deal with pointers. It also doesn't completely abstract away the Win32 C API. So understanding C would do one good if you're going to be dealing with C++ in the real world.

One of the first books I read on C++ was C/C++: Programming With Objects in C and C++ by Allen Holub. This one was helpful because it shows you what's going on in C++ from a C perspective, for example how C++ actually implements inheritance, both static and virtual, the mechanics of the "this" pointer, and how operator overloading really works (this is real important!). It was written before templates, and I don't think it's been updated, unfortunately. I looked at Amazon and Holub has another book called Enough Rope to Shoot Yourself in the Foot: Rules for C and C++ Programming. Maybe that's more along the lines of what you're talking about.

I prefer to understand what I'm really working with. Shallow descriptions of rules don't really help me. I understand that learning all this stuff is a lot, but I think if you come at it from a "top-down" perspective of "I'm just going to understand some things about C++" then when you run into C, I suppose you'll have to say, "I'll understand some things about C." But then you're going to need to understand pointers and addressing. Where are you going to really understand this? I'd suggest assembly. What about the idea that a "long" on a 32-bit C compiler means 32 bits, whereas on a 64-bit compiler it means 64 bits? Assembly gets that idea across very quickly. Java has consistency in these areas. C and C++ don't. That's one of Java's virtues.

Ok, here's a big question, is Assembly something someone like me could teach themselves?

The problem is that assembly for an Intel P4 and an Intel Itanium is different.
Assembly is 100% hardware specific. This is both the reason it is fast and powerful, as well as the reason it is so hard to work with.

Looking at the assembly for an i386 and learning that would most likely be enough to help with the C programming. The 386 is recent enough to have most of the complexity of current systems, yet it's also simple in comparison. The important thing is to understand what C is doing with your code in terms of the hardware level access C gives you.

When working at the Assembly / C level of hardware, mistakes are extremely critical. If you are looking at C for user space applications, then the hardware level isn't as important to know, it is important to understand how you could scew up that level though.

Unfortunately I don't have any recommendations about a book to get for this. The way I learned it was through a CS hardware architecture class in college. We used the Motorola 68000 CPU, and all I had was a CPU manual published by Motorola. It had a complete listing and description of all of the opcodes (the assembly instructions), the expected operands, and an exact description of what each command would do. We had some introductory instructions in my class about how to start and end an assembly program, how to run the assembler, how to look at the CPU registers, and a little sample code. Otherwise I just got my information out of the CPU manual.

We also of course learned some things about hardware architecture: the different parts of the CPU (like the program counter and registers), addressing, and how memory is accessed. Not all of this information is totally necessary for learning assembly. The main thing is learning about allocating and addressing memory, learning about the CPU registers, how to create your own routines in assembly, how to branch and set up conditional branching (this is also involved in creating loops), and how to push and pop data on/off the stack.

I was intimidated by assembly at first because early on I had heard horror stories about what happened when other people made mistakes with 8-bit computers, things like corrupted floppy disks. In those days there was absolutely no memory protection. If you were to run your assembly program in a Command Window inside Windows, or on a Linux system, you would be pretty safe. The worst that would happen in Windows would be corrupting some other application that was running, but I don't know if even that's possible now. Memory protection has gotten better with time on PCs.

I learned assembly on Unix, which had memory protection as well. The very first assignments I had were pretty easy stuff, things like string routines (concatenating a string, getting a substring, etc.). The most complex part was creating routines for doing arithmetic. The 68000 had some built-in arithmetic commands, but they were 16-bit only. We wanted to handle 32-bit numbers so we literally wrote our own routines for it. As I said earlier one of our semester projects was writing a 4-function calculator, that just took string input from the command line, did a calculation, and produced string output.

I was surprised. I found that assembly programming was amazingly straightforward. There were a few assignments I had where my program worked correctly on the first or second try! It was rare when I had that level of success in a HLL.

I know this isn't exactly the information you need to get started, but it's the best I can do. I did a quick look on Amazon and fortunately there's a bunch of assembly books on there, all for Intel as far as I can tell.

Just copy the script below to a file and then pipe this into the Debug program that comes with XP.

debug hello.txt

Make sure you include an extra empty line at the end after the 'q'.

a 100
jmp 110
db 'Hello world!'
db 0
db 0
mov ah, 40
mov bx, 1
mov cx, c
mov dx, 102
int 21
mov ax, 4c00
int 21


n hello.com
r cx
30
w 100
q

To do anything more serious you will have to get a good assembler program. However, you can learn a lot playing with Debug in the old DOS compatibility mode.
JS

What jslarochelle said reminds me, another critical thing to learn about is the base 16 numbering system, known as hexadecimal. You'll use this in assembly programming, and you'll also need to be able to read it, because anytime you look at data held in registers, or are debugging your program and you're trying to figure out what an address is pointing to, the values will be shown to you in hex. You'd see it a little bit in C and C++ as well. Most of the time values are represented as integers in those languages.

Doesn't make a whole lot of sense, is this what was supposed to happen?

C:\>debug

It made a file called hello.com than when run says hello world. Hmmm, how does that syntax work (Definitely not what I was expecting)

now, using any other language, write a hello world app for dos and compare the executable file size. I bet it is far larger than the 30 bytes the assembly app used.

I'm guessing

Echo Hello World

is cheating right?

But now I want to know what the heck that code meant.

Jaqui is right. The size is really hard to beat in any language (in fact the actual size is smaller than 30 bytes but I was lazy so I rounded up the number to make sure I got everything on disk).
This code is really not state of the art Ray Duncan DOS era code but I thought that it would do a nice demo. I was lazy in a number of ways:
Because I was actually typing this in the Debug shell as I went along I put the data (the Hello message) at the beginning of the code segment and put a jump over it. The db are used to define byte data. I just had to append a few 0 at the end to get the offset right for the start of the actual code (the value I used for the jmp - the goto).
I was also lazy because I used DOS Interrupt 21h function 40h (file output) to display the string (I could have used other functions or BIOS interrupts). Just shove the function number in register AH, the length in CX and the segment offset of the data in DS:DX. Because I use a .COM I did not have to set DS (automatically set by the "OS" to the same value as the code segment). The value in BX is the handle of the file. In this case 1 the predefined handle of stdout. AFter that just call Int 21h to display the message.
You end the program by calling Int 21h function 4Ch in AH with a return code 0 in AL. So I just shove 4C00h in register AX. Then call Int 21h to terminate.
A software interrupt is like a function call with the parameters passed in the CPU registers.
For a real program people did not use Int 21h for output to screen. They used direct hardware access because this was much faster. It also required much more code (detect the video adapter, setup for display, perform the actual copy, ...)
Int 21h was unbeatable for size and portability over different hardware and DOS versions.
This kind of script was quite popular in PC magazine at the end of the 80s and beginning of the 90s (the "compiler| came included with DOS). I won my first "of the job" programming money by having one of my scripts publish around 1991 in Neil Rubenking's "User to User" section.
JS

Robert Lafore was my childhood favorite programming book author. I taught myself assembly when I was in 8th grade from that book. (Moreover, I had a younger cousin who was ahead of me and was already writing his own video games in assembly on his Apple II at the time.) The first few chapters showed how to write simple assembly programs using the DOS debug program. It uses the same method described by JS, although it was written before "Hello World" had caught on as the ubiquitous obligatory first program. I later learned C from another one of his books.

When I was a university student, I wrote a keyboard macro in assembly on a 386 to automate some data processing in one of my research projects. I explored using C, but found it easier and more straightforward to do it in assembly since that way I knew exactly what my code was doing.

When I did MFC programming there were several times when I had to diagnose crashes. It isn't like in Java where you get a stack trace when an exception gets thrown from a crash. The application just locks up or the OS shuts it down altogether. I should clarify, in MFC the runtime does handle thrown exceptions. What I mean is there are instances where no exception will be thrown at all. If you reference memory that hasn't been allocated, no exception will be thrown for that. The OS will just shut it down. Neither the runtime nor the OS will tell you much about what happened.

In Windows the OS produces what's called a "Dr. Watson dump" in cases like this. In Linux you get a "core" file that you can load into a debugger and it will show you right where the fault occurred, down to the source line number.

In order to read the Dr. Watson dump in Windows you have to understand something about assembly, because all it is is a disassembly (creating assembly code out of machine code instructions) of the section of memory that caused the application to crash. If you have debugging symbols included with the compiled program you'll actually get some labels that will map back to the C/C++ code, so you'll get a rough idea of where the fault occurred, but that's all you get. So having some grounding in assembly helps you not freak out when you see that.