参数通过值或使用指针传递给一个函数哪个更好？

如果它只是CMD和FBack的一个实例，那么使它们成为全局更有效。



      以下为原文

    If it is only one instance of Cmd and FBack, it'll be much more efficient to make them global.

“如果它只是CMD和FBack的一个实例，那么使它们全球化更有效率。”我为什么不思考呢？



      以下为原文

    "If it is only one instance of Cmd and FBack, it'll be much more efficient to make them global."
Why didn't i think about that?
 

谢谢你们，0位到255位的8位论坛。如果我能把空的CMDService（空号）删掉，我会尝试的。



      以下为原文

    Thank you  1and0,  and all of you from 0 to 255 on the 8bit forum.
i will try if i can cut over to void CmdService(void)...
 

由于这是一个PIC16项目，使事物全球化可能是有意义的，它更快，但规模不大。随着项目的增加，Global的数量增加，并且变得难以管理。在计算机历史上，早期一切都是全球化的。他们创建参数来解决问题。



      以下为原文

   
Since this is a PIC 16Project it may make sense to make things Global, It is faster.
But it does not scale well.  As projects get bigger the number of Globals increase and become difficult to manage.
eary in computing history everything was global.  They created parameters to solve a problem.

C++甚至为更大的项目和大型程序引入命名空间。在PC上，我将尽可能地使实体成为本地，以避免名称冲突；但是在PIC上，思维变得有点不同……是的，参数仅仅是一个符号，只在函数内部看到，对于更大的数据结构，传递引用。是最好的方法，但是在PIC上，我认为，由于某些原因，比如银行交换和有限的环境，如果您经常通过调用内部不同的工具函数来访问数组中的某个元素，我们可以考虑回到全局访问。



      以下为原文

    C++ even introduce namespace for bigger project and  large programme.
on PC,i will make entities as local as possible,for one reason to avoid name conflict;
but on PIC,thinking become a little different...
yes,parameter is only a symbol,only seen inside function,for bigger data structure,pass reference is the best way;
but on PIC,i think,for some reason like banks switching, and limited environment,if you frequently access some element of the array by different tool function called inside,we could think about going back to access globals.
 

我认为这只是因为它是一个宣言。无论如何，不要害怕尝试并看到。



      以下为原文

   
I would think it is just that, since it is a declaration.  Anyway, don't be afraid to try it out and see.

好的，谢谢！事实上，这些缓冲器是在USB乒乓缓冲器的地址定义的，我仍然需要确保它们能够在正确的时间访问。我相信，如果正确端点被正确配置和启用，那么他的乒乓缓存将不被其他RAM实体使用。



      以下为原文

    OK,thanks!
in fact these buffers are defined at address of USB ping pong buffers,i still need to make sure they are available to access at the correct time.
i believe if the right endpoint is correctly configured and enabled,then his ping pong buffer will not be used by other RAM entities.

有很多非常糟糕的程序员编写了糟糕的代码。然后他们说：“等等，那不是我们。这就是我们使用的工具。它们让我们写出了看起来像意大利面条的烂代码。我们需要更好的工具。“所以，他们想出了更好的工具。他们的代码稍微大一点，稍微慢一点，但没有更好。当然，这不是他们的错。显然，新工具并不好。因此，他们想出了更好的工具和规则集，这将帮助他们写出更好的代码。再一次，他们的代码又大了一点，稍微慢了一点，但令人惊讶的是，它没有得到任何改善。但是，这又不是他们的错。只是工具已经过时了，需要更新、更好的方法和更严格的规则。因此，随着时间的推移，它一直持续下去。代码大得多，慢得多，但固执的东西却不肯做得更好。我们有Java，C，Python，jQuery，SWIFT——你可以说出它。我可以向你保证，还有更多的东西。这些东西在大学里是教过的，如果有人不使用这些先进的东西，他一定会被认为是个十足的白痴。



      以下为原文

   


There were lots of really bad programmers who wrote really bad buggy code. Then they said: "Wait a minute, that's not us. That's the tools which we use. They make us write really bad code which looks like spaghetti. We need better tools." So, they came up with better tools. Their code got a little bit bigger and a little bit slower, but it didn't get any better. But, of course, this wasn't their fault by any means. Clearly, new tools were not good. So they came up with better tools and sets of rules which would help them write even better code. Then again, their code again got a little bit bigger and a little bit slower, but, surprisingly, it didn't get any better. But again, this wasn't their fault. Just the tools were getting obsolete, and newer, better methods and stricter rules were needed.
 
And so, it went on and an on through the time. The code got considerably bigger and considerably slower, but the stubborn thing simply refuses to get better. We've got java, C#, pythons, jquery, swift - you name it. And I can assure you there will be more of that. These things are now taught in colleges, and if someone is not using this advanced stuff he must be considered a complete idiot.
 

啊啊！我在很大程度上同意诺斯盖尔，但事实上，我会避免全球化，除非惩罚是“显而易见的”。



      以下为原文

    Ah ah! I agree with Northguy, to a large extent.
But, indeed, I would avoid globals, unless the penalty is "noticeable"...

所有的工程都是权衡取舍。许多解决方案都有自己的问题。有些比他们试图解决的问题更糟糕。许多人习惯于解决错误的问题。锤子是钉钉子的好工具，但对螺丝来说是错误的工具。全球化是一种非常常见的工具。但是滥用很严重，而且你的代码很难调试。代码越大，变量越多，就越难管理。它。ECOMs只写代码。快速易写，调试困难，修改和扩展更差。对不起，我以前被迫钻过别人的密码。包括至少一个应该是一个开始。结构和组织是代码编写的重要特征。与注释、变量名以及进入实体程序的所有其他内容一样重要。对于那些在四年内学会了所有的知识，并且认为他们的新知识比几十年的经验要好的孩子。我只能摇摇头。编程是唯一一个不立即关闭的工程领域。



      以下为原文

    All engineering is about trade offs.
Many solutions have their own problems. Some worse than the problems they were trying to solve. Many used to to solve the wrong problem. Hammers are a great tool for nails, but the wrong tool for screws.
Globals are a very usual tool. But abused badly and you have buggy code that is hard to debug. The bigger the code with more and more variables it can get unmanageable.
It. Ecomes Write only code. Quick and easy to write, hard to debug, worse to modify and expand.
Sorry I have been forced to dig through others code before. Including at least one that should have been a start over.

Structure and organization is a important feature well written code. As important as comments, variable names, and everything else that goes in to a solid program.

As for the children that leaned all there is to know in four years and think their fresh knowledge is better than decades of experience. I can only shake my head. Programing is the only engineering field that does not shut that down immediately.

***



      以下为原文

    ***

枪不会杀人。人们会杀人。如果有人编写了糟糕的、不可管理的代码，那完全是他的错，与他是否使用全局语言无关。如果设置了禁止使用全局语言的规则，则无法使代码更好或更易于管理。但是由于你不必要地限制了你的自由，你的代码很可能会变得更糟。



      以下为原文

   


Guns don't kill people. People kill people.
 
If someone wrote bad unmanageable code it's totally his fault and has nothing to do with whether he used globals or not.
 
If you set up a rule not to use globals, it will not make your code better or more manageable. But since you needlessly constricted your freedom, your code is likely to get worse.
 

类似的“宗教战争”也因使用“goto”和从中间函数返回等问题而展开。我的立场是嵌入式系统通常不会给你提供理想的RAM、ROM和运行时间。苏珊



      以下为原文

    Similar 'religious wars' have been fought over the use of 'goto's and returns from the middle of functions etc..
My position is that embedded systems often don't give you the RAM, ROM and run time to be an idealogue.
Susan

我想几乎所有的事情都被诺斯盖尔所掩盖，我也同意澳大利亚的苏珊。GOTO太有用了，特别是对于常见的错误清除代码。它们可以使代码更容易理解，这总是一件好事。那些说你应该*永远不*做某事的人，因为理性，是白痴（或学者）。然而，我要补充的一点是，用前缀或骆驼壳/匈牙利符号，无论你喜欢哪个，对全球进行标记以明确它们是什么，是有用的。这在大型项目中尤其有用。但要确保无论你做什么，你都是始终如一的。



      以下为原文

    I think pretty much everything has been covered by NorthGuy.
I also agree with Aussie Susan. 'goto's are just too usefull, especially for common error cleanup code. They can make code much more understandable, which is *always* a good thing. People who say you should *never* do something, because reason, are Idiots (or academics).
 
One thing I would add, however, is that it can be usefull to demark globals to make it obvious what they are, using a prefix or camel case/Hungarian notation, whichever you prefer. This can be especially usefull in larger projects. But make sure that in whatever you do, you are consistant.

PIC16和PC程序的规则是不一样的。对于一个人项目和一个团队来说，他们也不一样。手表工程与桥梁设计的规则是一样的。尽管两者都是由机械工程师完成的。永远不要说永远的规则是好的。我花了很多时间，一旦发现这个项目会更简单，如果我做了所有的中断在中断。因此，如果您要在全球范围内完成这些工作，那么您应该有一个计划，使它们保持组织性，并且希望没有人要求数据流程图。



      以下为原文

    The rules for a pic16 and a PC program are not the same. Nor are they the same for a one person project vs a team. The same as the rules for watch engineering vs bridge design are not the same. Even though both are done by mechanical engineers.
The never say never rule is a good one. I spent a lot of time once finding out the project would have been simpler if I did all the comms in the Interrupt.
So if you are going to do it all in globals you should have a plan to keep them organized and hope no one asks for a data flow diagram.

在VC++中编译一些变量，它被支持在VC++的一些编译器中，或者成为STD C++的一个规则；但是我不支持ANSI C；在ANSI C中，规则是：在使用FUNC体之前先定义所有VAR，然后在XC8下面的行编译的传递：如果（发生了什么）{我的工作在这里……如果（TEMP）ItCONBITI. GEE＝1；}我希望事情会好起来，也就是说，在XC8中定义需求变量。



      以下为原文

    define variables on demand,it is supported on some compilers like VC++,or become a rule of std C++;but was not supported by ANSI C i believe;in ANSI C,the rule is :define all vars on the begin of you func body first,before using them.
but below lines compiled pass in XC8:
if( something happened )
{
   uint8_t temp = INTCONbits.GIE;
  INTCONbits.GIE = 0;

  my job here.......................

  if (temp)
 INTCONbits.GIE = 1;
}
i hope things will be OK,that is to say,define variables on demand in XC8.