...

View Full Version : Is C+ a language?



Deacon Frost
07-20-2009, 01:44 AM
I have a guy on a team of mine who says he knows "C+". I've always remembered C+ not even being in existence... and mocking people who claimed to know it O.o?


C+

Wtf is that?

Simular to C++ but it deals solely on gaming with HTML

Wow O.o. I've seriously never heard of it :P.

I teach you some day young grasshopper


And, I'm pretty sure it's non-existent. I mean, it sounds like... a web language? Because it deals with markup?

Wtf is it?

Dunna
07-20-2009, 03:00 AM
No such thing, completely fictional. If you know anything about programming you should recognize the syntax:


int i = 1;
i++;
// i Now = 2, as ++ is the post-fix increment operator
if (i == 2)
MessageBoxA(NULL, "Wow, I'm not retarted.", "Congratulations, me.", MB_OK);
else
MessageBoxA(NULL, "C+ is a language.", "I believe in fairies and religion.", MB_ABORTMYLIFE);


Sorry for the rampant sarcasm, had a little too much wine....

oracleguy
07-20-2009, 05:01 AM
Yeah, it doesn't exist, at least not relating to C or C++. Some people thing that because C++ has two pluses there had to be a C+, which isn't true. (The two pluses coming from the C syntax meaning increment by one)

Also see: http://en.wikipedia.org/wiki/C%2B%2B#Etymology

The only language that ever had c+ in the name isn't related to C++.

Deacon Frost
07-20-2009, 06:26 AM
Yeah, it doesn't exist, at least not relating to C or C++. Some people thing that because C++ has two pluses there had to be a C+, which isn't true. (The two pluses coming from the C syntax meaning increment by one)

Also see: http://en.wikipedia.org/wiki/C%2B%2B#Etymology

The only language that ever had c+ in the name isn't related to C++.

Wait, so C+ does exist, just not in relation to C/C++?

And yeah, I kinda figured it was ++ because of increment.

oracleguy
07-20-2009, 07:13 AM
Wait, so C+ does exist, just not in relation to C/C++?

And yeah, I kinda figured it was ++ because of increment.

Yes, the actual name is ABCL/c+, but its this funky concurrent language that I bet hardly anyone on the planet even knows muchless practices anymore.

it career
07-20-2009, 07:22 AM
I guess it does exist
http://baetzler.de/humor/c_more_or_less.html .

Trinithis
07-20-2009, 10:26 AM
I guess it does exist
http://baetzler.de/humor/c_more_or_less.html .
That's C+-, not C+ :D

C+ doesn't even show up at Esolang (http://esolangs.org/wiki/Main_Page).

All I guess C+ to be would be: typos, idiots, a joke.

DaiWelsh
07-20-2009, 12:12 PM
All I guess C+ to be would be: typos, idiots, a joke.

Or they meant c# ?

Deacon Frost
07-20-2009, 08:19 PM
Nah, it wasn't a typo :P



Well my whole list?

CSS
C
C+
C++
Java
Cms-2
Action Script
HTML
Apple Script
VBscript
and im great with PhP

( I can read but cant code HLA , High Level Assembly )

I want to learn RSL ( Robot Scripting )
and microcode

But if it DOES actually exist.... where are the reference sheets? Something I can use to learn it, so I can see if he actually knows it :P.

oracleguy
07-20-2009, 09:49 PM
Nah, it wasn't a typo :P

But if it DOES actually exist.... where are the reference sheets? Something I can use to learn it, so I can see if he actually knows it :P.

Ok, with that example, it looks like it is complete BS. Like I said and maybe I didn't make it clear, the only language that ever some times got referenced as c+ was ABCL/c+ (http://en.wikipedia.org/wiki/ABCL/c%2B#ABCL.2Fc.2B) which is utterly and completely unrelated to C++ and I seriously doubt that they were referring to it.

Why don't you ask them what compiler they use for 'C+'? See what they say.


I can read but cant code HLA , High Level Assembly Generally if you know how to read and understand a programming language, you are also at least some what adept at writing it. Since to read and understand the code, you'd have to be familiar with the constructs and syntax, which is what you also need to know to write it.

I've seen people like this before, you are wasting your time trying to prove them wrong. They will never, ever admit to being wrong.

RabidMango
07-22-2009, 11:52 PM
There is obviously no such thing as C+. Sorry to repeat a point already made, but maybe it needs to be put into the right words.

C++ was so-named because the difference in being able to increment a variable with just a double plus was, apparently, quite representative of the overall way in which it improved on C, that's what I read in a big book on it which I probably left in my parents house when i was deciding whether there's anything else in the world outside of Linux and Perl.

i.e. before C++, you had to say $thing=$thing+1;
or something (i forget how other languages write their variables, i just default to perl) whereas thanks to the improvement on C, you could now say $thing++, and save lots of writing.

Consequently it does not make any sense for anything called C+ to exist, it just could not. There would not be any meaning in the name. Hence why the follow-on to C++ wasn't in fact C+++ or C-squared or anything of that nature - they had to just move in a whole new direction.

In case anyone's wondering there is no C-flat to complement C-sharp, either. But I'll trust you guys with a trade secret - the operating system which will replace microsoft and apple and the whole lot of them, to be made by me, built on a foundation of a.i. is to be called "Grapes" - and the reason is that you can pick little nuggets off it one by one and use em. It's an o.s. that works in bunches. Lovely stuff. Eg if you want to build a system to do something, you pick a grape here and a grape there - one for making a window that does x or y, one for making a file-saving function that does z or p - you get the idea. Hell, maybe I'll start working on it this week. Nah. I've got less important things to do, may as well get on with those, in keeping with the law of dynamic negatives.

oracleguy
07-23-2009, 12:27 AM
i.e. before C++, you had to say $thing=$thing+1;
or something (i forget how other languages write their variables, i just default to perl) whereas thanks to the improvement on C, you could now say $thing++, and save lots of writing.

That isn't quite accurate, the increment and decrement operators were apart of C before C++. It is a pretty basic instruction that's why there is analog to it in almost every language. In fact in the x86 architecture there is a specific increment processor instruction.


Hence why the follow-on to C++ wasn't in fact C+++ or C-squared or anything of that nature - they had to just move in a whole new direction.

Which follow on would that be? If you are referring to C#, that isn't really a follow on, it is a completely different thing. You could say C# was influenced by C++ in the sense that a lot of the syntax is the same but they are very different languages.

Fou-Lu
07-23-2009, 01:45 AM
C# can be dirty coded as well to include C/C++ (I think its C# that has the dirtycode block in it?). I hate it when people do that >.<

My favorite is how few people seem to know the differences between how ++i versus i++ actually operates. Most of the students I tutor when they come to C are always asking why this doesn't do anything:


void increment(int *ip)
{
*ip++; // doesn't work, they revert to *ip = *ip +1;
}


Nothing beats explaining that it does indeed work as expected, but the final result is overwritten by the original when the stack memory is destroyed. On the otherhand, ++*ip; does work as it should. Best I know, its simply because post increments allocate an under-the-hood temporary variable which it adds one back onto before reassigning it to ip. This of course would take the current scope which is stack not static. I gots that right Kev?

oracleguy
07-23-2009, 05:19 AM
C# can be dirty coded as well to include C/C++ (I think its C# that has the dirtycode block in it?). I hate it when people do that >.<

My favorite is how few people seem to know the differences between how ++i versus i++ actually operates. Most of the students I tutor when they come to C are always asking why this doesn't do anything:


void increment(int *ip)
{
*ip++; // doesn't work, they revert to *ip = *ip +1;
}


Nothing beats explaining that it does indeed work as expected, but the final result is overwritten by the original when the stack memory is destroyed. On the otherhand, ++*ip; does work as it should. Best I know, its simply because post increments allocate an under-the-hood temporary variable which it adds one back onto before reassigning it to ip. This of course would take the current scope which is stack not static. I gots that right Kev?

Yeah, that is the general idea. *ip++ is just a weird bit of coding as far as it can be deceiving on what is actually going on. But since you brought it up I thought I'd show you. I compiled your function into a C program and generated the mixed listing file.

This is with the post operator:


_increment PROC ; COMDAT

; 4 : {

push ebp
mov ebp, esp
sub esp, 64 ; 00000040H
push ebx
push esi
push edi

; 5 : *ip++; // doesn't work, they revert to *ip = *ip +1;

mov eax, DWORD PTR _ip$[ebp]
add eax, 4
mov DWORD PTR _ip$[ebp], eax

; 6 : }

pop edi
pop esi
pop ebx
mov esp, ebp
pop ebp
ret 0
_increment ENDP


Notice how it loads the address into eax and adds 4, that's because you are incrementing the address, not the value at that address.

And with the pre operator:



_increment PROC ; COMDAT

; 4 : {

push ebp
mov ebp, esp
sub esp, 64 ; 00000040H
push ebx
push esi
push edi

; 5 : ++*ip; // doesn't work, they revert to *ip = *ip +1;

mov eax, DWORD PTR _ip$[ebp]
mov ecx, DWORD PTR [eax]
add ecx, 1
mov edx, DWORD PTR _ip$[ebp]
mov DWORD PTR [edx], ecx

; 6 : }

pop edi
pop esi
pop ebx
mov esp, ebp
pop ebp
ret 0
_increment ENDP


Now notice how it uses an additional register, ecx to hold the value after 1 is added. This line mov ecx, DWORD PTR [eax] is where the pointer is being dereferenced.

Now this is a debug build with no optimizations on so it reads in the value of the pointer twice, it could re-use the value in eax instead of using the one in edx.

We've branched a little off topic but it is a cool thing to look at.

DaiWelsh
07-23-2009, 09:32 AM
That isn't quite accurate, the increment and decrement operators were apart of C before C++. It is a pretty basic instruction that's why there is analog to it in almost every language. In fact in the x86 architecture there is a specific increment processor instruction.


+1 (or should that be ++)

From Wikipedia http://en.wikipedia.org/wiki/C%2B%2B



Etymology
According to Stroustrup: "the name signifies the evolutionary nature of the changes from C".[5] During C++'s development period, the language had been referred to as "new C", then "C with Classes". The final name is credited to Rick Mascitti (mid-1983) and was first used in December 1983. When Mascitti was questioned informally in 1992 about the naming, he indicated that it was given in a tongue-in-cheek spirit. It stems from C's "++" operator (which increments the value of a variable) and a common naming convention of using "+" to indicate an enhanced computer program. There is no language called "C plus". ABCL/c+ was the name of an earlier, unrelated programming language.


so that is pretty clear...

OMGLOLZ
10-01-2010, 01:31 AM
C# can be dirty coded as well to include C/C++ (I think its C# that has the dirtycode block in it?). I hate it when people do that >.<

My favorite is how few people seem to know the differences between how ++i versus i++ actually operates. Most of the students I tutor when they come to C are always asking why this doesn't do anything:


void increment(int *ip)
{
*ip++; // doesn't work, they revert to *ip = *ip +1;
}


Nothing beats explaining that it does indeed work as expected, but the final result is overwritten by the original when the stack memory is destroyed. On the otherhand, ++*ip; does work as it should. Best I know, its simply because post increments allocate an under-the-hood temporary variable which it adds one back onto before reassigning it to ip. This of course would take the current scope which is stack not static. I gots that right Kev?

I had to join this forum just to respond to this post, lest actual people trying to learn something from this alleged "tutor" be led astray.

What you describe has nothing to do with the inherent difference between putting "++" before or after the variable, or "under the hood temprorary variables." Rather, it's an order of operation issue.

*ip++ is the same as *(ip++). Hence the pointer is incremented and then dereferenced. At worst, this can lead to a protected memory error if (ip + 1) cannot be dereferenced; at best, it does nothing.

On the other hand, ++*ip is the same as ++(*ip), which increments the original variable as apparently desired. In fact, the same result could be reached with the ++ after the variable -- you would just need to add parentheses as follows: (*ip)++.

Fou-Lu
10-01-2010, 04:35 AM
I had to join this forum just to respond to this post, lest actual people trying to learn something from this alleged "tutor" be led astray.

What you describe has nothing to do with the inherent difference between putting "++" before or after the variable, or "under the hood temprorary variables." Rather, it's an order of operation issue.

*ip++ is the same as *(ip++). Hence the pointer is incremented and then dereferenced. At worst, this can lead to a protected memory error if (ip + 1) cannot be dereferenced; at best, it does nothing.

On the other hand, ++*ip is the same as ++(*ip), which increments the original variable as apparently desired. In fact, the same result could be reached with the ++ after the variable -- you would just need to add parentheses as follows: (*ip)++.

Yep, you are absolutely right. OG and I actually had a conversation about this when I asked if he could explain the assembly to me (still greek >.<), and I determined that my professor was just senile.
Problem was I had that exact issue in class (post increment of an int pointer in a function), and the professor had taught us that dereference had the highest priority under only brackets, subscripts and member access. Because of this, I asked why the above function didn't work (since our instruction had been that *ip would occur before the ++, and not the other way around), and he had explained that it was because it dereferences onto stack memory, increments and writes back. When the stack popped, it lost the changes, and when I asked how it reverted to the original pointer he explained that the original memory locations are preserved when passed to the stack, so are reverted when the stack popped. The way he explained it made sense, he even had drawn a couple of diagrams to explain it. Since he was my professor and I had faith in his abilities, I took him at his word, which I later learned may not have been a great idea. A simple test of my own would have revealed this of course, but I had to put some faith into the instruction I was receiving.

Once I was educated by someone who wasn't senile (lol), I looked up the precedence list for C, and sure enough dereference and unary were listed in the same level and not above it. Since it was right to left assignment, it totally explained why the ++*ip; worked as expected and the *ip++; did not.

Don't worry though, fortunately I was corrected quite early and only one of the students I worked with walked out with this idea. I wasn't too thrilled about it, I assure you; I'm far from perfect, but I do try to learn and confirm before giving advice, but I do jump the gun if I'm fairly certain (and since this is what was taught to me, I assumed that I was correct). This has come up twice since then, and I explained pretty much the same way you have here: increment first, then dereference = unexpected change.
Thanks for bringing this up though, it does give me a chance to correct myself on the forums here since I had completely forgot about this post!



EZ Archive Ads Plugin for vBulletin Copyright 2006 Computer Help Forum