Talk:Dynamic dispatch

Merge with dynamic binding?

This article overlaps significantly with dynamic binding; maybe the two articles should be merged? -Andyabides 22:02, 19 Nov 2004 (UTC)

I don't think so. Both are to do with how a bit of code is found for a given invokation, but they are different ideas. I'm not sure that the articles make it clear enough, but dynamic dispatch can occur through mechanisms like RPC (at least from an architecture perspective) and dynamic binding can also occur at load time through the choice of a given library (for example switching between DLLs). When looking at platforms/languages the two are seperate and a given platform may support one or the other, both or none. I'll have a think about adding something to the two articles about this. — KayEss | talk 11:02, 23 Apr 2005 (UTC)

I agree that the difference between those two concepts should me made very clear in both articles. I added to this article a link to Dynamic binding (and vice-versa) so that readers from both articles relate the ideas and help clarifying the difference in future edits. --Antonielly (talk) 09:41, 15 October 2008 (UTC)

Years later, I add a merge proposal to both article to point at that either these article should be merged or their content should point out explicitly their differences. --Abdull (talk) 19:51, 1 October 2010 (UTC)

Comment: Yes, a sentence in the lead of each explaining how it's different from the other would be very helpful. I'd try to write it but I don't quite understand the difference. Would someone please explain? --Pnm (talk) 01:17, 5 December 2010 (UTC)

Simply put -- emphatic no - similar is not identical. —Preceding unsigned comment added by 205.131.188.5 (talk • contribs) 16:07, 18 October 2010

Can you then point out the differences then please? 6 years on, the two articles still look the same to me. If the situation does not change, dynamic binding should become a subsection here, and currently it would barely amount to one line of extra info. 205.228.108.185 (talk) 07:34, 24 February 2011 (UTC)

Clarification in Single and multiple dispatch

For an uninformed reader, the section that explains how multiple dispatch can be achieved by inspecting the type of parameter y can be mistaken for method overloading. I feel that a statement to the effect of "Unlike method overloading, the type of the object y is known at runtime" could serve to clear the water. Moreover, I'd note that, with method overloading, the method to call is decided at compile time based on the declared type of the argument, as opposed to its runtime type. Viridium 16:23, 27 October 2007 (UTC)

External links

I just removed this external link posted by Dpol to the editor's own masters thesis. I think it qualifies as a reliable source, so its material should be incorporated and cited (with a URL), instead of listed as an external link. Because it appears to be a reliable source, it doesn't meet guidelines for external links at WP:ELYES or WP:ELMAYBE.

• Chapter on dynamic dispatch (in the tradition of C++) from master's thesis

--Pnm (talk) 00:38, 16 December 2010 (UTC)

std:: qualifier

@Strebe Do you even read the edit? A using statement was literally added to the code. The same case can be made with not including a import statement or #include directive, so why do you specifically draw the line at using statements? Adding std in front of everything, when it is incredibly obvious what string type is being referred to, doesn't benefit anyone. Do you suppose we're referring to const char*, java::lang::String, or QString? There's only one string it could possibly refer to, std::string, which IS obvious when we are in the context of C++, especially with the using statement above. This isn't subjective, do you think other C++ programmers will read it and interpret string as some totally different type, like absl::String or com::microsoft::text::String? And if you think it's because we would confuse std::string and std::string_view, that's meaningless when we would explicitly say string_view when we mean it. When you say "Somebody might copy and paste the code, but it won't work.", you're speaking entirely in theoreticals and this is a waste of time to even argue about. Should we include steps on how to run and compile the code for every snippet of code? 24.50.56.74 (talk) 18:05, 14 October 2025 (UTC)

import std; with using namespace std; is seriously frowned upon. You’re pushing some preference of yours that violates best practices to no benefit. No, I don’t think it matters privately in a short snippet, but I do think it matters not to be casually promoting bad practices. Strebe (talk) 18:37, 14 October 2025 (UTC)

Who wrote using namespace std;? I wrote using std::string;. And what are you talking about import std; being "frowned upon"? Do you think using namespace std; and import std; do the same thing? Do you even know what you're talking about? If you knew why people consider using "bad practice" (in very specific contexts) you would know that this isn't one of those contexts. 24.50.56.74 (talk) 18:38, 14 October 2025 (UTC)

Do you think using namespace std; and import std; do the same thing? Nope. That doesn’t follow from anything I said, which you would understand if you paused from your snotty jabs for a moment to recognize that I wouldn’t have said std:: is needed if I thought that. Those snotty jabs sabotage your arguments by suggesting that your motive is only about getting what you want. Meanwhile, the original text was clear, avoided idioms irrelevant to the solution that the code illustrates, and generally accords with best practices. It didn’t need your changes and I don’t need to waste more of my time on tantrums. Strebe (talk) 19:14, 14 October 2025 (UTC)

It looks like if anything, you're the one throwing a tantrum here after making several incorrect statements about my edits and resorting to bulverism to allege that "I am making edits to push an agenda", "...only about getting what you want.", and then saying "I don't need to waste any more of my time on tantrums." as if it will shut down the talk page section (it will not). I've made very clear what my motive is: cluttering the code with qualifying std::string every time it's invoked doesn't benefit anyone and is just needlessly verbose. You first suggested that simplifying it to string (and said If you don't have a using statement, when the code did) introduces ambiguity, or that it wasn't obvious. You then alleged I wrote using namespace std; which I did not, and then made a claim that using namespace std; is bad practice (again emphasising that this is not what I wrote), while refusing to acknowledge that it is bad practice only when part of library code (i.e. placed in a header file that is included by the preprocessor - though in modules using statement without an export statement does not leak to the user) when this snippet of code was never said to be library code, so this point is moot. Meanwhile, the original text was clear - just because something is verbose for "clarity" does not mean it is good. Should we then refer to humans in text as Eukarya, Animalia, Chordata, Mammalia, Primates, Hominidae, Homo sapiens, just because it is "clearer" precisely what "human" refers to? Or for a less extreme example that has direct parity, should we write in Java public static void main(java.lang.String[] args) { java.lang.System.out.println("Hello, world!"); } just because it becomes clear what String refers to? Or java.util.List<java.lang.Integer> l = new java.util.ArrayList<java.lang.Integer>();, when it could just be qualified with import statements into List<Integer> l = new ArrayList<>();. No one gains anything from seeing the full name (java.lang.String) because this is implicitly obvious, just as string is implicitly obviously referring to std::string (especially with the inclusion of using std::string;). 24.50.56.74 (talk) 19:47, 14 October 2025 (UTC)