Talk:Name mangling

message: The statement “All of these class names are valid (as $ symbols are permitted in the JVM specification) and these names are "safe" for the compiler to generate, as the Java language definition prohibits $ symbols in normal java class definitions.” is completely wrong.
The character '$' is a legal character for Java identifiers, including class names. It is a rather discouraged character so it makes clashes between compiler-generated and user-defined class names unlikely but, in fact, there is nothing preventing collisions between these names. 77.12.74.48 (talk)  —Preceding undated comment added 14:05, 22 January 2014 (UTC)
thread_title: Wrong statement about Java

message: The page introduction suggests that name mangling (euphemistically called "decoration") is needed in a particular case. I know what this is getting at, but suggest that this is not strictly true, that not all cases are covered, and that the causes of the use of name mangling should be more precisely drawn out by considering the intermediate form (e.g. object code) and its consumers (e.g. linkers), and their limitations, which require name mangling to be used, though I can't say this succinctly, so here are my ramblings...
The page says "The need [for name mangling] arises where the language allows different entities to be named with the same identifier as long as they occupy a different namespace (where a namespace is typically defined by a module, class, or explicit namespace directive)."
Firstly, when the same-named entities are in different namespaces then an entity can be unambiguously identified by its fully qualified name (e.g. namespace0.namespace1...class0.class1...identifier). Strictly, in this case, name mangling would be _needed_ only if there were no other means of representing in some intermediate form (e.g. object code) the fully qualified name, along with the number and types of function/method arguments, and other information (e.g. static/non-static, public/protected/private). A limitation of the intermediate form to fully represent the required information, and/or a limitation of the implementation of consumers (e.g. linkers) of an intermediate form, might impose a requirement for name mangling, but name mangling is not strictly _needed_ if the intermediate form has a means of representing all the required information and the consumers are implemented to use that information. The section on name-mangling not being generally required (with some exceptions) in Java makes this point by saying Java was designed with object-orientation in mind.
Secondly, the definition does not include the case where the same-named entities are in the _same_ namespace, which happens, for example, when a function/method identifier is overloaded within a class definition. Some disambiguation rules (e.g. considering the number and type of function/method arguments) are employed to identify the entity being refered to. A suitably rich intermediate form and employment of disambiguation rules means that name mangling is not strictly _needed_ in this case.  — Preceding unsigned comment added by 77.100.246.52 (talk) 11:18, 8 June 2012 (UTC)
thread_title: Need for Name Mangling

message: At what point is this article going to move to the main namespace?  I'd think a reasonable overview of C++ and Java is probably reasonable to start with, though I'm not sure how detailed 'reasonable' is :)  — Lady Lysine Ikinsile 03:58, Jun 17, 2004 (UTC)
I am not sure where to raise this issue but what exactly meant in article by saying "languages not supporting function overloading such as C" AFAIK and AFAIDIMT (done it many times?) C supports function overloading.
:Standard C does not support function overloading, and I've never seen a C compiler that supports it.  Just so we're clear, if a C compiler supported function overloading, this code would compile, but every compiler that I'm aware of will complain about a multiple definition of f:
 int f(int x) { return x; }
 int f(int x, int y) { return x+y; }
Mnudelman (talk) 18:05, 12 November 2013 (UTC)
thread_title:  status? 

message: The article Name decoration should be merged with this article. This will help avoiding redundant information as well as confusion. The reader will be unable to guess which one is the latest and most updated. Secondly, both are actually the same things, it is pointless to have two pages for synonyms.
Agreed, but arguably the "proper" name is "decoration" so it should be merged the other way. With a redirect left behind, it doesn't really matter though.
Eric 04:38, 10 January 2006 (UTC)
replies: text: Ok, I've finished merging that article into this one. -- Bovineone 05:52, 10 March 2006 (UTC)
thread_title:  Mangling and Decoration 

message: Can the below explained be a name mangling problem??
Today, I faced a strange ‘C’ problem that had forced me to go through the C fundamentals again.
STRANGE PROBLEM:Consider you are working in for LIB_A and calling some foo function of LIB_B
LIB_A
void xyz()
{
unsigned short usVar = 12;
/* Call function foo from LIB_B */
foo(usVar);
……..
}
LIB_B
void foo(unsigned int uiVar)
{
/* guess what should be the value of uiVar when called from xyz */
}
I found that the value of uiVar = 0x0038000C(Hex).
After analyzing to the value above
0011 1000 0000 0000 0000 1100 (0x0038000C) with the correct value
0000 0000 0000 0000 0000 1100 (0x0000000C)
I was pretty sure in a way that this is to do with type-casting. When I change function xyz with explicit cast
void xyz()
{
unsigned short usVar = 12;
/* Call function foo*/
foo( (unsigned int ) usVar);
……..
}
I got the right value. But why it would need an explicit cast?
According to general C typecast or coercion or automatic conversion concept, unsigned short should automatically be converted into unsigned int (without explicit cast).
Isn’t it??
NOTE: LIB_A and LIB_B played an important role here because in the same library it works as it should.
I was struggling for an answer and then I tried playing with MSVC settings, I found an option “RTTI” Run Time Type Information
under VC++->Project Settings->C\C++(Tab)->Categrory = C++ Language(Enable Run-Time Type Information (RTTI)
Strangely when I enabled this, I started getting the correct values.
Then I relied on the following two links to conclude that we should enable RTTI option in all our libraries to avoid such kinds of error.
http://www.duckware.com/bugfreec/chapter7.html#avoidtypecasts
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vccelng4/html/elgrfRundshTimeTypeInformation.asp
:I don't think Wikipedia is the proper site for this, but anyway...
:I think your problem is not related with name mangling or RTTI (and both unrelated one another), but with automatic function prototyping, that is, if you use a function without a prototype (ie. foo) without a prototype, the compiler will guess the number and type of parameters from the actual parameters it gets (in your case a short).
:But note that automatic function prototyping is a deprecated feature of C, and in C++ it is just not valid. Simply #include the appropiate .h files and all will be ok.
:--Pinzo 00:19, 15 November 2006 (UTC)
thread_title:  Type-Casting of Function Argument In Cross Library Function Calls  

message: Does this article strike anyone is being overly technical, especially with such a vague introduction?
—The preceding unsigned comment was added by 68.252.72.221 (talk • contribs) .
:I've added in more lead section text from the Name decoration article that I just merged into here.  This article should be a little more accessible to a wider audience now. -- Bovineone 05:57, 10 March 2006 (UTC)
thread_title:  Too technical? 

message: AFAIK, default arguments don't affect name mangling, because they are not part of the function signature...
BTW, what is "variable ownership"???
--Pinzo 00:11, 15 November 2006 (UTC)
thread_title:  Cases of mangling in C++ 

message: Just a minor issue with the "C name decorations in Microsoft Windows" section.
The mangling scheme was established by Microsoft, and has been informally followed by other compilers including Digital Mars, Borland, and GNU gcc.
Actually, GNU gcc does not name-mangle C function declarations. Maybe we should rephrase this by removing GCC or move this to the C++ section. --Periophthalmus modestus 15:51, 26 July 2007 (UTC)
thread_title:  No name decorations in C for GNU gcc 

message: Those middots in the examples are confusing. I know they're meant to clarify the syntax, but it took me a while to see what they stand for (nothing). Maybe rather use thin boxes or alternating backgrounds?  —Preceding unsigned comment added by 87.162.46.92 (talk) 22:32, 21 August 2008 (UTC)
replies: text: I agree, they are very confusing. I'm going to remove them. If the breakdown of the mangled name isn't obvious from the formatting (italics and bold) combined with the explanation, then further explanation should be given, but using middots in the name when they aren't part of the name is not a good solution. --Bigpeteb (talk) 15:31, 28 April 2014 (UTC)
thread_title:  Layout 

message: It should be possible to turn-off name mangling without using extern c? (e.g. to export a 'plain name' function from DLL which accepts C++ class as parameter)  A .def file can do this in MSVC++, not sure if there are any other ways. 80.177.58.130 (talk) 12:06, 12 December 2008 (UTC)
thread_title:  Extern C 

message: Regarding incompatibilities between different compilers: Does this imply that for all Windows shared library to be accessible for all possible programs these shared libraries must all be compiled with the same compiler? --Abdull (talk) 17:15, 16 January 2010 (UTC)
replies: text: Only if all of the relevant libraries are written in C++ - and then, it's just a matter of matching compiler ABI, for example, Digital Mars C++ is ABI-compatible with Visual C++. C, on the other hand, has a standard ABI and code should be able to use standard C calls to call code compiled by any compiler - sometimes even if the code being called is written in an entirely different language.  Segin (talk) 07:24, 6 July 2010 (UTC)
thread_title:  Incompatibilities  

message: AFAIK, Delphi (tested: Borland Delphi 2006 for Win32) does not mangle names in DLL exports. The function myFunc stays "myFunc". There is no need to use "name 'myFunc'". AFAIK, Delphi and Lazarus are always creating undecorated names, that's why the undecorated style is called PASCAL-style ( Ref: http://support.microsoft.com/kb/140485/EN-US ) --80.139.126.193 (talk) 01:02, 2 September 2011 (UTC)
replies: text: See the comment two section about DLL exports in general.  — Preceding unsigned comment added by 86.104.57.160 (talk) 16:50, 18 December 2011 (UTC)
thread_title:  Name mangling in Delphi 

message: In the "Standardised name mangling in C++" section, this article implies that they do, but doesn't give any examples, and I haven't heard of any.  — Preceding unsigned comment added by 86.104.57.160 (talk) 17:52, 18 December 2011 (UTC)
thread_title:  Do C++-only linkers exist? 

message: Hello fellow Wikipedians,
I have just modified one external link on Name mangling. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20140410114817/http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html to http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 18:44, 11 February 2018 (UTC)
thread_title:  External links modified (February 2018) 

message: A number of sections in this article concern particular programming languages.
I would regard it as improvement if at the top of, e.g. the Rust section, one could simply click thru to the language article.
The most "obvious" way would be for the section name itself to be an article link.
Example:  "== C ==" becomes "== [ [C ] ] =="
[Pardon the extra spaces.  Without them something is eating my square braces.]
Is there a wikipedia rule/guideline discouraging that practice?  Has it been tried before and proven a disaster?
Alternatively at the beginning of each section the language might be mentioned, as a link.
Does anyone regard any of this as a "bad" idea? 2601:1C2:881:3630:B49F:BCD4:797C:7F32 (talk) 03:07, 11 September 2022 (UTC)
replies: text: MOS:SECTIONS says "For technical reasons, section headings should: … Not contain links, especially where only part of a heading is linked." You could include hat templates for the section like TEMPLATE:Further or TEMPLATE:See also which might point to a particular section, e.g. C++#Compatibility. StrayBolt (talk) 18:24, 12 September 2022 (UTC)
thread_title:  Is it wikipedia.naughty to use article links as section names? 

message: I think all the details, are just too technical, implementation defined, and not worth being in encylopedia. Such details should stay in the respective programming languages and compiler documentations, not wikipedia.
Half of this article should be easily removed. 85.195.241.133 (talk) 03:36, 29 January 2023 (UTC)
thread_title:  Too detailed