Ok ok. the ONLY place i can see ANYTHING like that is we have some macros / inline functions for transforming vertex data. They are something like 9 in and 3 out parameters.
A few cases we have some strange stuff because we init classes only using the
classA foo = {...}
syntax instead of
classA foo(...);
and so there are wrapper macros that EMULATE the constructor format and thus can have tonnes of parameters.
33 parameters for a function?! Seriously!?
Quote:Original post by KulSeran
Ok ok. the ONLY place i can see ANYTHING like that is we have some macros / inline functions for transforming vertex data. They are something like 9 in and 3 out parameters.
A few cases we have some strange stuff because we init classes only using the
classA foo = {...}
syntax instead of
classA foo(...);
and so there are wrapper macros that EMULATE the constructor format and thus can have tonnes of parameters.
o_O
For purely educational purposes, why would you do such a thing?
Quote:Original post by Way WalkerQuote:Original post by polymorphedQuote:Original post by MikeTacular
Is this normal?
Nope. The normal thing would be to just pass a pointer/reference to an object containing said 32 arguments. I can't imagine why you'd have any portability issues with plain objects, unless you're planning to port it to FORTRAN. [smile]
Even then, I usually write a wrapper function or macro for the FORTRAN function which takes a struct or two as arguments.
And even then, the more recent standards of FORTRAN (e.g. 2003) contain support for object-oriented programming, so even the good old grand daddy of programming languages should be able to handle passing a struct or an object through the parameter list :-)
You should consider finding another job. You just received production code that has 33 function. Something is wrong here :|. No matter how good your boss is.
Quote:Original post by polymorphedOn the contrary, he must be quite good at typing, you noticed 100 lines were removed from the declaration right :)Quote:Original post by d000hg
But, 33 is nothing.
Hmm. Wow. I'm genuinely surprised that the person who wrote that code was able to operate a keyboard.
I once generated a function with 81 parameters—each parameter was a distinct Su Doku cell, and I needed to manipulate them by name.
Quote:Original post by MikeTacularYes. It is quite common that people who take decisions have no flipping clue what they are talking about. However, they are still the ones who decide.
my boss recently had me make an API change [...]
He agreed but said "the guys" (dunno who they are... his management maybe?) like to use parameters and were pretty stiff about it. He said it was probably so it could work with legacy code and that "the guys" say objects cause portability issues.
Is this normal?
This is where corporate branding and FUD have their base. It is what influencer marketing aims at too. Big companies have been successful selling inferior goods and services with that strategy for decades.
In other words, executives will rather spend 250,000 for something that works less efficient and has higher maintenance cost than something they could get for free or nearly so based on the fact that some guy they play golf with says it's what people use, or because it has a big name.
It looks like your boss has a great career as executive ahead. :-)
Quote:Original post by samothIt's also common for technical people to think their bosses are stupid because they are less technically able than they are. This is logically ridiculous. Your boss has to manage people, organise schedules and budgets, keep clients happy etc, which all take time and require knowledge and skills. Only a very special person can do all that and still know as much as his development team. In fact even if he is a coder by trade, a good boss would be hiring coders who were better than him.Quote:Original post by MikeTacularYes. It is quite common that people who take decisions have no flipping clue what they are talking about. However, they are still the ones who decide.
my boss recently had me make an API change [...]
He agreed but said "the guys" (dunno who they are... his management maybe?) like to use parameters and were pretty stiff about it. He said it was probably so it could work with legacy code and that "the guys" say objects cause portability issues.
Is this normal?
This is where corporate branding and FUD have their base. It is what influencer marketing aims at too. Big companies have been successful selling inferior goods and services with that strategy for decades.
In other words, executives will rather spend 250,000 for something that works less efficient and has higher maintenance cost than something they could get for free or nearly so based on the fact that some guy they play golf with says it's what people use, or because it has a big name.
It looks like your boss has a great career as executive ahead. :-)
Expecting your boss to be at the same level as you on your specialty is unreasonable. Programmers need to learn not to feel superior to people who aren't great programmers, and how to communicate with less technical people.
Yeah, I'm glad this resolved properly into a refactoring of the function into an object. It is exactly the type of thing that shouldn't be a single function.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
