没有前向声明的C ++? [英] C++ without forward declarations?

查看:76
本文介绍了没有前向声明的C ++?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述



C ++会不会像Java一样进行多级编译?


这样我们就可以转储旧模型了必须首先声明然后写

代码?


我发现声明浪费了很多编码时间。它比预处理器需要的东西多得多了b $ b,除了它是古老的垃圾。在Java或其他现代OOP语言中不需要它。

(Visual Basic和REALbasic),为什么选择C ++?


这是必须的我对C ++最大的抱怨。其余的只是我可以忍受的东西。


如果对象有标准化的实现,也会很好。

我们可以调用一些标准函数来获取它的类。内置

内省,基本上。 Java有内省......我想如果你愿意在内存中做坏事,那么你可以用b ++内省
内省和

读取超出类的指针'那个界限。

解决方案

实际上,现在我想起来了...... C ++&关键字真的很糟糕。


它就像一个残缺的指针。你不能重新安置它就像你可以在

Java :(


它只是为了语法糖,它仍然设法是错误的!!!为什么

不只是扩展。(点)来处理指针或引用吗?

这更像是Java和更好。


而且,为什么我们甚至需要将某些东西定义为虚拟或

不是?难道编译器不知道你是否已经将一个函数子类化了或者

不是吗?这个虚拟关键字没用,有害且烦人。


为什么编译器也没有要求我告诉它什么寄存器

。参与其中?如果我不知道,它会抛出一个错误,因为它已经秘密地知道答案了吗?


多么愚蠢的系统,要求程序员告诉编译器

它已经知道的东西,这样就浪费了他的时间!!!真的

愚蠢。如果我是C ++的设计者我会杀死''虚拟''

关键字。


此外,将函数放入类中不应该真正内联它...

内联关键字应该这样做。我们已经有一个内联关键字

所以为什么暗示将它放在类中也一样?这是多余的
。你做同样事情的方式越多,臃肿的

a语言就变成:(


另外,共享指针(就像提升所得到的那样),应该默认情况下一直在

C ++中,即使在stl中也是如此。而且它们应该被提升

比使用new / delete更重要.new / delete就是这样过度使用

概念,我真的尽力避免它们,但我经常会来到其他人使用它们写的库中的


使用了STL的字符串或容器类。这很烦人。


我认为使用共享指针比使用它更容易

new / delete。这将是一个隐含的建议,以某种方式做到这一点。如果你让一种技术变得更容易,你基本上就是

推荐它,即使你没有说沿着这条路走下去。


并且不应该使用模板在模板上,除非他们首先输入类型:(模板疯狂真的伤害了眼睛。


C ++应该指定一些标准化名称修改。因为Bjorne在这里疏忽了,所以​​链接C ++库是不可能的。他/ b $ b应该提前看到这个...而且,''this''关键字

应该始终是实际内容的第一个参数

在寄存器中。


co ********** @ googlemail.com 写道:


实际上,现在我想到了它... C ++'s&关键字真的很糟糕。


它就像一个残缺的指针。你不能重新安置就像你可以在

Java :(



这实际上是为什么它很好。


这只是语法糖,它仍然设法错了!!!



它不是只是语法糖。

我几乎看不出它是怎么回事。


为什么

不只是扩展。(点)才能使用指针或引用?



因为指针不是对象,而是指向对象的指针。 />


这更像是Java和更好。



C ++并不打算就像Java一样。


>

而且,为什么我们甚至需要将某些内容定义为虚拟或

不是吗?难道编译器不知道你是否已经将一个函数子类化了或者

不是吗?



首先,编译器无法知道。

其次,你可能不想使用虚拟,即使在子类化时也是如此。


这个虚拟关键字无用,有害且烦人。



这里是为那些想要它的人提供多态性。


多么愚蠢的系统,到请程序员告诉编译器

它已经知道的东西,这样就可以浪费他的时间!真的

愚蠢。如果我是C ++的设计者,我会杀掉''virtual''

关键字。



编译器的工作不是猜测你的错误并自动纠正它们

自动生成。

发生错误时,它会告诉您这些错误是什么。它可以尝试猜测你做错了什么,但就是这样。


此外,将函数放入这个班不应该真的内联它...



它没有。

这只是一个先决条件。 />


inline关键字应该这样做。



它也不是,它只是一个建议。


此外,共享指针(如增强功能),默认情况下应该在

C ++中,即使在stl中也是如此。他们应该被提升

比使用new / delete更重要。



共享指针也被过度使用。

通常你根本不需要使用它们,除非你想分享

数据。


new / delete是如此过度使用

概念,我真的尽我所能避免他们



当然你应该*从不*使用它们解开,这将导致

明显的异常安全问题。


>,但是我经常来这些其他人使用它们写的库中的


已经使用了STL的字符串或容器类。它很烦人。



不幸的是,大多数现有的C ++代码都很糟糕,主要是因为人们认为C ++是带课程的C语言。

C ++语言无法做到这一点。


我认为使用共享指针比使用它更容易/>
new / delete。那将是一个隐含的。建议以某种方式做到这一点




隐含的建议是支持在自动内存上分配

而不是动态内存分配。


并且不应该在模板上使用模板,除非他们首先输入类型为
:(模板疯狂真的会伤到眼睛。



这是一个愚蠢的想法。


C ++应该指定一些标准化的名称修改。因为
由于Bjorne在这里的疏忽,
链接C ++库是不可能的。他

应该提前看到这个......



这是可能的。


此外,''this''关键字

应始终是第一个参数实际内容的条款

在寄存器中。



你在说什么?

co ********** @ googlemail.com 写道:


实际上,现在我想起来了...... C ++&关键字真的很糟糕。


它就像一个残缺的指针。你不能重新安置它就像你可以在

Java :(


它只是为了语法糖,它仍然设法是错误的!!!为什么

不只是扩展。(点)来处理指针或引用吗?

这更像是Java和更好。



我不确定你的问题是什么。请详细说明你想要做的事情,记住C ++的目标,那不知不觉

与Java非常不同。


>

而且,我们为什么要这样做?甚至需要将某些东西定义为虚拟或

不是吗?难道编译器不知道你是否已经将一个函数子类化了或者不是
?这个虚拟关键字是没用的,这是一个很好的问题。两者都很有用。在C ++中你可以同时拥有它们。


>

为什么不是e编译器还要求我告诉它什么寄存器到什么东西

params in?如果我不知道,它会抛出一个错误因为它已经秘密地知道答案了吗?



你在说什么? 寄存器今天关键字与编译器功能较差时的用途相差甚远。

今天,唯一能指望的是标记为
寄存器不能让它的地址最多给予优化器一个

暗示该对象没有别名。


>

多么愚蠢的系统,要求程序员告诉编译器

它已经知道的东西,这样就浪费了他的时间!真的

愚蠢。如果我是C ++的设计者,我会杀掉''virtual''

关键字。



这很好,你来不及了。你应该在大约20年前就已经讨论过C ++的讨论了。


>

此外,将函数放入类中不应该真正内联...

内联关键字应该这样做。我们已经有一个内联关键字

所以为什么暗示将它放在类中也一样?这是多余的
。你有更多的方法做同样的事情,更臃肿

a语言成为:(



内联的含义和编译器实际内联的选择是两个非常不同的东西。你应该用编译器提交错误

供应商如果遇到问题,你会发现它们非常敏感。


>

此外,共享指针(就像提升所得到的那样)应该是在

C ++默认情况下,即使在stl。并且它们应该被提升

比使用new / delete更重要.new / delete是如此过度使用

概念,我真的尽力避免它们,但是我经常会来这些其他人使用它们编写的库中的


使用过相反,STL的字符串或容器类。它很烦人。



智能指针相对较新。编译器直到最近(最后

6年左右)太多马车了。您还可以选择在Java中使用

垃圾收集器。


>

I认为它应该比使用共享指针更容易

new / delete。那将是一个隐含的。建议以某种方式做到这一点

。如果你让一种技巧变得更容易,那么即使你没有说沿着这条路走下去,你基本上也会推荐它。



没有参数。就我个人而言,我不喜欢使用boost'的shared_ptr,因为它们会导致(imho)较少的问题,因此我会优先使用
侵入式引用计数。


>

并且不应该在模板上使用模板,除非他们首先输入类型:(模板疯狂真的伤害了眼睛。



啊 - 欢迎来到编程编程的世界。模板是一个非常强大的概念,但它需要用户非常非常地思考

不同的编程方式。


>

C ++应该指定一些标准化名称修改。因为
应该提前看到这个...



完全没有。还有其他更简单的方法可以做这些事情

不需要知道名字如果你看看奥地利C ++

通用工厂实现。它适用于动态链接的

库,并且完全不知道名称损坏。


....此外,''this''关键字


应该始终是寄存器中实际内容的第一个参数




你为什么关心?


C ++当然有很多瑕疵,但它更强大了/>
语言比C.我最近没有关注JAVA,但在我看来

它比Java更灵活,但这确实意味着你

需要花时间去了解语言。当我开始用C ++弄乱

时,很少有C ++的好用例,所以

的学习曲线有点长,现在已经改变,有很多

非常好的C ++应用程序的好例子。

编译器最近(最近2年)才符合标准。


我的建议是,不要指望C ++是完美,它就是它b / b和你学得更快的东西,并且不再感到沮丧,

你会更快地学习并且有用。喋喋不休

不会有所帮助。


至于完美的语言,如果是C ++ / Java等,请不要屏住呼吸

任何迹象,这将需要很长时间才能到达这里,所以你有更好的

学会使用你拥有的工具。尽管如此,这不应该让你无法想象完美的语言是什么样的,只是不要b / b
期望它出现,除非你愿意放一些严肃的能量。



Will C++ ever have Java-like multiple level compiling?

So that we can dump the old model of having to first declare then write
the code?

I find the declaration wastes so much time in coding. It''s little more
than something needed for the preprocessor, apart from that it is
ancient junk. It''s not needed in Java or other modern OOP languages
(Visual Basic and REALbasic), so why C++?

That''s gotta be my biggest gripe with C++. The rest are just stuff I
can live with.

It would be nice if objects had a standardised implementation, also.
Some standard function we could call to get at it''s class. Inbuilt
introspection, basically. Java''s got introspection... I suppose you can
introspect in C++ if you are willing to do bad things to the memory and
read pointers beyond the class''s bounds.

解决方案

Actually, now that I think about it... C++''s & keyword really sucks.

It''s like a crippled pointer. You can''t "Reseat" it like you can in
Java :(

It''s just for syntactic sugar, and it still manages to be wrong!!! Why
not just extend "." (dot) to just work with pointers or references?
That would be more like Java and better.

And also, why should we even need to define something as virtual or
not? Shouldn''t the compiler know if you''ve subclasssed a function or
not? This virtual keyword is useless, harmful and annoying.

Why doesn''t the compiler also ask me to tell it what registers to stuff
the params in? And if I don''t know, it throws an error because it
secretly knew the answer already?

What a stupid system, to ask the programmer to tell the compiler
something it already knows, just so it can waste his time!!! Really
stupidity. If I were the designer of C++ I''d kill the ''virtual''
keyword.

Also, putting functions into the class shouldn''t really inline it...
The "inline" keyword should do that. We already have an inline keyword
so why imply that putting it in the class does the same???? It''s
redundant. The more ways you have to do the same thing the more bloated
a language becomes :(

Also, shared pointers (like what boost has got), should have been in
C++ by default, even if in the stl. And they should have been promoted
as more important to use than new/delete. new/delete are such overused
concepts, I really do my best to avoid them, but all too often I come
across libraries written by other people using them when they could
have used STL''s string or container classes instead. It''s annoying.

I think it should be easier to use a shared pointer than it is to do
new/delete. That would be an "implicit" recommendation to do it a
certain way. If you make one technique easier, you are basically
recommending it even if you haven''t said "go down this path".

And it shouldn''t be possible to use templates on templates, unless they
are typedeffed first :( Template madness really hurts the eyes.

And C++ should have specified some standardised name mangling. Because
linking C++ libraries is impossible due to Bjorne''s oversight here. He
should have seen this one ahead of time... Also, the ''this'' keyword
should always be the first parameter in terms of the actual stuff going
on in the registers.


co**********@googlemail.com wrote:

Actually, now that I think about it... C++''s & keyword really sucks.

It''s like a crippled pointer. You can''t "Reseat" it like you can in
Java :(

This is actually why it is good.

It''s just for syntactic sugar, and it still manages to be wrong!!!

It''s not just syntactic sugar.
And I hardly see how it''s wrong.

Why
not just extend "." (dot) to just work with pointers or references?

Because pointers are not objects, but pointers to objects.

That would be more like Java and better.

C++ doesn''t aim to be like Java.

>
And also, why should we even need to define something as virtual or
not? Shouldn''t the compiler know if you''ve subclasssed a function or
not?

First, the compiler can''t know.
Second, you might want to not use virtual, even when subclassing.

This virtual keyword is useless, harmful and annoying.

It is here to provide polymorphism for those that want it.

What a stupid system, to ask the programmer to tell the compiler
something it already knows, just so it can waste his time!!! Really
stupidity. If I were the designer of C++ I''d kill the ''virtual''
keyword.

The job of a compiler isn''t to guess your errors and correct them
automagically.
When errors occur, it tells you what those errors are. It can try to
guess what you did wrong, but that''s it.

Also, putting functions into the class shouldn''t really inline it...

It doesn''t.
It is just a precondition.

The "inline" keyword should do that.

It doesn''t either, it''s just an advice.

Also, shared pointers (like what boost has got), should have been in
C++ by default, even if in the stl. And they should have been promoted
as more important to use than new/delete.

shared pointers are also overused.
Normally you shouldn''t need to use them at all, unless you want to share
data.

new/delete are such overused
concepts, I really do my best to avoid them

Of course you should *never* use them unwrapped, that would cause
obvious exception safety problems.

>, but all too often I come
across libraries written by other people using them when they could
have used STL''s string or container classes instead. It''s annoying.

Unfortunetely, most existing C++ code is bad, mainly because people
believe C++ is C with classes.
There is nothing the C++ language can do about it.

I think it should be easier to use a shared pointer than it is to do
new/delete. That would be an "implicit" recommendation to do it a
certain way.

An implicit recommendation is to favorize allocation on automatic memory
rather than dynamic memory allocation.

And it shouldn''t be possible to use templates on templates, unless they
are typedeffed first :( Template madness really hurts the eyes.

That''s a stupid idea.

And C++ should have specified some standardised name mangling. Because
linking C++ libraries is impossible due to Bjorne''s oversight here. He
should have seen this one ahead of time...

It''s possible.

Also, the ''this'' keyword
should always be the first parameter in terms of the actual stuff going
on in the registers.

What are you talking about?


co**********@googlemail.com wrote:

Actually, now that I think about it... C++''s & keyword really sucks.

It''s like a crippled pointer. You can''t "Reseat" it like you can in
Java :(

It''s just for syntactic sugar, and it still manages to be wrong!!! Why
not just extend "." (dot) to just work with pointers or references?
That would be more like Java and better.

I''m not sure what your problem is. Please give concrete examples of
what you''d like to do bearing in mind that C++''s goals, that incidently
were very different to that of Java.

>
And also, why should we even need to define something as virtual or
not? Shouldn''t the compiler know if you''ve subclasssed a function or
not? This virtual keyword is useless, harmful and annoying.

That''s a great question. Both are useful. In C++ you can have both.

>
Why doesn''t the compiler also ask me to tell it what registers to stuff
the params in? And if I don''t know, it throws an error because it
secretly knew the answer already?

What are you talking about ? The "register" keyword serves a far
different purpose today than it did when compilers were less capable.
Today, the only thing you can count on is that a variable marked as a
register cannot have it''s address taken at most giving the optimizer a
hint that the object is not aliased.

>
What a stupid system, to ask the programmer to tell the compiler
something it already knows, just so it can waste his time!!! Really
stupidity. If I were the designer of C++ I''d kill the ''virtual''
keyword.

That''s nice, you''re too late. You should have been around 20 years ago
when the discussions about C++ were evolving.

>
Also, putting functions into the class shouldn''t really inline it...
The "inline" keyword should do that. We already have an inline keyword
so why imply that putting it in the class does the same???? It''s
redundant. The more ways you have to do the same thing the more bloated
a language becomes :(

The meaning of "inline" and the compiler''s choice to actually inline are
two very different things. You should file bugs with the compiler
vendor if you have a problem, you''ll find they''re very responsive.

>
Also, shared pointers (like what boost has got), should have been in
C++ by default, even if in the stl. And they should have been promoted
as more important to use than new/delete. new/delete are such overused
concepts, I really do my best to avoid them, but all too often I come
across libraries written by other people using them when they could
have used STL''s string or container classes instead. It''s annoying.

Smart pointers are relatively new. Compilers only until recently (last
6 years or so) were too buggy. You also have the option of using a
garbage collector -like in Java.

>
I think it should be easier to use a shared pointer than it is to do
new/delete. That would be an "implicit" recommendation to do it a
certain way. If you make one technique easier, you are basically
recommending it even if you haven''t said "go down this path".

No argument. Personally, I don''t like boost''s shared_ptr, I prever
intrusive reference counts since they cause (imho) less issues.

>
And it shouldn''t be possible to use templates on templates, unless they
are typedeffed first :( Template madness really hurts the eyes.

Ah - welcome to the world of programming the compiler. Templates are an
extremely powerful concept but it does need the user to think very very
differently about programming.

>
And C++ should have specified some standardised name mangling. Because
linking C++ libraries is impossible due to Bjorne''s oversight here. He
should have seen this one ahead of time...

Not at all. There are other much easier ways to do these things that
require no knowledge of name mangling. If you look at the Austria C++
generic factory implementation. It works with dynamically linked
libraries and with absolutely no knowledge of name mangling.

.... Also, the ''this'' keyword

should always be the first parameter in terms of the actual stuff going
on in the registers.

Why do you care?

C++ certainly has a number of warts, but it is a far more powerful
language than C. I have not followed JAVA recently, but in my opinion
it has much more flexibility than Java as well but that does mean you
need to put in the time to know the language. When I started messing
with C++ there were very few examples of good uses of C++ so the
learning curve was a bit longer, now that has changed, there are many
good examples of C++ applications that are very very good. The
compilers have only recently (last 2 years) caught up with the standard.

My advice to you is, don''t expect C++ to be perfect, it is what it is
and the quicker you learn what it is and stop being frustrated, the
quicker you''ll be up the learning curve and useful. Bitching about it
isn''t going to help.

As for the perfect langauge, don''t hold your breath, if C++/Java etc are
any indication, it will take a long time to get here so you had better
learn to use the tools you have. Still, that should not preclude you
from dreaming about what the perfect language looks like, just don''t
expect it to appear unless you''re willing to put in some serious energy.


这篇关于没有前向声明的C ++?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆