Hi, buddies, I am writing a C++ library, it is an open source software, contains GUI/Threads/TextToken and so on...
find more information at http://stdex.sourceforge.net
Are you interesting in implemention of GUI controls?
hehe..regards.
Printable View
Hi, buddies, I am writing a C++ library, it is an open source software, contains GUI/Threads/TextToken and so on...
find more information at http://stdex.sourceforge.net
Are you interesting in implemention of GUI controls?
hehe..regards.
Very nice to see something like this.
I would be interested in making changes more to VB-like style (ie form.Caption = "something") instead of a function and such.
Also more of a suggestion - but you can use Option Tree for listboxes and such. Incredibly feature rich.
>>I would be interested in making changes more to VB-like style (ie form.Caption = "something") instead of a function and such.
Eww...stick to accessors.
Get/set for everything is horrible X_X
Having them as properties is more invigorating.
Yeah, but it makes more sense to keep the interface away from the data especially if you are in early stages of a library.Quote:
Originally Posted by Elysia
IIRC when you write a COM object in C++ (and I think the same applies to when you write them in VB) you have to use accessors in the interface you expose that the VB language then hides from the user when it makes those properties accessible.
Let the users access your data and somewhere down the line you might have to do something like check state before allowing access to that data, but as the data is "on show" your stuck
Ah yes, I was never suggesting letting users access data directly. No no no.
It's possible to "emulate" properties using some operators and templates. They act just like data members from the outside, but they are actually fully fledged functions.
That's similar to what I'm suggesting (I even developed a template for this kind of purpose).
Sounds good, but complicated and maybe a bit of a bloat. I'll stick with good old inline accessors!
thank you for your suggestion.
I tried to implement a generic property template, and its object is initialized in the init-list of a class, the property objects are always initilized with 'this' pointer, so compiler gives a warning that using 'this' in init-list, I don't like this warning, so I give up this implementation.
>>Option Tree for listboxes and such
All the widgets are own-draw, would you please implement an option tree? :-)
You can refer to "this" in the initialization list, but you cannot use it to either directly or indirectly reference members which have not yet been constructed. In other words, you can use "this" to access members of the base (if one exists) but not members of the class itself. At least, not members which are not yet constructed.Quote:
Originally Posted by jinhao
The conditions are sufficiently tricky, and compilers are sufficiently buggy, that a wise programmer would not use "this" in the init list. This is why the warning is there.
In other words, an proprety object should not use 'this' in the initialization list, because the object refered by this is under constrcution and the object is imcomplete. Although the property object just stores the 'this' while initializing, I gave up this implementation in logic/concept correct.Quote:
Originally Posted by brewbuck
I have met with similar designs, and the warning made me feel as you do. In the long run I think it is harmless in this situation, since the stored "this" will not be used until a call to a member, which can only happen after the object is fully constructed. You just have to be sure that the self-pointer is initialized in ALL constructors, including copy constructors -- which means you'll have to write a copy constructor explicitly.Quote:
Originally Posted by jinhao
In the end I also chose to switch to a different design.
You can pass this in the initializer list without any danger if the only thing you do with it is store it for later use.
But I consider property emulation a waste of code and memory. (Yes, the emulation needs one word per property of overhead.)
yes, one property uses at least >=8 bytes, 4 bytes for 'this', 4(>=4) bytes for pointer of member function.Quote:
Originally Posted by CornedBee
get/set is horrible...I avoided this issue by using function overloading.Quote:
Originally Posted by Elysia
form.caption(str); //set the caption of form
str = form.caption(); //get the caption of from;
thank you guys, i think we should go on with the discussions. ^_^
The function pointer can be passed via the template declaration instead to save some bytes...Quote:
Originally Posted by jinhao
4 bytes overhead is not much. It's typically what a smart pointer takes (or less).
I find it acceptable between functionality and overhead/size.
Accessors are not horrible if they are relevant to the problem domain.
How is that not an accessor, anyway? I mean yeah, you didn't name the pair get and set, but a rose by any other name ...Quote:
get/set is horrible...I avoided this issue by using function overloading.
form.caption(str); //set the caption of form
str = form.caption(); //get the caption of from;
I can acceptQuote:
Originally Posted by citizen
form.caption(str); //set
str = form.caption(); //get
the name caption is more flexibler than get_caption/set_catpion, it's easy and harmless.
a property has to face an important issue. e.g.
assume a form has a caption property object by type of property<std::string>Code:template<typename T>
struct property
{
operator T()const { return T(); }
};
Can't deduce the template parameter of bool operator==(const std::basic_string<C, T, A>&, const std::basic_string<C, T, A>&) with form.property.Code:std::string str;
str = form.property; //OK, operator T() works
str == form.property; //!!
fix the issue by overloading the operator==, but this solution is not good enough in my opinion, too many operators need to be overloaded.
No, you're missing the point. The pair of functions
std::string &form::caption() const
void form::caption(std::str &)
is as much an accessor as get_caption and set_caption would be, so as a matter of fact you did not avoid the concept of accessors at all.
And the problem that you have with implementing a property in C++ is that it must be read only at times as well as capable of changing state. The most straightforward way seems to be through a reference, but that doesn't hide your data very well.
I just think about whether the property is necessary in a C++ class. the form::caption is not only an assignment operation, but also setting the caption of a window. Actually, a generic property template is not cheap for some situations.
Well I'm glad we agree
I honestly don't see the problem with this. It's so beautifully verbose. I realize you already reached a consensus. So never mind me.Code:form.SetCaption(str);
str = form.GetCaption();
I have a problem with it mostly due to two [four] reasons:
1) Having to write two functions to do thing (basically).
2) Having two functions littering the definition instead of one.
And the [optional] 3rd) It's just ugly to have to type Get/Set.
And the [optional] 4th) It just feels more natural to be able to use operator = to assign and nothing to get since it feels like it's a property of the object - not some function that changes the state of the object.
1 and 2 can be solved using a generic template, alternatively two functions for advanced functionality.
Is there a reason you have your own custom license for the project instead of just releasing it under the GPL or BSD license (or even public domain)?
I have implemented a generic property template before. like thisQuote:
Originally Posted by Elysia
the length setter_ and getter_ is depend on compiler and Class. one property object takes 20 bytes, a widget has 10 property objects, a program has 20 widgets, so the program needs more 4000 bytes. it's not cheap. -_-!Code:template<typename T, typename Class>
class property
{
typedef property self_type;
public:
property(Class& obj, void (Class::* setter)(const T&), const T& (Class::*getter)() const)
:object_(obj), setter_(setter), getter_(getter)
{}
operator T() const
{
return object_.getter_();
}
self_type& operator=(const T&t)
{
object_.setter_(t);
return *this;
}
private:
Class& object_;
void (Class::* setter_)(const T&);
const T& (Class::*getter_)() const;
};
I don't like GPL.. -_-! releasing with my own license. refer to http://stdex.sourceforge.net/LICENSE_1_0.txtQuote:
Originally Posted by Mad_guy
While your license appears to comply with the Open Source Definition, it is not OSI approved, and is similiar to the BSD license and perhaps the MIT/Expat license, so why not use an existing OSI approved permissive license?Quote:
I don't like GPL.. -_-! releasing with my own license. refer to http://stdex.sourceforge.net/LICENSE_1_0.txt
The reason is that i've not read BSD/MIT license -_-!
That isn't an excuse. While nothing may come of it in the end, your licensing terms should be protected by a private entity in the event of your site's death and copies of the license are no longer available there, and especially if a copy of the license need not be distributed as part of the terms.
Otherwise it would just be your word, which makes your code public domain ex post facto.
This can be changed. Let me demonstrate.Quote:
Originally Posted by jinhao
Given, I did not compile and test this, but try it - it should work.Code:template<typename T, typename Class, void (Class::* setter_)(const T&), const T& (Class::*getter_)() const>
class property
{
typedef property self_type;
public:
property(Class& obj)
:object_(obj)
{}
operator T() const
{
return object_.getter_();
}
self_type& operator=(const T&t)
{
object_.setter_(t);
return *this;
}
private:
Class& object_;
};
That leaves just 4 bytes overhead.
And mate - 4KB of memory is nothing.
this version is too restrictive. the property just can set/get one thing. if it gets/sets caption and how it gets/sets size/position and so on...Quote:
Originally Posted by Elysia
No, it isn't.Quote:
Originally Posted by jinhao
Instead of passing the address via the constructor, you merely pass it when defining the object within the class definition.
Instead of:
property<int> myproperty;
myproperty(this, &CMyClass::mysetter, &CMyClass::mygetter)
You do:
property<int, &CMyClass::mysetter, &CMyClass::mygetter> myproperty;
myproperty(this)
Same thing. Less memory consumption.
I agree. Elysia's template is quite useless because even in the event that it works you still need to write the functions it uses underneath so 99% of the proposed benefits go away. Especially if changing state is not trivial likeQuote:
Originally Posted by jinhao
mystring.length = foo;
How does investing in this pretty syntax save you from functions resizing string buffers and so forth? I don't even think that properties work correctly on const objects which is amateur.
Whether or not this is more expressive is debatable to say the least. Foolish consistency is the hobgoblin of little minds. If you want properties they were correctly implemented in C#
I simply redesigned the EXISTING template which was not mine to begin with.Quote:
Originally Posted by citizen
And believe it or not, there's a huge amount of just set/get out there and we DO want to hide them.
And it does get rid of point 3 & 4, which is the biggest advantage which only C#, VB & Co have enjoyed for so long.
Microsoft's disgusting attempt to convert C++ to managed with a disgusting managed framework, disgusting syntax and broken or missing language features?Quote:
If you want properties they were correctly implemented in C#
No thanks.
Equally no thanks to VB.
Hey at least they did properties the right way.
I'll give them thumbs up for that, at least.
With what exactly?Quote:
Originally Posted by Elysia
Public members?
Emulating variable-like properties?
Excluding Get and Set from function names?
I agree with the first and do not with the other two. The second doesn't reflect C++ semantics and the third is not even a solution.
Wow, all this discussion about something so small!
Basically there's a lot of discussion over syntactic sugar, which comes at a greater price for the class writer (class having property implemented in these ways as member would require non-trivial copy constructor/operator= or be uncopyable) and some surprises for the user (because of the conversion operator the property may not always behave as expected).
I don't find any problem with the original approach. In case of a GUI frame, setting and retrieving the caption should not be thought of as accessors to a particular data member, they encapsulate the actions this class was meant for (displaying and controlling a window). (For example, if it is a wrapper around WinAPI then it wouldn't even need a data member for the caption, since Windows stores it someplace anyway and lets me access it.)
Sorry..I missed the second and third template parameter.Quote:
Originally Posted by Elysia
I totally agree with these points. I don't think the property is necessary in a C++ class, it was mentioned above.Quote:
Originally Posted by anon
I think we need to think outside the box of efficiency for a while.
C++ programmers seem to be obsessed with it.
Such a solution may be a little tricky but would give much better syntactic sugar in the end, aka to typical VB and C#, and we still run those programs, don't we?
We don't need to cram 100% speed out of the programs. It's 2008, not 1980!
You're not willing to trade in the mediocre slowdown of VMs for greatly increased security and all the syntactic sugar of C# (of which it has heaps and heaps), but you're willing to trade in a slight inefficiency for the dubious benefit of the half-working syntactic sugar of property emulation?
The problem is that I mentioned above.
I don't like managed.
I don't like VM.
I don't like Interpreted, compiled or whatever.
I don't like slow startups.
I don't like being restricted to what I can and can't do, which .NET actually restricts.
C# is supposed to be an "evolution," but I don't think so. So much changed to WORSE or broken.
And the syntax is just disgusting, it ticks me off. I never have, and never will use "^" for a pointer, nor "%" for a reference.
C++ is the language I grew up with and will continue to use until a new language evolves that doesn't break its features or syntax. I'm skeptic about D, as well.
You're confusing C# and C++/CLI.Quote:
C# is supposed to be an "evolution," but I don't think so. So much changed to WORSE or broken.
And the syntax is just disgusting, it ticks me off. I never have, and never will use "^" for a pointer, nor "%" for a reference.
Not really. The only thing it prevents is undefined behaviour, errors that may or may not lead to crashes. Do you think that's a worthy feature of your programs, one you can't do without?Quote:
I don't like being restricted to what I can and can't do, which .NET actually restricts.
Unless of course you're running under restricted security, in which case it also prevents you from doing things the owner of the computer hasn't actually given you permission to do.
So you don't like C++? It's compiled.Quote:
I don't like Interpreted, compiled or whatever.
That's just dogmatic nonsense.Quote:
I don't like managed.
I don't like VM.
It's a trade-off. It's good, but it removes too much flexibility.Quote:
Originally Posted by CornedBee
I meant compiled on-the-fly. Like a dynamic recompiler or stuff.Quote:
So you don't like C++? It's compiled.
Say what you want, but I don't like it and though it's not much of an argument, it's an opinion that's important to me and another reason I stay away from it.Quote:
That's just dogmatic nonsense.
If Microsoft were to start building library components and enhancing C++ with safe things, then I'd probably start using them directly (they have implemented a safe C library, and I do use it when I tend to use C stuff), but not C#.
> I meant compiled on-the-fly. Like a dynamic recompiler or stuff.
Why not? Even when it can provide a speed advantage?
Nothing wrong with a VM... flexibility for what!? It's rather nice to know what number representation, endianness or how big data types are the 'machine' is running, even if it is sometimes emulated.
I'd rather think of it as "slow down."
I fail to believe dynamic recompilation can beat native.
Give me one example of something you might want to do that you can't under the VM. (Destructors aside.)Quote:
Originally Posted by Elysia
But why is this opinion so important to you? You have absolutely nothing to back it up with, so it only makes you appear unreasonable.Quote:
Say what you want, but I don't like it and though it's not much of an argument, it's an opinion that's important to me and another reason I stay away from it.
They have "enhanced" C++ with their checked standard library. Which causes a factor 10 slowdown in one STL benchmark and is binary incompatible.Quote:
If Microsoft were to start building library components and enhancing C++ with safe things, then I'd probably start using them directly (they have implemented a safe C library, and I do use it when I tend to use C stuff), but not C#.
Well, I might think that the following might not work:Quote:
Originally Posted by CornedBee
MyManagedObj* pObj; // Assume it points to something
BYTE* pRaw = (BYTE*)pObj;
Now do whatever you want with pRaw. Dump it to a file for all I care.
Also, due to the blasphemous GC, you can't really move memory around without sticking it first. I believe there was an example somewhere about how that caused problems, but I can't remember where or how.
It's what makes me tick. That's why it's an opinion.Quote:
But why is this opinion so important to you? You have absolutely nothing to back it up with, so it only makes you appear unreasonable.
I like fast, responsive, powerful, non-cpu intensive applications.
I will give credit to the Framework, however. I've always wanted something like that in C++, separated in namespaces and all.
And it's a darn shame no one else has attempted to implement one, says I.Quote:
They have "enhanced" C++ with their checked standard library. Which causes a factor 10 slowdown in one STL benchmark and is binary incompatible.
I'm sure it could actually be optimized, as well.
I've always echoed it and will do so again. I really don't like iterators because they are unsafe, as in you can easily walk past the end. Microsoft's checked iterators will alert you if you do and I love that.
C++ needs more of things like that. It can become a modern, safe language.
Both STLPort and GNU libstdc++ have debug versions that are checked.
> I'd rather think of it as "slow down."
So you'd want to write a website in a pre-compiled language? And what if the environment changes, such as the server OS, etc?
Sometimes it's not all about speed, but productivity. Very well you may be able to write a program that is faster, but in terms of some VM/interpreted languages I can port mine without even recompiling, and it took less time to write ;). Of course there are cases that would blow this argument out of the water (but I'll ignore them for now).
And if MyManagedObj is a non-POD? And what about endianness and such?Quote:
MyManagedObj* pObj; // Assume it points to something
BYTE* pRaw = (BYTE*)pObj;
Now do whatever you want with pRaw. Dump it to a file for all I care.
As to the original topic, may-be it's just me but I find it useful to have Get... and Set... in function names. It seems to make it a lot easier to locate functionality to ... set and get things in references, especially if you have no idea what the property might be called (is it caption, or label, or text?). These prefixes nicely group similar functions together alphabetically. If your libraries have a reference, it will probably be easier for me to find set_caption(), rather than just caption().
Or not... The London Stock Exchange (which was in the news just recently for the wrong reasons) runs on a C# platform and still allows for a performance level that is among the most critical requirements one can think of. That didn't stop the minds -- which I'm sure are more than qualified -- behind the LSE to adopt a solution based on managed code, dynamic compilation and all the other demons from hell we like to think of when tagging programming languages as "bad".Quote:
Originally Posted by zacs7
Performance is perhaps one of the least understood requirements by many programmers. I wished Elysia reviewed her concept of it. Meanwhile liking or disliking the programming language has nothing to do with it, as Elysia will soon learn when the time comes for her to join the masses of other programmers waiting for a job in the industry.
Finally, the notion of a safe C++ ticks me. C++ is not meat to be safe. If that is a requirement (and I see plenty of reasons why it can be) one either implements safety or uses libraries that do. That's what's libraries are for. The language itself must remain as much general-purpose as it can be.
>> The language itself must remain as much general-purpose as it can be.
I agree. But that's not to say the language should throw if you, for example, try to divide by zero, or allocate a string of the size -1, or model the LHC, etc. [I've ignored the first 51 posts... so this might be a little off track...]
Mario,
your point about performance is good. 90% (or more in large systems) of code is not factoring in the performance of most applications. The relatively small portion of code that is performance critical can often be optimized on a algorithmic level to a larger degree than the optimizations that you get from the difference between one language to another (or variant of language to another). And if all else fails, most languages support calling C or assembler.
--
Mats
I completely fail to understand what this means or attempts to imply. What types of 'flexibility' do you lose?Quote:
It's good, but it removes too much flexibility.
Actually, forget that - the more important question is what types of flexibility do you gain by moving to other languages?
Note that I say 'types of flexibility' because the whole point varies from language to language. Ruby for example has a very flexible object model - you can add individual methods to classes for example. Combined with meta-programming you can have your objects and classes become even more powerful and you don't have to repeat yourself as much.
Another good example is Io. Io is an incredibly dynamic and flexible language that is built on message passing and objects (smalltalk-style.) It is possible for example to completely change code in situ by passing messages to objects and thus their behavior can change. This makes it completely feasible for example to write a self-optimizing optimizer in Io which could take your code and eliminate redundant or dead code if necessary.
Factor (or really Forth for that matter) is also an excellent example. Because it is a stack-based language, it tends to be very easy to refactor (pun intended) pieces of code. The underlying philosophy is that the factor words you write (think of words as functions basically) should be short and composed. It is extremely easy to get out of hand with it if you go with words that are too long.
Factor - like Forth - is a very 'high ceiling' language. It is completely feasible to write extremely DSL-like syntax to describe things like, for example, parsing grammars. Here's an example:
If you've got any sort of basic computer science education (or simply worked with BNF-grammars) then most of that should make sense to you immediately. It is extremely DSL-like, so it is entirely feasible to build very abstract and complicated programs in this manner. Doing it in C++ is, to say the least, not this easy (and yes, I'm completely aware of flex/yacc.)Code:EBNF: balanced?
parens = "(" term ")"
brackets = "[" term "]"
braces = "{" term "}"
term = (parens | brackets | braces)? => [[ >boolean ]]
;EBNF
Erlang is another example. Very very flexible concurrency model and because of it, it is extremely easy to take erlang programs and parallelize them across hundreds of computers and CPU cores. The underlying model of the system is what allows this to happen so easily and with so little hassle.
Does C have its place? Absolutely. C is essentially just portable assembler - you can basically get C anywhere within reason, and it is exceptionally good when it comes to things like hard constraints on memory or speed (e.g. real-time systems.) In some cases, it is absolutely the best tool for your job and I have never ever denied that.
I can go on and on, if you want.
The point is, if you just keep thinking in terms of losses you're completely limiting yourself because that connotation is likely to have a negative impression on your brain and thoughts - "oh, I lose pointers," "oh, I lose templates." It's a half-full vs. half-empty type of thing. It is better to think of what you may gain - reduced development time, better scalability, more security and soundness in your programs, more modular, refactorable code - and weigh it out overall than to just think of what you lose.
Being opinionated is fine - I think it is a wonderful thing - but if you let it get in the way of cold, hard fact and reality then it's useless and you're simply hindering yourself.
That's fine. Just be aware in the real world, nobody gives a damn about that.Quote:
Say what you want, but I don't like it and though it's not much of an argument, it's an opinion that's important to me and another reason I stay away from it.
(Addendum: I am almost completely ignoring efficiency in this post because I have been down that road so many times and so few people understand it, I've found bringing it up to be almost worthless in practice because nobody gets the point. Programming - simply put - is about more than how blazingly super-fast your programs can be.)
Are you aware of Boost.Spirit?Quote:
Doing it in C++ is, to say the least, not this easy (and yes, I'm completely aware of flex/yacc.)
The biggest complaint seem to be around that opinions are evil or the real world doesn't care about them.
Yes, I know, in the real world, you just have to bite it and do it.
I'm fully aware of this and if it would indeed some day be a requirement in a job, then yes, I would do it. Not willingly or happily but because the job required it.
Thankfully, programming is a hobby rather than a job for me, so I can freely ignore it (for now).
The other argument seem to be about A VS B - the advantages and disadvantages of the both. I agree. You have to use the right tool for the job. Especially in jobs.
And while I do agree on the topic, this is also why I like C++ - it can borrow and create strengths from other programming languages due to its flexibility. It doesn't support properties natively, but with some knowledge, I can emulate it.
Being a hobby as it is, I try to bend C++ around to the way I like things. Even if it costs some performance or if it's awkward. It's a hobby and a challenge and it allows me to stay with C++ instead of moving on to other languages.
Again, if I were in a job, I wouldn't try this if it's a waste of time or resources. If I'm given a NO, then I wouldn't do it. But for a hobby, I would definitely pursue it.
But the problem with the web is that it's a data format understood by browsers. And data formats aren't exactly executable code... if it were, then there'd be no need for browsers.Quote:
Originally Posted by zacs7
But if I would choose speed over portability, in my own opinion, it would be a yes.
Actually, I would like a library that handles endianess. Abstraction, without losing the flexibility-Quote:
Originally Posted by anon
This may have been a poor example, but I would like to be able to do it nevertheless. It makes me feel more control and grip over how things work.
Hmmm. I'd rather there was just some documentation instead.Quote:
Originally Posted by anon
Now I do agree with that. A language should not be safe out of the box (like C#), because it would put too much restriction on what you can do.Quote:
Originally Posted by Mario F.
As we have seen, C++ can be safe, and that's why I like it. It can be safe, it can be fast, and it doesn't put restrictions on what I can do.
If I know what I'm doing, then I should be allowed to do it. Hurray for C++.
Btw, a good question to this might be - what do I lose due to the strict security in place?Quote:
Originally Posted by Mad_guy
Due to the strict security, there is so much that I cannot do. That's probably the features that I "miss".
No (I don't really do C++ that much and by association Boost) - could you provide me with a code example? If it can accomplish the same thing as succinctly and clearly I would be very impressed and interested in it (and I will retract my earlier point about not being able to do it as easily.)Quote:
Originally Posted by CornedBee
That doesn't exactly answer my question, you're just saying "there's a lot I can't do, trust me."Quote:
Due to the strict security, there is so much that I cannot do. That's probably the features that I "miss".
What does this 'security' a VM (or similar) introduces inhibit you from doing, exactly? More importantly - why is this feature/idiom not expressible in another manner?
Pardon me for speculating, but do you know what CGI is and what it does? Some types of web sites will require interaction with the user -- if you so much as utilize form data -- and as Google wants to prove with Chrome, the web is becoming more and more like an application platform. It's not cute to ignore the possibility that you would need to write some perl or something for a website.Quote:
But the problem with the web is that it's a data format understood by browsers. And data formats aren't exactly executable code... if it were, then there'd be no need for browsers.
But if I would choose speed over portability, in my own opinion, it would be a yes.
And I really hope that you would choose an interpreted language for the web since it is much easier to use perl or php to interpret form data and draw pages on the fly.
I believe that was the point zacs was trying to make. But you did admit that every job has a tool ...
CGI scripts run on the server, so portabilty is not as much a concern as with client-side applications. Java has platform-independent (I know... JVM dependent) bytecode so that it can have multi-platform capability for client-side web applications, which is what I think was being implied.
Also, C and C++ can do CGI.
Yes, I do know what CGI (typically Perl) and PHP are.Quote:
Originally Posted by citizen
I've used PHP + mysql myself.
Well yes, to be honest, I'd rather use C++ for server-side applications rather than PHP or Perl, if I could make it work. Honestly, I don't know how because I haven't done it.
Mostly the reason is speed (native vs interpreted) and syntax (Perl syntax confuses me with all its operators and all that).
If it was a job, then PHP or Perl would probably be used instead, part due to it being easier and part being that it's platform independent.
But with server-side, it's not a 50+ OSes you have to worry about, though, unlike web pages.
Well, C++ supports... err... properties natively. Strange would be an OOP programming language not supporting data members.Quote:
this is also why I like C++ - it can borrow and create strengths from other programming languages due to its flexibility. It doesn't support properties natively, but with some knowledge, I can emulate it.
The confusion you are drawing here is that you expect C++ to follow the semantics of other programming languages like VB. But that's obviously not the case, and "properties" in C++ are implemented through public data members or accessors. In fact the term property is even usually non-existing in the C++ OOP-related lingo. "Data Member" is the term used, regardless how it is interfaced.
I can understand you liking the syntax offered by these programming languages. But you are better off using those languages instead of trying to emulate their behavior on a programming language that has a different syntax. And you should really know this by now. I'm surprised we are having this talk.
As for opinions... maybe they aren't evil. But opinions can be dangerous.
If I understand your earlier example correctly, it checks that all sorts of brackets in a string are balanced.Quote:
Originally Posted by Mad_guy
That would look something like this:
Not quite as concise as the functional version, but quite good.Code:namespace
{
rule<> term = // Term is ...
('(' >> term >> ')') | // ... parentheses around a term ...
('[' >> term >> ']') | // ... brackets around a term ...
('{' >> term >> '}') | // ... braces around a term ...
(~chset<>("()[]{}") >> !term); // ... or anything but those characters, followed potentially by another term.
}
bool is_balanced(const std::string &input)
{
return parse(input, term).full;
}
I never change, do I? ;-)Quote:
Originally Posted by Mario F.
Until I find a better language, I'm going to continue to try creating my own "special" language.
Oh yes, I'm fully aware. I remember how many times they've gotten me in trouble...Quote:
As for opinions... maybe they aren't evil. But opinions can be dangerous.
Off my head, I can think of 6 at least partially binary-incompatible OSs you may have to think of for server applications which are in common use for servers: Windows, Linux, FreeBSD, NetBSD, OpenBSD and Solaris.Quote:
But with server-side, it's not a 50+ OSes you have to worry about, though, unlike web pages.
I only know of Apache (typical Linux) and Windows Server. They seem to be the most popular if I'm not mistaken.
Those are web servers, not OSs (well, Windows Server is a Windows edition, but I think you mean IIS). Apache runs on any of the OSs I named.
Of course, for server applications there's Apache, IIS, lighttpd, five or six different servlet containers (Tomcat, Jetty, WebSphere, ...), and probably some more.
Pretty much all of those unices have binary compat packages for various platforms.Quote:
Originally Posted by CornedBee
The only place it can have a speed advantage is when you're using an x64 OS and the native app is written for 32bit. Otherwise, native apps are often designed to check if a processor feature exists and if it does, they use that feature when it's useful.Quote:
Originally Posted by zacs7
I will very much say a lot better than I expected! :]Quote:
Not quite as concise as the functional version, but quite good.
(nitpick: the example earlier was factor code, which is not a functional language but a stack based one, along the lines of Forth.)
Citation needed. Otherwise this is just nonsense.Quote:
The only place it can have a speed advantage is when you're using an x64 OS and the native app is written for 32bit.
I'm not quite sure what you mean by this. Do you mean the application determines at runtime if e.g. SSE4 instructions are available and use them? If so, I've never seen a compiler insert things like this into the code path - things like instruction availability (e.g. SSE/MMX) are generally speaking turned on by options at compiled time and if done that immediately makes it incompatible with processors that do not share the same specifics (you are likely to get illegal instruction errs or something of the sort.) If you are speaking of determining things like this at runtime then, again, citation needed.Quote:
Otherwise, native apps are often designed to check if a processor feature exists and if it does, they use that feature when it's useful.
(Unless of course you are talking about compile time, but determining such things is really more a function of your build system than anything I would imagine.)
mplayer does it. But the detection is hand-written, not compiler-supported. At startup, it detects the CPU capabilities and sets a few function pointers accordingly.
Intel compiler does this thingQuote:
If so, I've never seen a compiler insert things like this into the code path
It can compile 2 versions of the assembly code into the exe - 1 using some High-end processor intructions specified by compilation flag, another - using some basic set of instructions (for example any PIII) and adds the switch in the beginning of the main function - that selects the appropriate code to be working based on the CPU type installed
The source of this citation is me. But you can always prove me wrong if you want to.Quote:
Originally Posted by Mad_guy
I have seen it in media players, also I have seen it in the disassembly of games and other graphics applications.Quote:
Originally Posted by Mad_guy
Edit: This can be done with the cpuid instruction or by WinAPI function IsProcessorFeaturePresent(). cpuid instruction is often used in Windows applications because the WinAPI function for that was introduced in Windows NT, so this way it is compatible with older Windows versions.