|
Probably, backward compatibility.
There was a huge reservoir of C libraries back than, and since C++ wasn't a "new language" per se but a superset of C it would have made sense to design it to work with existing code.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
That's a very interesting point, because I just assumed that C's default convention was stdapi. The reason I assumed that is that when you want to export a function from a C++ DLL, you usually enclose the declaration in extern "C".
But I never considered that C's default convention was cdecl.
Well played. 
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Richard Andrew x64 wrote: But I never considered that C's default convention was cdecl.
Hence the name, "cdecl"
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
TheGreatAndPowerfulOz wrote: Hence the name, "cdecl"
And that's why I come to this board! I always learn something interesting.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
extern "C" indicates that C++ name mangling should not be used - just the plain function name, not decorated with the types of the function arguments for overload resolution.
|
|
|
|
|
Your partly correct, indeed it indicates that C++ name mangling should not be used. But this does not mean plain function names. It's mangling the way c get's mangled. For example a function returning a 32 bit int would be something like function@4 and if u take stdcall c function by a microsoft vc compiler u often get even more mangling on the function name.
|
|
|
|
|
It is the opposite, *they* did the OS the wrong way.
|
|
|
|
|
The reasons are mostly historical. The cdecl convention allows for variable-length parameter lists (as required by the printf and scanf families, etc.). For all I know, it may also have been more efficient on the PDP-8 and -11, which were first used to run C.
In order to maintain binary compatibility with C libraries, many C++ compilers also adopted the cdecl convention as default.
Windows 1.0 was originally compiled to use the cdecl convention. Microsoft discovered that the executables would be smaller with the pascal convention (and, IIRC correctly, fit on one less diskette), so they switched.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Daniel Pfeffer wrote: so they switched.
bad decision
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
When Windows 1.0 was released, most PCs used 8088s. A high-performance machine used an 80286, and the 80386 was just coming on the market. We looked for every possible way to eke out some extra performance. Microsoft's decision made sense at the time from both the technical and the production standpoints - saving three bytes and one instruction for each function call, and shipping Windows on one less diskette.
Windows was from the beginning designed to be programmed in C. Unless you were writing code in Assembly language (mostly device drivers), the difference between the calling conventions was handled by the compiler and so was transparent to the programmer. At the C level, it makes no more difference than big-endian vs. little-endian.
(Now, let the Religious Wars resume... )
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Very good information!
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Quote: Windows was from the beginning designed to be programmed in C.
That is true if you never opened a window before it became 32 bits.
The native calling convention of the original 16 bits Windows was the Pascal way of doing it.
|
|
|
|
|
- The Windows SDK was always published first in C. If any ports to other languages occurred (e.g. Borland's Borland Pascal), they were delayed by some months.
- As my OP said, the calling convention is handled by the C compiler, so unless you are programming in Assembly language, it is irrelevant.
I stand by my statement.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
C++ has no default calling convention; it is implementation defined.
MSDN states msvc uses cdecl by default. However, on x64, __fastcall is used unless there are variable number of arguments.
Also note that while Win32 uses __stdcall by default for it's APIs, this is not mandatory for operating systems.
|
|
|
|
|
I thought C++ preferred stdcall, whereas C was always cdecl.
Fast call is a head f*** though, using registers for the first arguments!
|
|
|
|
|
Read reply of every single one and it was nice that people still care about it. Just as you can drive either on Left side or on Right side of road, in computer world, there are two primary directions to read or write data from. For higher level languages, compiler encapsulates all this complexity and provides user a neat option to switch the calling conventions. C language adopted PDP convention as its de-facto and coined the term cdecl to encapsulate the idea. The original name for opposite calling convention was PASCAL and if you go thru some old Windows API books, you will find that word.
all over the place. cdecl convention allows variadic parameters very easily whereas PASCAL convention makes stack management easier.
Reason why cdecl causes generates more code is usually because the underlying hardware has opposite convention and hence the compiler has to emit more opcodes to compensate for it.
|
|
|
|
|
Quote: Reason why cdecl causes generates more code is usually because the underlying hardware has opposite convention and hence the compiler has to emit more opcodes to compensate for it.
x86 specific, RISC architectures probably have similar constraints for registers used to push arguments.
cdecl causes more code because the caller is responsible for cleaning up the pushed arguments.
Since cdecl allows variable argument count, only the caller knows how many arguments were actually pushed.
printf("Hello", unused1, unused2);
Hence the extra instruction mentioned on another post; after the call returns, the stack must be adjusted to remove the pushed arguments.
std call/Pascal is a fixed argument list and the callee can adjust the argument list.
On the x86 processers, "return from subroutine" has a form that allows for the stack to be adjusted to remove the pushed arguments. The std call/Pascal convention used this form to "return and adjust" as a single opcode + operand.
|
|
|
|
|
C-compatibility. Loads of issues with C++ stem from C-compatibility.
|
|
|
|
|
C existed during 16 bit period and I am almost sure that RET instruction did not take argument back then. Your computer most likely start in real mode, which is 16 bit, so it is still in use today. I suppose that is why they do not want to change the calling convention.
P.S. fastcall prolog is usually optimized (under /O2 or more) to use arguments directly from registers when possible.
|
|
|
|
|
Something that I have been doing for years is actually reading licenses for software that I use and that companies use. This goes all the way back to when books were the only real source for code.
I have never worked with anyone else that does this. Even met a few people that seemed to think it was a waste of time.
Yet I do occasionally find problems with the code that is being used.
My perception over the last 10 years is that it has really gotten out of hand because people start importing libraries that in total might encompass hundreds of other libraries.
And then something like the following comes along that makes it much more relevant to understand that a library that seems like a good idea to include might require actually paying someone for it.
The Commons Clause will destroy open source | Drew DeVault’s Blog[^]
Note that the article above does not call out that this new license does not restrict it to just products but also services.
|
|
|
|
|
It's just such a hugely complicated topic...
Some of those licenses are pages long legalese that takes years of experience to understand.
I do try to figure out if some library is ok for me to use, so recently I came across some GNU license.
Here's the problem, GNU, as I understand it, is free for all to use for whatever they want (so what are the differences with MIT?).
However, my license wasn't GNU, it was GNUx (whatever x was), meaning that I should put a disclaimer with my software and source code.
The program I was working on was a closed source back-end service that no one would ever see.
Do I still need to put the license with it, where should I put it, can I use it at all?
If only it ended there.
The GNUx license was for the "free" version if the software.
I could buy a software license which would give me full rights to use the software, however, I wanted without the need for a disclaimer, but why would I because, as I said, no one would see the disclaimer anyway.
But wait, the license seemed to be necessary for any commercial product, but then what happened to GNUx which only required me to add a disclaimer?
Some parts of the library were GNU, others GNUx, then there are different versions of GNU and there's also GNUy and GNUz.
And what about software without licenses!
And next to licenses there are copyrights, which is restricted by law even if an individual doesn't agree.
Now I had to deal with a single library, but if you deal with multiple libraries and all those libraries reference a thousand other libraries you can only hope you're not breaking some kind of license/copyright law.
Meanwhile, my boss wants the code shipped by the end of the week.
In the end, I found some MIT licensed alternative.
As I understand it MIT is always completely free with all rights as if you wrote the code yourself.
But what if I didn't?
Who's ever going to find out my closed source back-end API is using some library with proprietary code? 
My guess is no one unless the library has some code that checks for licenses (which you can even remove if it's not compiled).
So yeah, I can see how people just don't want to go through all that hassle and can then say "we think it's ok to use this software, but we should hire a lawyer to make sure."
|
|
|
|
|
Sander Rossel wrote: Do I still need to put the license with it, where should I put it, can I use it at all?
Based on what you described - no.
The addition of the license is when you distribute the code. So if you decided to sell your server rather than just provide a service from it then you would need to include it as part of that sale.
Sander Rossel wrote:
And what about software without licenses!
Simple - don't use them. They are usually covered by copyright. So you must negotiate with the author always.
You can ask however and they might agree that you can use it any way you want. If that happens you MUST keep what the author sent you. I usually just check it into the source as a file with a note that explains it.
Sander Rossel wrote: Who's ever going to find out my closed source back-end API is using some library with proprietary code?
The scenario is as follows.
- You get sued (civil case) because it was decided that you were violating a license.
- You lose or settle.
- As part of that you agree to a software audit of everything associated with your business.
- They find the code and presumably others.
- For each invalid licensed code, by settlement, you would be required to buy a license and pay an agreed upon amount on top of that.
|
|
|
|
|
jschell wrote: Simple - don't use them.
The problem here is often that the author of the code has no clue about licenses or copyright either.
They'll create a repository on GitHub and assume it's now open source.
jschell wrote: The scenario is as follows.
- You get sued (civil case) because it was decided that you were violating a license.
But how would they know that in the first place?
In my eight years in the industry, I've never seen a code audit.
And even if there is an audit, are they going to check all of our repositories, all with thousands of dependencies?
Or only the ones we consciously downloaded, like jQuery and Angular?
And what happens if I use library x that has an MIT license, but library x uses library y which has a less permissive license and so library x isn't really MIT, but something else.
Should I check if library x is really MIT or if they are in violation with any of their dependencies?
When I download and use library x I also (often unknowingly) download and use library y and so I'm restricted by their license, which I don't know about because the authors of library x are lying to me.
I have no idea how often this happens (because I never check the thousands of dependencies in the libraries I use), but I can imagine this is happening on a rather large scale.
I'm not saying we should all ignore licenses, but I can see how many people have no idea what to do.
Especially if you're not really aware of licensing in the first place.
If it's on the internet and you can download and use it (through npm, NuGet, Maven...) it's free, right?
Simply put, we're programmers, not lawyers.
It's like the law says "every citizen should know the law" (so "I didn't know" isn't a valid excuse in court).
If it was that easy we didn't need lawyers, judges, and four to five-year college studies.
|
|
|
|
|
This is why large organizations (the ones with deep pockets, worth suing) (a) require their programmers to document any open-source libraries that they use, (b) use software, updated regularly, that scans the source code and ensures that no libraries with toxic licenses are used, and (c) have lawyers that vet the licenses of any libraries.
For example, if you are writing proprietary software, any GPL source code is toxic - including it in your source code base would require you to publish the source code of your proprietary package.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Those aren't the organizations I work for.
My current organization has a faint idea that somewhere they have a room full of contractors who are writing their software for them 
The (in-house?) IT manager was opposed to Azure because he wanted the software "in de cloud".
The CEO, late in the project, decided that since one of his other companies uses two or three of the same services we needed to use their application (which, other than those few services, is a completely different product).
With that kind of ignorance going around really no one is worrying about licenses.
Heck, I don't even think they know what they are.
Luckily, there's a coworker and me who read licenses until we give up and decide to use something else
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
