C question

[geek1]

I was just wondering, is there a difference between C and C#?




thanks

[tristantech]

Yes, there is.

Although C and C# have similar names, they are completely different languages.

C# is developed by microsoft. It is a high-level object-oriented programming language.
Some sample c# code:

Code: [Select]

using System;
class ExampleClass
{
    static void Main()
    {
        System.Console.WriteLine("Hello, world!");
    }
}



C is from 1972. It is lower-level than C# and a lot different:

Code: [Select]

#include <stdio.h>
void main()
{
    printf("Hello, World");
}

Both those examples write "Hello, World!" in a console application.

[SciTech02]

What about C++?  How does that language stack up with the other two? (I'm asking this so that this thread may become a summary of all the "C" languages). 

[Webbot]

The world started with C - which is a procedural language like Basic.

Then the world went object orientated (OO). The OO version of C was called C++.

Then Java came along - which also OO but runs on most operating systems without modification (unlike C or C++).

Microsoft came up with C# when the Java community got fed up with them trying to turn Java into a Windows biased programming language (so whats new!). MS threw their toys out of the pram, and stopped promoting Java, and came up with C# : thereby allowing Java to become the excellent language it is today.

Forget C# - use C for micro-controllers and Java for real computers.

[bryan922]

C has always been the language for pedal to the metal performance. It's one step away from assembly, yet it's also considered a high level language.

C is easy to read - I would argue that it's one of the easiest languages to read, due to its limited set of keywords. I would also argue that it compiles to some of the fastest machine code out there.

C is easier to learn than Java or C++ because of its smaller set of syntactical features. With regard to its lack of object oriented features, it often loses out to object oriented languages for large software applications - that is to say, applications pushing beyond 100,000 lines of code and upwards, into the millions.

Drivers, which is code to run devices, such as graphics cards, etc., are written in C usually, for the closeness to the machine hardware that C represents. For the same reason, it is no coincidence that C is also one of the language of choices for microcontrollers.

C is performance minded, professional, efficient, respectable, and nobody ever got fired or was laughed at for programming a device or machine in C.

C is not a toy language. It is one of THE languages for getting real work done, in devices in your car, devices rolling around on Mars, control systems in manufacturing plants, and so on.

Linux is written in C. The Apache web server, which dishes out most of the world's websites, is written in C. The original Unix operating system and just about all subsequent ones were/are written in C.

The compilers or interpreters of other computer languages are often written in C.

C is pedal to the metal performance.

[cosminprund]

C has always been the language for pedal to the metal performance. It's one step away from assembly, yet it's also considered a high level language.

C is easy to read - I would argue that it's one of the easiest languages to read, due to its limited set of keywords. I would also argue that it compiles to some of the fastest machine code out there.

The kind of C used for microcontroller programming is surely easy to read but that's no longer true for large programs that use C effectively. You'll get lost in a sea of pointers and the compiler will not help you navigate because it has no notion of "pointer type". Sure it's grate for embedded stuff and really high performance stuff (thinking of kernels and device drivers here) but it's not well suited for higher level applications.

Linux is written in C. The Apache web server, which dishes out most of the world's websites, is written in C. The original Unix operating system and just about all subsequent ones were/are written in C.

That's true for the Kernel, both the Linux kernel and the Windows kernel (apparently) but for an unexpected reason: There are way too many libraries for C++ and both the Windows people and the Linux people quoted this as a reason NOT to program low-level stuff in C++: You can't expect every library out there to be readily present in the kernel we don't want every driver or every module to bring in every library that's being used. Also people are writing Windows drivers in C++!

What works against C++ (and in favor of C) for low-level stuff works the other way around for user-level applications: With todays computers and storage capacity, time-to-market is more important then efficiency and size. It's OK to use a preexisting library if it makes programming easier, faster and safer (safer because preexisting libraries are properly debugged allready).

The compilers or interpreters of other computer languages are often written in C.

I thought all respectable compilers make it a point to compile themselves! They might use a bootstrapping technique based on C to start the compiling process when a previous version of the same language is not available but they DO compile themselves.

I mostly agree with you bryan922, just wanted to make it clear that C is grate for low level programming but it also stops there: it's not an effective language for other kinds of applications.

[pomprocker]

Object Oriented programming uses something called "abstraction"!!

I remember a c++ programming course I took, we took about a week, just to train ourselves in the ways of thinking abstract...

[cosminprund]

There's more to OOP than just Abstraction. Here's Wikipedia's take on the subject:
http://en.wikipedia.org/wiki/Object-oriented_programming

OOP is a very cool thing and anyone considering programming today would better spend the time to learn it! And not just mechanically learn it but really get to understand how things work and why they're usefull. I've seen people with a university degree in software development that sometimes have a hard time grasping the concepts of OOP and have trouble using OOP libraries to the max because of that.

[bryan922]

I mostly agree with you bryan922, just wanted to make it clear that C is grate for low level programming but it also stops there: it's not an effective language for other kinds of applications.

I'm going to have to disagree with you on that. I respect your view on what is and what is not effective for lots of applications, but I certainly believe that many others believe C is effective for midsize applications.

As an aside, I think C++ applications and C++ APIs would be cleaner, easier to read, easier to code in, and the code would be more terse and elegant if OOP was ditched, but leaving in operator overloading and function overloading.

Consider functions to intersect geometrical objects, including spheres, triangles and rays:

Code: [Select]

// In C:

if( intersect_ray_tri( ray, tri, &t )) {
    ...
}

if( intersect_ray_sphere( ray, sphere, &t )) {
    ...
}

// In C++ without OOP:

if( intersect( ray, tri, &t )) {
    ...
}

if( intersect( ray, sphere, &t )) {
    ...
}

// In C++ with OOP:

if( ray->intersect( sphere, &t )) {
    ...
}

if( ray->intersect( tri, &t )) {
    ...
}
I find the pointer referencing of object methods to be ugly and unnecessary, yet it is done all the time in C++ APIs. Calling intersect( ray, tri ) is an elegant way of coding what you mean. Calling ray->intersect( sphere ) is just plain ugly.

Object oriented methods are perfectly feasible using C - you just need to be structured in how you code. It boils down to programmer experience.

I will grant the productivity (mostly gained through easier to read code) gained by judicious use of operator overloading and function overloading, as indicated by the intersect function above, using C++ without objects.

Unfortunately, I have never been witness to a beautifully written C++ API, but rather have been victimized by C++ APIs that make their use unpleasant through inheritance, which forces one to often dig back up the chain of objects to understand what the hell you're working with.

Few things beat a well written C API. Interestingly, look in a post above for C#'s ugly hello world program vs. the C version.

C++ has such potential, if it was just used properly in my opinion, instead of abused of every feature it has. There are other monstrosities of computer languages as well. Perl comes to mind - great for scanning text files, but what an inconsistent set of syntactical rules. The idea of Lisp is so elegant, code as data and macros which allow you to run code at compile time - but a Lisp program doesn't become easy to read until the programmer has effectively built the mini-domain language for his problem - at which point Lisp becomes a true joy to behold. Haskell, well, I don't understand how Haskell evolved to become a language to teach programming, because it is so far out in left field. PHP - not really elegant in my opinion, but it gets the job done - more C++ style ugly object coding. Python - not bad, but why is it so much slower than other interpreted languages?

Anyway, cosminprund is certainly a more experienced C++ programmer than me, so he makes some good points, but I just enjoy the purity of C.

[cosminprund]

What would be left if you ditched OOP from C++? How can you possibly implement operator overloading or function overloading without an object? What is it that you don't like about the "->" operator? Are you sure you're not confusing overloading methods with overriding methods?

You say calling:

Code: [Select]

intersect(ray,tri)
is more elegant then

Code: [Select]

calling ray->intersect(sphere)
because the second example uses "pointer referencing of object method". That's just not true. The second function call is equivalent to:

Code: [Select]

TGeometricEngine_Intersect(shpere,Self)
In other words you're using a plain method, not a pointer to a method. It's just that the given method has an implied extra parameter.

And of course you can use plain C to write code and use OOP techniques. The first C++ compilers would generate plain C code and then the plain C code would get compiled to generate the program. I also used OOP techniques to write "OOP" code as stored procedures in an SQL database (Firebird Database if you want to know). The stored procedure language is purely procedural and has no notion of pointers, yet I was able to use OOP techniques with it. THAT DOESN'T MEAN A THING! Just because you ca do it with C or ASM doesn't mean you should do it!

Please understand I don't assume everyone should do C++ or OOP. It's just that OOP is one of the most powerfull paradigms for writing software available today and it shouldn't be ignored. AFTER one understands what OOP is all about then they can decide not to use it. But if one decides not to use OOP without even learning OOP then they're putting themselves at risk: In today's concurential world you need to stay on top. If you're not using the best tool for the job, someone else will use it and get your market share.

[geek1]

I have read everyone's replys and have another question. For robotics, is C fine or should I switch to C++?

[paulstreats]

C is the language for programming robots at the minute. (as soon as better control boards are made to allow OOP this would be in my opinion a good addition).

OOP languages like java are called performance languages (where previously languages like C were thought of as research style langauges). What makes java etc so difficult to get to grips with is that nearly everything is done for you. Rather than using C to make a button (drawing the button writing mouse intersect code etc...) all you have to do is declare one i.e. Button newButton = new Button("im a button"). There are even button factories to send them through to change their look and feel. Or you can declare one with an imageIcon to create a customised one.

This means having to have endless amounts of reference documentation and gives you the feeling that youre not really in control. The good point is that you can create a fully functioning user interface in 1 hour as opposed to 1 week with other languages.

[izua]

OOP languages like java are called performance languages (where previously languages like C were thought of as research style langauges).

I think they are called High level languages, not performance. Because languages like java and C# have the worst performance.
The more you move stuff into the abstract, the more of a burden is on the cpu

[paulstreats]

Theyre called performance languages because programmers are supposed to use them to perform (spend their time actually making the program rather than seeing how far they can push the language). This was the first thing I learnt on my java course.

Just for reference, does anybody know what the java virtual machine or intermediary platform is programmed in?

[bryan922]

What would be left if you ditched OOP from C++? How can you possibly implement operator overloading or function overloading without an object? What is it that you don't like about the "->" operator? Are you sure you're not confusing overloading methods with overriding methods?

True, you need to use what C++ terms an object to do function overloading, but that's a semantic issue that boils down to use of terminology. There is nothing about the conceptual components of function overloading within the realm of computer science that require one to adopt an OOP paradigm with regard to creating function overloading in a language. Function overloading, in its essence, boils down to a compiler detecting the argument types. It is C++'s choice to entangle that with OOP, which outside of C++, conceptually refers to objects which have methods and can inherit.

Just because you ca do it with C or ASM doesn't mean you should do it!

Actually, you should adopt some form of loose OOP methodology in many instances when using C. Just because a language does not provide a set of syntactical features to do certain things does not mean you should not employ certain paradigms. The ultimate example is Lisp, which provides no syntactical features at all, and thus frees the programmer to develop his own paradigm of programming which best suits the domain of the problem, and the result is a min-language with its own set of syntactical features which suits the problem - mostly doable because of the power of the Lisp macro.

I believe C++ is a bloated dog that has become an industry standard for not all the right reasons. Entrenchment in the industry often exists because of its meme like replication. Once in, its hard to remove.

[hgordon]

Just for reference, does anybody know what the java virtual machine or intermediary platform is programmed in?

Portions of the Sun jvm that aren't written in java appear to be written in C++ (see openjdk.java.net).  There is a non-Sun version of Java called Kaffe (kaffe.org) that is written in C.

[bryan922]

I have read everyone's replys and have another question. For robotics, is C fine or should I switch to C++?

No, because you can't. You would need a C++ compiler for the processor, and they mostly don't exist.

However, if you use something like a PC/104 board (PC on a board) or your robot is connected to a PC, then, if you want to develop your host application (which resides on the PC) in C++, then  by all means, do so.

[cosminprund]

True, you need to use what C++ terms an object to do function overloading, but that's a semantic issue that boils down to use of terminology. There is nothing about the conceptual components of function overloading within the realm of computer science that require one to adopt an OOP paradigm with regard to creating function overloading in a language. Function overloading, in its essence, boils down to a compiler detecting the argument types. It is C++'s choice to entangle that with OOP, which outside of C++, conceptually refers to objects which have methods and can inherit.

Please help me understand. By function overloading you mean something like this:

Code: [Select]

int func1(int x) {
    return x;
};

int func1(double x) {
    return 0;
}
... and then have the compiler choose between the two based on the type of the RVALUE you're actually passing. Well I've got good news for you, that code up there is perfectly correct C++ code that used overloading for global functions (not part of an object). It compiles without warnings and produces the expected results. When you were talking about method overloading I honestly thought you were confusing overloading with overriding as overriding is what's interesting about OOP, not overloading.

I also believe you're comparing Apples to Oranges when you're comparing C++ to Lisp - Lisp is an interpreted language and that's where all the interesting sintax comes from. I know there are compilers for Lisp but apparently you loose most of what makes Lisp by writing code that's compileable (ex: You need to use type declaration for everything you use!). There's an other issue: You apparently don't like Perl because of it's inconsistent syntactical rules but you like Lisp because you can define your own syntactical rules (by creating your own domain-specific programming language).

I've said it and I repeat it. I've got no problem with all the other programming paradigms and - in fact - I enjoy learning about new programming languages and ideas. I believe that every single one of those programming languages has it's own place. If you insist on bashing C++ do it with the right arguments! Example: C++ is annoying because it's an type-checked language that limits one's creativity for the sake of noobs (that's one of the arguments used by Ruby people)

[Webbot]

No, because you can't. You would need a C++ compiler for the processor, and they mostly don't exist.

Assuming that, like most of us, you are using the FREE avr gnu compiler -then it also copes with C++ - see my Members Tutorial

[cosminprund]

Assuming that, like most of us, you are using the FREE avr gnu compiler -then it also copes with C++ - see my Members Tutorial

Can you put a link to your tutorial here? I'm trying to locate it in this list but can't find it:
http://www.societyofrobots.com/member_tutorials/taxonomy/term/1?sort=asc&order=Author

Thanks.

[bryan922]

Please help me understand. By function overloading you mean something like this:

Code: [Select]

int func1(int x) {
    return x;
};

int func1(double x) {
    return 0;
}
... and then have the compiler choose between the two based on the type of the RVALUE you're actually passing. Well I've got good news for you, that code up there is perfectly correct C++ code that used overloading for global functions (not part of an object). It compiles without warnings and produces the expected results. When you were talking about method overloading I honestly thought you were confusing overloading with overriding as overriding is what's interesting about OOP, not overloading.

Yes, you are correct. As I said in my original post, operator overloading and function overloading are desirable features. I was very clear in my original post. I believe it was you who confused the issue and myself (because I am indeed not as knowledgeable about C++ as you) as well. I clearly stated:

As an aside, I think C++ applications and C++ APIs would be cleaner, easier to read, easier to code in, and the code would be more terse and elegant if OOP was ditched, but leaving in operator overloading and function overloading.

In retrospect though, it appears that I did indeed have it right about function overloading being independent of objects, and thus I can only strongly back up what I originally said.

I also believe you're comparing Apples to Oranges when you're comparing C++ to Lisp - Lisp is an interpreted language and that's where all the interesting sintax comes from. I know there are compilers for Lisp but apparently you loose most of what makes Lisp by writing code that's compileable (ex: You need to use type declaration for everything you use!).

That isn't true. Lisp by definition is not interpreted, and Lisp incarnations which compile do not give up features of Lisp. In fact, by definition, Lisp contains a function called 'compile', which will compile any piece of Lisp code, assuming the Lisp implementation has implemented the function to its fullest potential. Take a look at Corman Lisp, for one incarnation. Surprisingly, Lisp benchmarks at often only about half the speed of C, which an interpreted language could never do. Lisp's major shortcoming is the overhead to put a program in memory, because of the Lisp core support required (of which one component isn't necessarily an interpreter, but a compiler).

There's an other issue: You apparently don't like Perl because of it's inconsistent syntactical rules but you like Lisp because you can define your own syntactical rules (by creating your own domain-specific programming language).

Having the ability to define your own syntax, which is an extension of creating an elegant code library or API, in a way, does not mean that one must create a language (or library) that exhibits inconsistent syntactical structures, as exists in Perl's native syntax. Take a look at Perl's sorting functions, for one. You are wrongly assuming that building a unique (yet syntactically consistent  language) is the same as using and liking a language that exhibits inconsistent syntactical structures and methods.

I've said it and I repeat it. I've got no problem with all the other programming paradigms and - in fact - I enjoy learning about new programming languages and ideas. I believe that every single one of those programming languages has it's own place. If you insist on bashing C++ do it with the right arguments! Example: C++ is annoying because it's an type-checked language that limits one's creativity for the sake of noobs (that's one of the arguments used by Ruby people)

I really don't believe I'm bashing C++ moreso than a large base of existing programmers already have. It's common knowledge that C++ is a bloated beast with complex and often obtuse inner workings that does often translate to abuse of said features.

Furthermore, with regard to calling object methods, regardless of language (PHP, Java, C++, and others), I remain firm that the resulting code is ugly: ray->intersect( sphere ).

ray->intersect( sphere ) is in my opinion, not as readable as a straight overloaded function: intersect( ray, sphere ). This may sound like nitpicking, but I think the pointer operator creates a jarring disconnect to smooth reading of code. It doesn't necessarily reduce the speed of comprehension, but it introduces two extra characters, and an extra syntactical component that is overused. At its heart, we are doing something procedural, which proponents of OOP have overly taught, is inferior to OOP. This notion is flat out silly. Intersecting two things is a procedural task - there is no way around that. The mind in fact thinks this way - we think about intersect testing the two objects. Furthermore, intersecting is, in general a binary operation, which means the commonality is the procedure, not the object. In OOP, we are trained to think how the object operates on the world. So yes, a ray operates on a sphere by intersecting it, but, alas, what of the sphere? Does not the sphere operate on the ray by intersecting it? Now the API developer has to choose, and the API user must adopt the coder's choosing. Nitpicking again? Not at all. Intersecting two geometrical objects is a procedural event between two objects, and is best addressed by looking at it that way.

OOP is overused and imposed where it needn't be because people are being taught to overuse OOP. No way around it.

[Webbot]

Assuming that, like most of us, you are using the FREE avr gnu compiler -then it also copes with C++ - see my Members Tutorial

Can you put a link to your tutorial here? I'm trying to locate it in this list but can't find it:
http://www.societyofrobots.com/member_tutorials/taxonomy/term/1?sort=asc&order=Author

Thanks.

http://www.societyofrobots.com/member_tutorials/node/108 Soon to be updated with various new sensors, software PWM etc

[Webbot]

This thread seems to be going rapidly down hill !! And I'm sure we've had this 'battle of the languages' debate before.

Some folk are seeking advice and others are responding with 'strongly felt' personal feelings - and so it is turning into a battle of the languages - and everyone wants 'one winner'.

It won't happen.

Why use assembler:-
a -  it is very fast
b -  it is complied 'as is' regardless of any C compiler optimisation.
So

void loop(uint8_t delay){
      __asm__ volatile (
         "1: dec %0" "\n\t"
         "brne 1b"
         : "=r" (delay)
         : "0" (delay)
      );
}


Will always delay - based on the passed parameter and the microprocessor clock speed- irrespective of compiler optimisation settings. NO other language can do this. So assembly is great for time sensitive, or core, procedures.


Standard C is one level above this - and may call assembly routines for any time critical stuff. So far so good. But C is not namespace aware - by which I mean: lets assume that you have a servo and a DC motor H-Bridge. Both may need a 'setSpeed' method. Using C you would need to mangle the name into:-
Servo_setSpeed(50);
Motor_setSpeed(50);
so as to avoid a clash on naming conventions.

@bryan922: This answers your point: ray->intersect( sphere ) is in my opinion, not as readable as a straight overloaded function: intersect( ray, sphere ). If you disagree: then refer to ANY oop programming language!!  Your 'intersect' method of a ray and a sphere would return a 3D point. The former example is much more obvious - if you disagree then what would: intersect( sphere1, sphere2) actually return - it sure as hell isn't a point? - and given your prefered syntax then there is little chance that the compiler could realise that this code is obviously junk?

For those of you who wish to continue to 'diss' C++ then don't forget that early C++ compilers would turn the code into C (using struct contructs) and then compile the C program. So if you think C++ is rubbish then, by implication, you think C is rubbish.

So comparing C and C++. In C++ you can write a single I/O pin class that can be re-used across the 40 I/o pins you are using with NO additional code- whereas in C (when not using structs) you have to copy and paste the code 40 times.

C++ needs to be constrained slightly in a microprocessor environment as it needs to be closely mapped to the hardware. ie if you create a 16 bit timer class in  C++ then you cannot create 100 instances of timers on an ATMega8.

But the BIG benefit of C++ is that you can create a library for Servos, Motors, Sensors etc etc which is object orientated - but can be called from a 'main' that is written in C. So for all you AVRlib users out there - you just call it - you don't care whether its in assembler, C, C++, Java or MiltonKeynes409. And that is how programming should be.

If the library works - then you have no excuse about making your code work (irrespective of language).

If anyone wants an 'email fight' then I'm up for it. I've been using assembler since about 1977 (4 bit processors to 64 bit), C since about 1987, C++ since about 1990 and Java (web, EJB etc) since about 1998 - using ALL of these for either computer games, fun, or business systems - but have written commercial systems in all of them. They all have their own strengths and weaknesses

[cosminprund]

@Webbot
Thank's for the link.

@bryan922

That isn't true. Lisp by definition is not interpreted, and Lisp incarnations which compile do not give up features of Lisp. In fact, by definition, Lisp contains a function called 'compile', which will compile any piece of Lisp code, assuming the Lisp implementation has implemented the function to its fullest potential.

Lisp's "compile" functions compiles what it would normally interpret into something that's called "implementation specific" - with no more details. Some compilers may do "further compilation" including generate machine-specific code. Right. It's like calling Java an compiled language simply because it has an compiler. If you put it that way allmost any language may have a compiler! Back in the DOS days I used an compiler that compiled BAT files to COM files. Let's call Microsoft command interpreter an compiled language then!

Here's an other idea. Take a look at this link: http://clisp.cons.org/summary.html It's a link to CLISP, an free GNU-ed LISP implementation. Go there and click on the "Compiler" link - you'll be sent to a page titled "Chapter 37. The CLISP bytecode specification".

Surprisingly, Lisp benchmarks at often only about half the speed of C, which an interpreted language could never do.

Where did you get that? The Corman Lisp's kernel you're talking about is actually an "C" program itself! Here's quote from http://www.cormanlisp.com/CormanLisp/CormanLisp.pdf page 22:

The Corman Lisp kernel is written in C/C++/x86 assembler

Since an Lisp program requires the kernel to run, and the kernel is written in "C", isn't the final Lisp "compiled" program actually an "C" program doing something with some bytecode? If that's faster then a native "C" implementation then there must be a problem with the "C" implementation.

Since I don't want to start a flame-war, I'm not going to post any more replies here.

[bryan922]

Webbot,
In every case I can think of, intersect returns a boolean. Every single case. The 3d point (or 2d point), or ray's parameter value t, or anything else, is, in every single case I have ever seen, an additional argument pointer. Such code is always written:

if( intersect( ... )) {
    ....
}

Considering I wrote my first ray tracer in 1987 (on an Amiga) and have studied 3d graphics on and off ever since, I am not unfamiliar with said territory.

cosminprund,
I too don't wish to argue anymore. However, you are incorrect in your interpretation of how Lisp is compiled. We all know an interpreter or compiler is written in some language, and likely compiled, and executes, either at run time or compile time. Let's be clear. We both know the difference between an interpreted language and a compiled language. I would not insult your intelligence by assuming you don't know the difference. Like Webbot, I too have been programming in C since 1987.

Some Lisp implementations compile to machine native code. Let's be clear on what that means: That means that the Lisp compiler (on some implementations) is building machine code when it compiles code - NOT running machine code at run time that was embedded in the compiler/interpreter at the time the compiler/interpreter was compiled, although that occurs too at various times.

For example, be my guest in dissecting this statement found at http://www.cons.org/cmucl/ where CMUCL is described as:

a sophisticated native-code compiler which is capable of powerful type inferences, and generates code competitive in speed with C compilers.

Regarding Corman Lisp and the PDF document you linked to: did you read the section on compilation? More to the point, have you inspected the compiled code, and ran tests?

Let me be clear on one last point: C++ has power and flexibility, I will grant that. However, OOP is not the panacea it is purported to be - it is overused, and is not always the best fit to programming problems, and it is often imposed by developers onto problems that gain little by it.

[bryan922]

For those of you who wish to continue to 'diss' C++ then don't forget that early C++ compilers would turn the code into C (using struct contructs) and then compile the C program. So if you think C++ is rubbish then, by implication, you think C is rubbish.

For the benefit of the readers here who are not familiar with C and C++, I'd like to point out that such arguments, as above, hold zero water. I do not like it when such statements are made.

To deflate the above argument (and I would not feel compelled to do so if you hadn't made it), all I need to do is point out that I could design a very very bad language, but as long as it could, in theory compile on any Turing compliant machine, I could also get it to compile to C code. And by virtue of that, your above argument makes no case as to whether C is 'rubbish' due to whether C++ is 'rubbish' or not.

Furthermore, C++ is not necessarily rubbish. But the overuse of OOP in most C++ APIs is, at times, a little excessive and rubbish-like.

Please, I have been quite clear in what I have been saying, and I have made mistakes, but not generally with regard to where my statements are being attacked. For example, I concede that any processor which is supported by gcc should allow C++ programming, whereas I said that only a C compiler would do.

[Webbot]

In every case I can think of, intersect returns a boolean. Every single case. The 3d point (or 2d point), or ray's parameter value t, or anything else, is, in every single case I have ever seen, an additional argument pointer. Such code is always written:

if( intersect( ... )) {
    ....
}

Considering I wrote my first ray tracer in 1987 (on an Amiga) and have studied 3d graphics on and off ever since, I am not unfamiliar with said territory.

Yawn 1987 - that late! - my ray tracer was in 1983 on a BBC Model B  back when I was writing computer games for a living. So I'd also like to think I know vaguely what I'm talking about. Having converted from 6502 assembler (which is procedural like C, Basic, Algol etc) to OOP then the 'shape->intersects(ray,..)' signature is far more helpful. Complex shapes like bicubic splines, or even triangle meshes, can best be tested first by intersection with simpler bounding shapes be they spheres, cubes etc. Your criticism of good/bad design seems to suggest whether you make a spline inherit from its bounding shape or whether you use an internal variable to represent the bounding shape. This is an implementation issue - not a language issue. Yes - we could all write bad code.

Re-writing everything from oop 'shape1->intersects(shape2)' into 'intersects(shape1,shape2)', when there are many different shapes, is surely just replacing virtual methods with operator overloading and makes the code harder to read and debug as you end up with one monolithic lump of source code. Of course, if you insist on doing this, then you can still do it in C++ anyway if you choose to do so.

Please, I have been quite clear in what I have been saying, and I have made mistakes, but not generally with regard to where my statements are being attacked.

- Enough said

Over and out

[bryan922]

Re-writing everything from oop 'shape1->intersects(shape2)' into 'intersects(shape1,shape2)', when there are many different shapes, is surely just replacing virtual methods with operator overloading and makes the code harder to read and debug as you end up with one monolithic lump of source code. Of course, if you insist on doing this, then you can still do it in C++ anyway if you choose to do so.

Seems to me that introduction of a new geometrical object shouldn't influence an existing object's code. What it does influence in the world is the need for new intersection functionality.

6502 Assembler? Yawn. I have refrained from tooting my horn (and yawning), but you seem to invite it. I programmed in 6502 Assembler long before I learned C.

And since you're clearly the "ray tracing" expert, then why would you ever make a statement that an intersection function between a sphere and a ray would return a 3d point instead of a boolean? Was that to try and win an argument - hoping nobody would call you on it? Or did you just not know?

Over and out indeed. Please, no more.

[Admin]

I have read everyone's replys and have another question. For robotics, is C fine or should I switch to C++?

If it means anything to you, Admin started with basic, moved on to C++ for more advanced features, then finally settled on C as my preferred language for microcontrollers.

If I were to program for a PC I'd probably use C++ or Visual Basic. It really depends on the task - use the language best for the task at hand. All languages have their advantages and disadvantages. I prefer languages simple to use with a lot of source code and community support, I don't care for 'optimal' as all of them will work fine for my limited apps.

As for which language is fastest or takes up the least memory or whatever, that's more of a compiler issue. Hypothetically a compiler, that's good enough, can turn C++ to be as efficient as assembly code when compiled. Hypothetically . . .


Anyway, this is a friendly forum, try to be sensitive in your comments. Proving you're an awesome programmer should be limited to the amazing robots you upload on youtube

[geek1]

I have read everyone's replys and have another question. For robotics, is C fine or should I switch to C++?

If it means anything to you, Admin started with basic, moved on to C++ for more advanced features, then finally settled on C as my preferred language for microcontrollers.

If I were to program for a PC I'd probably use C++ or Visual Basic. It really depends on the task - use the language best for the task at hand. All languages have their advantages and disadvantages. I prefer languages simple to use with a lot of source code and community support, I don't care for 'optimal' as all of them will work fine for my limited apps.

As for which language is fastest or takes up the least memory or whatever, that's more of a compiler issue. Hypothetically a compiler, that's good enough, can turn C++ to be as efficient as assembly code when compiled. Hypothetically . . .


Anyway, this is a friendly forum, try to be sensitive in your comments. Proving you're an awesome programmer should be limited to the amazing robots you upload on youtube

What do you mean "Proving you're a awesom programmer"? I actually kind of suck at programming, and was just asking a question, sorry if I offended you.