C programming language discussion

Everything todo with programming goes HERE.
User avatar
Lucifer
Project Developer & Local Moonshiner
Posts: 8610
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Re: C programming language discussion

Post by Lucifer »

Monkey wrote:
Lucifer wrote:C++ isn't that complex. It's basically what you get when you allow function pointers to be members of structs, and the logical things that that allows (inheritance and polymorphism). It's called C++ because it really is just C with a few additions to it.
I have to admit that I like the fact C++ classes have methods/functions within them (encapsulation or whatever the buzzword is for this). However, I'm not sure that C is Just C++ with a few additions. From what I remember of C++, there's lots of extras: encapsulation, inheritance, polymorphism, operator overloading, scoping differences, cout/cin/whatever, templates, virtual functions, etc.
Encapsulation is just the idea of having function pointers as part of structs. Inheritance is a logical consequence of that. C has scope as well. cout/cin are just objects in the standard library. You can still printf your heart out if you prefer. Templates are something that C badly needs, and technically already has in the form of #defines, but for objects, you need the same idea implemented in a way that #defines don't cover, and virtual functions are simply ways to designate a method that *must* be implemented in a subclass or it won't compile. Java uses interfaces instead. In Python, you have to program the base class to throw an exception for functions that must be overloaded.

Edit: I forgot that operator overloading is just a mechanism to tell the compiler how to do math with different types. When the compiler doesn't know how to add two data types together, you have to tell it how to do that. That's all that is. It already knows how to add/subtract/multiply/divide/exponentiate ints, floats, words, chars, long ints, etc. But it doesn't know vectors until you write a vector class telling it to. Furthermore, you may want multiplying vectors to find the determinant instead of just multiplying the components, so the compiler can't even try to do it lazily. Operator overloading is easy. C just doesn't need it because it doesn't have user-defined types, only user-defined aliases for types it already understands.

See? It really is just C with a few extra things that logically follow when you allow a struct to contain function pointers. :)
Linux has much more hardware support than any BSD true, but I wouldn't say that Linux does hardware support better than the BSDs. A good example is (or at least was) the differing APIs for different architectures that Linux has (or at least had). OpenBSD uses one API for all architechtures, keeping machine-independent code together and machine-dependent code seperate; it's all nice and tidy. Another example is kernel modules; OpenBSD doesn't have any. The reasoning behind this is that using kernel modules can produce race conditions (i.e. bugs). Also, everyone uses the same kernel (called "GENERIC"). Therefore bugs can be reproduced more easily/consistently. There's no compiling your own kernel (well, you can but it's not encouraged other than for kernel hacking).
Nowadays you don't have to compile your linux kernel either. :)

However, if you write GPL drivers, the interfaces for those are static and well-supported. The device interfaces that keep changing are Linus Torvalds's way of throwing the middle finger at NVidia for refusing to write GPL drivers.

Also, Linus Torvalds is on record as saying that kernel modules were a bad design decision. :) He's been trying to move to a more sandboxed approach since 2.6, but I don't know what sort of progress they've made since then.
Lucifer wrote:Maybe the GNU kernel is the best because it doesn't have to compete with anybody
Yeah, good luck with that. GNU is a recursive acronym, standing for GNU's Not Usable. Harsh but true.
Heh, that was my joke. :) Does the HURD kernel do anything other than generate flamewars yet?
Lucifer wrote: Lisp vs C is one of the classic flamewars, after all.
Yes it is. So is vi vs EMACS. It's probably obvious that I'm a vi guy. I used Vim for years until I decided it was too complex and switched to vi. I do miss multiple undos but other than that, I haven't looked back :)
[/quote]
I was a vi guy until they invented GUIs. Nowadays, I'm all nano, but I found a cool syntax-highlighting code editor that works similar to Kate in a terminal. Then I got a new (to me) laptop and didn't need it anymore.
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden

Monkey
Match Winner
Posts: 735
Joined: Thu May 22, 2008 12:36 am
Location: England, UK

Re: C programming language discussion

Post by Monkey »

Lucifer wrote: It really is just C with a few extra things that logically follow when you allow a struct to contain function pointers. :)
I'm still not convinced that all of the features you mention are necessary. I can see the thinking behind them of course but I'm not convinced they're needed. Years ago, I wrote a program, with a GUI, in C++, that could apply filters to images (like the GIMP can do, e.g. blur, sharpen, smooth, edge-detect, etc). I used classes but none of the other features of C++ that we're talking about, not even inheritance. My point is that thinking of a program in terms of objects is the best way to program. However, in my opinion, you can do that without lots of OO features. I could be wrong here; time will tell :)
Lucifer wrote:Nowadays you don't have to compile your linux kernel either. :)
You didn't when I used Linux either but it was considered a right of passage and hence many people did it.
Lucifer wrote:Heh, that was my joke. :) Does the HURD kernel do anything other than generate flamewars yet?
Snap :) and no, I don't think that even to this day the HURD kernel does much of any use.
Lucifer wrote:Nowadays, I'm all nano
nano was the first FOSS text editor I ever used, even before I knew of EMACS or vi :)
Playing since December 2006

User avatar
Lucifer
Project Developer & Local Moonshiner
Posts: 8610
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Re: C programming language discussion

Post by Lucifer »

Monkey wrote:
Lucifer wrote: It really is just C with a few extra things that logically follow when you allow a struct to contain function pointers. :)
I'm still not convinced that all of the features you mention are necessary. I can see the thinking behind them of course but I'm not convinced they're needed. Years ago, I wrote a program, with a GUI, in C++, that could apply filters to images (like the GIMP can do, e.g. blur, sharpen, smooth, edge-detect, etc). I used classes but none of the other features of C++ that we're talking about, not even inheritance. My point is that thinking of a program in terms of objects is the best way to program. However, in my opinion, you can do that without lots of OO features. I could be wrong here; time will tell :)
Ok, I'm biting. :)

Let's take a simple mathematical construct and consider how you'd write it. Vectors. In C, it's a struct.

Code: Select all

struct Vector {
   int x;
   int y;
};
.....aaaaaand, you're done. Ok, so, how do you add vectors together? Obviously, you write a function with a signature like this:

Vector AddTwoVectors(Vector victor, Vector vector);

You'd write a similar function to subtract them. So far, so good, right? Ok, let's look at that in C++.

Code: Select all

class Vector {
   int x;
   int y;

   // operator overload for addition not shown
  // operator overload for subtraction now shown
}
So, in C, when you add your two vectors together, you have to write:

addedVectors = AddTwoVectorsTogether(jane, tarzan);

In C++, when you add two vectors together, you have to write:

addedVectors = jane + tarzan;

Ok, so C++ is winning on readability. Now, what's a vector for, anyway? In this limited example, a vector can be a two-dimensional position, velocity, or acceleration. At least, those are the most obvious uses of the vector. Now, you want to create a light cycle so you can model its movement.

C:

Code: Select all

struct LightCycle {
    Vector position;
    Vector acceleration;
    Vector velocity;
};
Now, every iteration of your game loop, you have to call your three functions to add acceleration to velocity, then velocity to position. That's easy enough. Ok, let's see that in C++.

Code: Select all

class LightCycle {
   Vector position;
   Vector velocity;
   Vector acceleration;

   void Update(timestep);
}
Now, for every iteration of your game loop, you simple iterate through all the light cycle objects you've created and you call LightCycle->Update(currenttime).

So far, we're doing exactly the same stuff, right?

Now it's time to animate the light cycles. You have wheels turning. Now you're writing all these extra functions for that in C. In C++, this is what we'd do:

Code: Select all

class Wheel : public Vector {
    float rotation;
    float radius;

   // function that uses velocity to calculate the new rotation using the radius of the wheel
  // no function needed to render the wheel, the LightCycle class will use the members of this class to do that.
}
Ok, so you're coming up with a few "easy" ways to do that in C, so far, right? Here's where we get to the key, though. Everything you've written so far is pretty specific to your app. So I decide I want to make a motorcycle racing game that's motocross rather than light cycles with walls and crap. Here's all I have to write (after copying exactly two files from the light cycle game) to create my motocross cycle and have it be fully functional:

class MotocrossCycle : public LightCycle;

C has a decent level of code reusability, and it's good and useful, but it just can't compare to what you get with C++.

Now, let's consider a different situation, one where inheritance and polymorphism both come into play to some degree. I'm currently working on a game network library in Python. I figure there are a lot of tasks (including object syncing) that are common to many types of games, and everyone writing games is writing their own network code (even game engines only give you primitives to work with). So here's what I've got for a design:

nSyncObject is a base class. You must subclass it to make any game object you want, whether it's lightcycles or spaceships or that stupid duck that you could never shoot for some reason. When you initialize your subclass, you have to tell the super class what attributes are to be synced over the network. Then the base class that I wrote registers with another class that manages all the game objects to be synced, and whenever any object attributes change, the network layer will automatically send sync messages. As a game developer, this is what you'll write in order to tell all the other clients that your light cycle has changed directions:

player[juan].TurnLeft()

This will generate a command message sent to the server which will turn the cycle left and immediately inform all clients of the turn, the location of the turn, and the cycle's current speed, acceleration, and position. And the person who's writing this hypothetical light cycle game using my library only had to write one line of code to make that happen.

Now, in C++, this library is feasible, but would heavily depend on templates and the standard template library. In Python, with their batteries-included philosophy, everything's already there.

How do you do this in C?

Again, not to say that network code in C is inherently difficult or complicated. In fact, at the very bottom of the stack of programming technology I'm using is a socket library written entirely in C, without which none of this would be possible. But then, I've looked at FreeCiv's network layer, and it's a gigantic mess. Z-man occasionally complains about armagetron's network layer, but compared to some of the others I've seen, arma's network code is approaching art, not just in its relative simplicity, but also in its overall robustness. Using UDP, even. FreeCiv uses TCP, and during later parts of the game, it's common for clients to timeout waiting for all that C code to process the turn. I realize C isn't the problem there, but it's certainly doing absolutely nothing to help solve that problem. When you start moving into classes with inheritance and polymorphism, you have a language that is actively helping you to solve that problem and many others.
Lucifer wrote:Nowadays, I'm all nano
nano was the first FOSS text editor I ever used, even before I knew of EMACS or vi :)
I started with vi, got pretty good at it, then got a GUI. Now I only use terminal-based editors when absolutely necessary, and I use nano because it's fairly easy and straightforward, and if I need anything more than that, I fire up Kate. I *did* grow up with an Amiga, after all.
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden

Monkey
Match Winner
Posts: 735
Joined: Thu May 22, 2008 12:36 am
Location: England, UK

Re: C programming language discussion

Post by Monkey »

Lucifer wrote:So, in C, when you add your two vectors together, you have to write:

addedVectors = AddTwoVectorsTogether(jane, tarzan);

In C++, when you add two vectors together, you have to write:

addedVectors = jane + tarzan;

Ok, so C++ is winning on readability.
The C++ code may be shorter but does that mean it's automatically more readable or better? I'm not convinced. The "+" operator is far less expressive than"AddTwoVectorsTogether". In the above case, which is a simple case, both the C and C++ versions should behave as expected. What about if two more complicated objects were to be added together? "+" doesn't necessarily tell you much about exactly what happens when you do that but a meaningful function identifier could do. This is especially important if other programmers want to use/reuse the code as they may make assumptions or forget important details while coding.
Lucifer wrote:C has a decent level of code reusability, and it's good and useful, but it just can't compare to what you get with C++.
Lucifer wrote:Now, in C++, this library is feasible, but would heavily depend on templates and the standard template library. In Python, with their batteries-included philosophy, everything's already there.

How do you do this in C?
OK, so you're saying that in C++ and Python less time is spent when writing and reusing code. That is possible. However, I'm not yet buying that the code is better in the long term than when writing in C. With my current way of thinking, even if the C code is longer, if it's well written it shouldn't lose performance over C++ or Python code and it should be more readable. I'm gonna have to learn a lot more though before I can come a more decisive conclusion :)
Playing since December 2006

User avatar
Lucifer
Project Developer & Local Moonshiner
Posts: 8610
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Re: C programming language discussion

Post by Lucifer »

Monkey wrote:[quote="Lucifer"
The C++ code may be shorter but does that mean it's automatically more readable or better? I'm not convinced. The "+" operator is far less expressive than"AddTwoVectorsTogether".
Yes, in this case, it is automatically more readable and better. The "+" operator has a well-defined meaning that goes back a couple thousand years or so. If a programmer were to write code using the "+" operator that's inconsistent with that meaning, there are only one of two outcomes. 1. The code doesn't work because it's physically impossible. 2. The programmer never gets good at programming because he/she never truly understands how operators work and ends up doing something completely different with his/her life.

We think of math as a human invention, but really, the notation is just the invention. Math itself is a natural phenomenon. When you start dealing with object types that don't make sense in a mathematical context, then mathematical operations become meaningless. For example, you can't add two QButtons (from the Qt toolkit), because they're GUI elements, and adding GUI elements doesn't make any sense. Putting them together in a layout makes sense. Connecting them to the same slot so they do the same thing when you press them makes sense. But addition? No sense.
In the above case, which is a simple case, both the C and C++ versions should behave as expected. What about if two more complicated objects were to be added together? "+" doesn't necessarily tell you much about exactly what happens when you do that but a meaningful function identifier could do. This is especially important if other programmers want to use/reuse the code as they may make assumptions or forget important details while coding.
A lot of that really depends on the code in question. One of the goals in object-oriented languages is to provide well-defined interfaces with well-defined behavior, but keep the details of the implementation out of the way. As long as the object's interface stays the same and behaves the same, then the details of the implementation are irrelevant to the programmer using the object. Because of this philosophy, when a programmer finds a better/faster/more efficient way to implement something a given object does, they can go ahead and make the change to the object, and everybody else using the object benefits by the change, without having to change a single line of code. This can include completely rewriting the internals of the object, because the internals don't matter to someone using the interface. That's something that C just can't do, because the internals are all right there. You can do a little bit, of course, but if C could do all of that, then the need for object-oriented programming would never have been there in the first place.
OK, so you're saying that in C++ and Python less time is spent when writing and reusing code. That is possible. However, I'm not yet buying that the code is better in the long term than when writing in C. With my current way of thinking, even if the C code is longer, if it's well written it shouldn't lose performance over C++ or Python code and it should be more readable. I'm gonna have to learn a lot more though before I can come a more decisive conclusion :)
Well, first of all, less time is spent writing code in C++ because you use a lot of code that was already written by someone else. You can do that in C, too, but C is more limited in reusing code than C++ is, and C++ is more limited than Python is.

Now, when it comes to performance, assuming you're talking about execution speed, for well-written code, you should expect C to always come out on top over all other languages. You can't even write faster assembly code than what you get in C because compilers have gotten so good at optimizing compiled code that a human simply can't write assembly code that's faster than what the compiler spits out. C++ is the language that comes the closest to C, but because of the extra cycles it can take to lookup methods in vtables and stuff like that, C++ loses a little bit of ground in performance to C. Python, being an interpreted language, loses a lot of ground in performance. In fact, an important strategy in writing Python code is to write in such a way that you can turn CPU-intensive tasks over to the underlying C library to do the heavy lifting.

As far as what counts as more readable, there's a lot of aesthetics involved in that question. I like that Python forces you to indent code blocks. I hate that there are 50 different style guides out there on how to "properly" format a function declaration in C/C++. In particular, I hate the GNU style standards for exactly that. I find this to be more readable...

Code: Select all

def RenderSomethingToTheScreen(thatSomething)
...than this...

Code: Select all

(void) RenderSomethingToTheScreen(*renderableSomething something);
...but this is more informative...

Code: Select all

float sin(float theta)
....than this...

Code: Select all

def sin(theta)
...and since the two languages I'm directly comparing here are C and Python, C++ gets the same criticism/complement that C gets here.

But you did hit on the most important bit of coding, which leads to the most important part of selecting a language: there's just no substitute for well-written code, and a programmer is going to write their best code when they use a language that suits their style and mode of thought. So, Linus Torvalds can hate C++, he probably wouldn't write as good a code in it as he does in C anyway, so he should stick to C. I like to talk a lot, and prefer to use the least amount of words I need, so C isn't for me. I truly believe I've written my best code in Python, so I'll stick with that. :) If C works for you, knock yourself out.
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden

User avatar
kyle
Reverse Outside Corner Grinder
Posts: 1860
Joined: Thu Jun 08, 2006 3:33 pm
Location: Indiana, USA, Earth, Milky Way Galaxy, Universe, Multiverse
Contact:

Re: C programming language discussion

Post by kyle »

Lucifer wrote:
Monkey wrote: The C++ code may be shorter but does that mean it's automatically more readable or better? I'm not convinced. The "+" operator is far less expressive than"AddTwoVectorsTogether".
Yes, in this case, it is automatically more readable and better. The "+" operator has a well-defined meaning that goes back a couple thousand years or so. If a programmer were to write code using the "+" operator that's inconsistent with that meaning, there are only one of two outcomes. 1. The code doesn't work because it's physically impossible. 2. The programmer never gets good at programming because he/she never truly understands how operators work and ends up doing something completely different with his/her life.

We think of math as a human invention, but really, the notation is just the invention. Math itself is a natural phenomenon. When you start dealing with object types that don't make sense in a mathematical context, then mathematical operations become meaningless. For example, you can't add two QButtons (from the Qt toolkit), because they're GUI elements, and adding GUI elements doesn't make any sense. Putting them together in a layout makes sense. Connecting them to the same slot so they do the same thing when you press them makes sense. But addition? No sense.
[/quote]
Also Methods tend get lost, AKA I may call the method AddTwoVectors, someone else may call it VectorPlusVector another may call it something else. Me not knowing what the other programmer called it may not be aware that it exists and I may write my own method that does the same thing. We'll have duplicated code. Operator overloading is the best way to get around this.

Also consider the case of adding more than 1 vector together

With operator overloading

Code: Select all

A + B + C + D;
using methods

Code: Select all

AddTwoVectors(A, AddTwoVectors(B, AddTwoVectors(C, D)));
(hopefully I got the right number of closing brackets)

Which is clearer as to what's going on?
Image

Monkey
Match Winner
Posts: 735
Joined: Thu May 22, 2008 12:36 am
Location: England, UK

Re: C programming language discussion

Post by Monkey »

Lucifer wrote:The "+" operator has a well-defined meaning
Lucifer wrote:When you start dealing with object types that don't make sense in a mathematical context, then mathematical operations become meaningless.
I don't believe that things are that black and white and middle ground cases could cause problems. I suppose it depends on the programmer's decision making skills.
Lucifer wrote:One of the goals in object-oriented languages is to provide well-defined interfaces with well-defined behavior, but keep the details of the implementation out of the way.
That sounds great in theory but aren't internals generally made up of other objects/classes and functions/methods? So if you change the internals, chances are you're changing some other interfaces somewhere?
Lucifer wrote:Now, when it comes to performance, assuming you're talking about execution speed, for well-written code, you should expect C to always come out on top over all other languages
I'm surprised at this because I've heard talk of "incremental" compilers being able to compile C++ code that rivals C code. I don't know much about compilers myself though so that could well be wrong.
Lucifer wrote:You can't even write faster assembly code than what you get in C because compilers have gotten so good at optimizing compiled code that a human simply can't write assembly code that's faster than what the compiler spits out.
I didn't know that, I always assumed that assemblers would produce faster code than any compiler could.
Lucifer wrote:I like that Python forces you to indent code blocks. I hate that there are 50 different style guides out there on how to "properly" format a function declaration in C/C++.
I think I agree with that; in my opinion, sometimes choice is not a good thing. OpenBSD has it's own style guide for C code so I'll follow that.
Lucifer wrote:there's just no substitute for well-written code,
Absolutely.
Lucifer wrote: I like to talk a lot, and prefer to use the least amount of words I need, so C isn't for me. I truly believe I've written my best code in Python, so I'll stick with that. :) If C works for you, knock yourself out.
Fair enough :)
kyle wrote:AddTwoVectors(A, AddTwoVectors(B, AddTwoVectors(C, D)));
I don't think that's actually what you would do in C. I think you can define functions that can be given any number of arguments so you'd end up with something like:
add_vectors(A, B, C, D) :)
Playing since December 2006

User avatar
Lucifer
Project Developer & Local Moonshiner
Posts: 8610
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Re: C programming language discussion

Post by Lucifer »

Monkey wrote:[
Lucifer wrote:When you start dealing with object types that don't make sense in a mathematical context, then mathematical operations become meaningless.
I don't believe that things are that black and white and middle ground cases could cause problems. I suppose it depends on the programmer's decision making skills.
A lot of the middle ground cases that used to exist have been resolved. :) For example, for list types, the + operator is defined as concatenating the two lists. It didn't used to be that easy to figure out. The - operator is still ambiguous, depending on language/programmer decision.
Lucifer wrote:One of the goals in object-oriented languages is to provide well-defined interfaces with well-defined behavior, but keep the details of the implementation out of the way.
That sounds great in theory but aren't internals generally made up of other objects/classes and functions/methods? So if you change the internals, chances are you're changing some other interfaces somewhere?
Sure. So, take Armagetron's resource manager, or lack thereof. The one I almost wrote. :) It would use libxml2 for the backend xml parsing and stuff, but provide a sane public interface to arma code. I hated that the libxml2 http retrieve function was always blocking, and I wanted to find a smaller, faster, more lightweight xml parser, preferably one I could embed in the codebase and remove the dependency on libxml2. If I were to do that, then I could, and none of the code using the resource manager would know or care that I did that. But I haven't changed any interfaces in a destructive way at that point, I've only changed the ones I've chosen to depend on in the implementation, and the interface to the rest of the arma code is still the same.

Java has public and private interfaces for precisely that reason. The public interface for an object is expected to stay the same for all time, but the private interface is allowed to change.
Lucifer wrote:Now, when it comes to performance, assuming you're talking about execution speed, for well-written code, you should expect C to always come out on top over all other languages
I'm surprised at this because I've heard talk of "incremental" compilers being able to compile C++ code that rivals C code. I don't know much about compilers myself though so that could well be wrong.
The key word there is "rivals". C++ code can *never* be fast than C code, because the whole language really is C plus a few things. More in a sec...
Lucifer wrote:You can't even write faster assembly code than what you get in C because compilers have gotten so good at optimizing compiled code that a human simply can't write assembly code that's faster than what the compiler spits out.
I didn't know that, I always assumed that assemblers would produce faster code than any compiler could.
Strictly speaking, assembly code is the fastest code that you can write, because there's a direct 1 to 1 relationship between what you write and how it runs on the CPU. Assembly code is a human-readable version of the CPU's instruction set. Many compilers (and back in the day, all compilers) actually convert whatever language you're working with to assembly code first, then use an assembler to finish the job.

C was designed so that many of the basic tasks you do with it would compile straight to assembly, thus giving you the speed of assembly code but the readability of a higher-level language. That's why it's often referred to as a middle-level language. It's as close as you can get to the metal while still speaking English, so to speak. But back in the 70s, when it was developed, there was still the understanding that, at that time, a human could write faster code in assembly than they could generate from C, so C has a feature where you can write a function declaration in C, then write the body of the function in assembly code using the variables provided in the function declaration. That would allow the programmer to selectively optimize performance bottlenecks when needed. The most recent that I've seen anybody actually doing that would be the Quake engine (I'm pretty sure the same version Z-man used to get the initial network code for arma). Of course, C++ inherited this ability from C.

So then you get this discussion of "When do I optimize my C code with assembly instead?". Well, the 90s called, and they want their dumb programming arguments back. Anyway, you sacrifice cross-platform compatibility for performance, but you get to fix the bottlenecks. Nice, so far, right?

That's where compiler optimizations matter. The question, over the years, has been "Can a compiler optimize better than I could, writing my own assembly?" The answer, nowadays, even using GCC, is a firm "yes, yes it can". In fact, it was when C++ compilers finally starting compiling code that rivaled C in performance that it became time to stop optimizing C code with assembly code and let assembly fall to electrical engineers to use amongst themselves. I hear they use it for foreplay or something like that.
kyle wrote:AddTwoVectors(A, AddTwoVectors(B, AddTwoVectors(C, D)));
I don't think that's actually what you would do in C. I think you can define functions that can be given any number of arguments so you'd end up with something like:
add_vectors(A, B, C, D) :)
Yeah, the function declaration would be something like:

Vector AddTwoVectors(Vector ...)

That ellipsis specifies variable arguments, and man, the flame wars over that being added to the language were insane. Also, fun. Too bad I wasn't actually around when they were happening, you know I'd have had a lot of fun trolling those flame wars.
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden

User avatar
kyle
Reverse Outside Corner Grinder
Posts: 1860
Joined: Thu Jun 08, 2006 3:33 pm
Location: Indiana, USA, Earth, Milky Way Galaxy, Universe, Multiverse
Contact:

Re: C programming language discussion

Post by kyle »

Lucifer wrote:
Monkey wrote:
kyle wrote:AddTwoVectors(A, AddTwoVectors(B, AddTwoVectors(C, D)));
I don't think that's actually what you would do in C. I think you can define functions that can be given any number of arguments so you'd end up with something like:
add_vectors(A, B, C, D) :)
Yeah, the function declaration would be something like:

Vector AddTwoVectors(Vector ...)

That ellipsis specifies variable arguments, and man, the flame wars over that being added to the language were insane. Also, fun. Too bad I wasn't actually around when they were happening, you know I'd have had a lot of fun trolling those flame wars.
Did not realize that actually existed in c, not to say there were not other ways that that could be done also. (was trying to make a point, based on writing similar methods)
Image

User avatar
Lucifer
Project Developer & Local Moonshiner
Posts: 8610
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Re: C programming language discussion

Post by Lucifer »

kyle wrote: Did not realize that actually existed in c, not to say there were not other ways that that could be done also. (was trying to make a point, based on writing similar methods)
Your point still stands. :) It's sort of antithetical to the basic concept of C to have variable numbers of function arguments, hence the flamewars over it.

Personally, I like Python's keyword-based arguments. It's clearer, even if the types of the arguments aren't clear. What I don't like is that, short of using a documentation method (like doxygen, or the built-in python docs), there isn't a clear way to see what the arguments are to a function without reading the body of the function.
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden

Monkey
Match Winner
Posts: 735
Joined: Thu May 22, 2008 12:36 am
Location: England, UK

Re: C programming language discussion

Post by Monkey »

Lucifer wrote:What I don't like is that, short of using a documentation method (like doxygen, or the built-in python docs), there isn't a clear way to see what the arguments are to a function without reading the body of the function.
The good news for me is that OpenBSD's man pages contain all that sort of stuff relating to C (including the standard library).

I've stopped reading the tutorial on C that I was reading because it wasn't that good. Instead, I've found a PDF of "The C programming language, second edition", the book on C that was written by C's creator and another influential person on C. So far so good although it'll take me a little while to get through as I'm a bit slow :)
Playing since December 2006

User avatar
kyle
Reverse Outside Corner Grinder
Posts: 1860
Joined: Thu Jun 08, 2006 3:33 pm
Location: Indiana, USA, Earth, Milky Way Galaxy, Universe, Multiverse
Contact:

Re: C programming language discussion

Post by kyle »

Monkey wrote:I've stopped reading the tutorial on C that I was reading because it wasn't that good. Instead, I've found a PDF of "The C programming language, second edition", the book on C that was written by C's creator and another influential person on C. So far so good although it'll take me a little while to get through as I'm a bit slow :)
I have the book, it was the one used at my college for the C class.
Image

Monkey
Match Winner
Posts: 735
Joined: Thu May 22, 2008 12:36 am
Location: England, UK

Re: C programming language discussion

Post by Monkey »

kyle wrote:I have the book, it was the one used at my college for the C class.
Good to know that they're still using it in teaching environments. So far, I'm liking it, especially with the tasks they set. I'll probably have it finished by Xmas 2020 haha :)
Playing since December 2006

TheKaras
Posts: 3
Joined: Wed Jun 06, 2018 8:25 pm

Re: C programming language discussion

Post by TheKaras »

hey monkey how u doin homie? I know some C, I did a scheduling class after CFS at some point for the linux kernel, I can help u dawg. let's build a C website for the red cross homie if u know what I'm saying daw.g

Post Reply