Sure, why not - let's bolt another leg onto that dog ;)
A proposal for named arguments for C++
51–60 of 62 posts
Re: A proposal for named arguments for C++
#52Earlier quoted context omitted.
You can do that with C++ too -- assuming they are conforming to the platform ABI. On Linux, for example, all C++ compilers can call each other's code just fine. You may be thinking of the funny situation on Windows where GCC has historically flagrantly disregarded the platform C++ ABI and implemented its own instead. I assume this decision was made as a matter of practicality: The Cygwin people didn't have the resour…
In all fairness, Microsoft breaks abi in the standard library with every single release. They do so deliberately to reserve the right to improve implementations over time. For some evidence: See an interesting reddit thread: http://www.reddit.com/r/cpp/comments/13zex3/can_vs2010_c_lib... And a link to a msvc blog post which lists the sizes of various containers under various versions of MSVC: http://blogs.msdn.com/b/…
True, but that's a different level of ABI. Stefan is talking about the base language ABI, e.g. calling conventions, vtable layout, etc., which is what matters if you're trying to call C++ from another language. You're talking about the ABI of the standard library -- or, more accurately, any library that uses STL types in its interface (which probably disqualifies it from being called from another language anyway).
Re: A proposal for named arguments for C++
#53Earlier quoted context omitted.
Nonsense. C doesn't even define the width of an int, without which an ABI makes no sense. An ABI is a property of a specific target platform (architecture and possibly OS); every platform defines its own. Windows and Linux on x86_64 don't even use the same ABI (the width of "long" is different, for starters). But both platforms have C++ ABIs just as much as they have C ABIs. The problem with C++ ABIs is that C++ A P…
It's certainly not cross-platform, but in practice you can call C libraries on a given platform the same way, regardless of which compiler generated them.
So why are you asking that the standards committee do it?
Re: A proposal for named arguments for C++
#54This might sound negative, but I'm really curious why this is needed if you have an IDE that tells your the parameter names as you're typing and in a mouseover. If you need it to be more visible, make that a feature in the IDE to show you the parameter names all the time. Why change the language? Not only that, but why are you passing so many parameters like top, bottom, left, right? At least put them in a struct if…
Optional named parameters with default values can make nice clean calls in the common case while still allowing for the uncommon case. As far as the IDE goes, for the sort of code I write, reading is more important than writing. When I read the code I'd rather see what it does than what I think it does.
VB used to allow you to omit optional parameters by just leaving it blank
foo(36,,,54)
sure it won't do if there are dozens but for the odd ugly case where you naughtily use optional parameters it's OK.
It sounds like there's a need for IDEs to show the parameter names all the time. They could just be inserted automatically into the display if you want to see them, or turn them off if you don't like that. Better than being always on like this proposal.
Re: A proposal for named arguments for C++
#55What's the argument against, well, named arguments? Is it a matter of brevity versus verbosity?
The problem is that all the names of parameters in every header file suddenly become enshrined as part of the API. You end up having to remove the names from all the system header files or first standardise their names. Otherwise, you'll quickly find code starts appearing that assumes the names as they are on Linux will then not build on BSD, Solaris etc.
Re: A proposal for named arguments for C++
#56Earlier quoted context omitted.
It's certainly not cross-platform, but in practice you can call C libraries on a given platform the same way, regardless of which compiler generated them.
You can do that with C++ too -- assuming they are conforming to the platform ABI. On Linux, for example, all C++ compilers can call each other's code just fine. You may be thinking of the funny situation on Windows where GCC has historically flagrantly disregarded the platform C++ ABI and implemented its own instead. I assume this decision was made as a matter of practicality: The Cygwin people didn't have the resour…
GCC didn't ignore the Windows C++ ABI. Windows doesn't have a platform C++ ABI.
Microsoft consider MSVC's C++ ABI as being internal to the compiler. They don't guarantee that the ABI won't change between major versions, only that it won't change between minor updates. Either way, it is not considered to be part of Windows, unlike the C ABI.
It's also not completely documented, so you'd have to reverse-engineer most of it if you wanted to be compatible.
It's the platform's de-facto C++ ABI, certainly, and in practice it's somewhat stable, but hardly reliable or useful for anyone other than Microsoft.
Other compilers and platforms used to have the same problem - each compiler had it's own ABI, and on platforms where one compiler was dominant, it basically became the de-facto standard, but there was no interoperability. That changed when pretty much every compiler (aside from MSVC) and OS (aside from Windows) adopted the Itanium C++ ABI, or a derivitive (like the ARM C++ ABI).
The C++ standards organization have a draft proposal to have platform standard ABIs, specified and documented by the platform holder. This really only affects Windows, and would require Microsoft to define a C++ ABI for Windows. That would most likely mean documenting the MSVC ABI, and calling that the standard C++ ABI.
Various Microsoft employees are pushing for it, so it might happen. The proposal was written by Herb Sutter, for example.
Re: A proposal for named arguments for C++
#57This is exactly why I like the Objective-C method call syntax. Instead of "mystery argument soup" rectangle->set(10,10,20,20,true,false) you get something that can be understood without taking a trip to the API docs: [rectangle setX:10 y:10 width:20 height:20 updateBSP:YES clipToParent:NO] It's a pity they are moving away from this syntax in Swift. It's the right move -- I hear nothing but hate for it from those who…
Swift has named arguments, and it's called "external parameter name". Here's an example taken from Apple's documentation[1].
func join(string s1: String, toString s2: String, withJoiner joiner: String)
-> String {
return s1 + joiner + s2
}
join(string: "hello", toString: "world", withJoiner: ", ")
// returns "hello, world"
Re: A proposal for named arguments for C++
#58I like this idea in theory. the rectangle the example is a good one that I've personally tripped over before. That being said, this could hurt readability in some cases as single lines of code are going to get larger, especially with length parameter names. Another issue I forsee is a code style where parameters are prefixed with p_. Having to type that prefix each time would be annoying, but finding a readable synta…
I agree this probably looks better in theory than it does in practice. As far as long function declarations go, it sure would be nice to go back to declaring multiple arguments of the same type without repeating the type: int myfunc(float x, y, z, r, g, b, a); instead of int myfunc(float x, float y, float z, float r, float g, float b, float a); Yes, I know about structs, but often that's not applicable. And if the ty…
"int myfunc(float x, y, z, r, g, b, a);"
This got me thinking of the old C ways: http://msdn.microsoft.com/en-us/library/efx873ys.aspx
Re: A proposal for named arguments for C++
#59How about this:
typedef int annotated_type;
void foo (annotated_type parameter_name) {}
foo (5); /* the short and alegedly ambiguous version of function calling */
foo ((annotated_type) 5); /* now I know more about what "5" means
in this function parameter's context */
Of course, this doesn't come with parameter-order juggling, but that is another can of worms in itself, which I'd better avoid!
Re: A proposal for named arguments for C++
#60Earlier quoted context omitted.
You can do that with C++ too -- assuming they are conforming to the platform ABI. On Linux, for example, all C++ compilers can call each other's code just fine. You may be thinking of the funny situation on Windows where GCC has historically flagrantly disregarded the platform C++ ABI and implemented its own instead. I assume this decision was made as a matter of practicality: The Cygwin people didn't have the resour…
GCC didn't ignore the Windows C++ ABI. Windows doesn't have a platform C++ ABI. Microsoft consider MSVC's C++ ABI as being internal to the compiler. They don't guarantee that the ABI won't change between major versions, only that it won't change between minor updates. Either way, it is not considered to be part of Windows, unlike the C ABI. It's also not completely documented, so you'd have to reverse-engineer most o…
Hmm, you got me. I had thought MSVC's C++ ABI was documented and intended to be used by other compilers, but sounds like I got that wrong. Still, as you say, it is the case that most other platforms do in fact have a C++ ABI (if belatedly).