CSC-SY

Foaad you haven't changed a bit when it comes to voicing opinions based on complete lack of information, have you?

 

1. C++ has enjoyed serious standardization efforts early upon its entrance to the industry, and was aimed to be free from single-vendor agenda from the very start. Disregarding literature, that is to say the first and second versions of TC++PL, ARM and D&E which were published in 1986, 1991, 1989 and 1994 respectively, the ANSI X3J16 C++ standardization committee was formed in 1989, and it became part of an ISO standardization effort in 1991, producing a complete draft in early 1995. The ISO C++ standard ISO/IEC 14882 was ratified in 1998, and a technical corrigendum was issued in 2003, while a new version of the standard, known informally as C++0x, is being actively developed.

 

2. <string.h> services which are part of ISO/IEC 9899:1990 (ISO C90) offer character string operations and the C++ <string> covered by ISO/IEC 14882 and canonically implemented by all production-grade compilers offers equivalent services (string length, concatentation, addition, searching, slicing, etc.) for std::string in a high-level manner. This allows the programmer to do things like these:

 

 

In addition, it is very easy to use searching, sorting, reversing, etc. facilties in <algorithm> via the iterator interface std::string provides. It also is possible to use low-level <string.h> routines on the chracter string representation of std::string returned by string::c_str() should the need to speak to low-level code arise.

 

3. It is extremely funny how you mention Microsoft's divergence from the adoption of the standard as an indication of lack of acceptance of the aforementioned C++ feature by the programmer community, as if nobody knows about Microsoft's long history in deliberate breaks of established standards on all grounds of computing.

 

4. Your last point is quite vague, but generally speaking I don't think that a practicing programmer needs to think too much before he realizes the benefits of static-typing, and what he needs to do to get the most out of it in programming languages that support it. The particular scenario of having definitions in scope offers the programmer the following benefits:
a. Better analysis by the compiler of all code that invoke it or depend on it
b. Early catching of particular types of errors (domain, range, numeric precision, etc.) and inconsistencies before the system goes online and disasters occur in the form of runtime errors
c. Higher optimization and better code generation chances because more information is available to the compiler.

 

The art of compiler writing has come a long way since late 80s, however it still is inadequte to offer really efficient implementations to some of the most powerful features of many programming languages alive. C++ itself has some language features (e.g. template exporting) customarily unsupported by many compilers, but things will be significantly better in the near future as huge advances are being made in compilers technology.. simultaneously to language oversimplification and library design replication trends.

class parent;

class child : public parent
{
...
};

class parent
{
...
};

Surprisingly you're the only one who think that about me
If I'm not sure about something I always state it clearly.

1. So I was right the C++ standard library came out years after the release of the c++ language itself, right?!
2. Read what?
Do I need to read about FORTRAN and COBOL too, no thanks.
3. I didn't say it's not MS fault, but a lot of programmers have to use their libraries, so the problem do exist.
4. Don't get me wrong, I'm a die hard fan of static-typing.

I really admire some of the features in C++ but I also hate the shortcomings and the complexity of it, so obviously I need a language that has all the features of C++ and lack all of the problems of it (which is what JAVA and C# claim to be), right now I didn't find a language that live up to that claim better than VB.NET

Wrong. The C++ standard library evolved as part of the language, and many of its facilities, particularly strings have been around since the very beginning.

Who said anything about Fortran or Cobol?
You thought that string manipulation in C++ boils down to twiddling with C-style character strings and used that as an indication of deficiency and age, and I told you that you are misinformed. Why are you escaping the context?
BTW, if you think that Fortran is still what it was in the 70s, then you're really encouraged to go read about current features the latest standard introduces.

Then please refactor what you want to say and try to say one thing at a time if you'd like to make a point.

And BTW, the idea you're demonstrating with the code snippet is irrelevent in general programming practice. If we discount the important fact that it often is the case that one needs to see the parent class before any children of it simply because the parent class defines the most general concept and prototypical services, real code is often comprised of several dozens of classes which aren't necessarily defined in the same compilation unit for many reasons e.g. several programmers working on the project, code available in binaries, "legacy" code that needs to be incorporated into current code, etc.

I thought you were talking about file streams, but here is a different case .
Since we're talking in IDE context -where you don't have to wary about building you're project since compiler and linker commands are given automatically- all C++ known IDEs provide the same facilitation, in MS-VC++6.0 you simply press F7 to build you project, but most of C++ programmers tend to write makefiles themselves for many reasons:
1. The makefile generated by some IDE is large, unnecessarily complicated and redundant, and relatively hard to modify manually.
2. Sometimes you have to write makefiles yourself when you're writing a cross-platform project for example, and you need to link against different libraries for each OS, or tweak it to adapt to variant environments.

As for the next topic (about class declaration) I think strontium90 explained it all.

I've been using qmake for this for the past 2 years or so for both GUI and non-GUI cross-platform projects management. It's a bliss.

This is exactly what I'm talking about because I do the same .
Although it seems the upcoming IDE Eclipse Qt promises to ease this process "With its general makefile generator it supports virtually all compilers to build C/C++ applications"*.
* A Sneak Peek at the Qt Eclipse™ Integration

Can't stand IDEs whatsoever.. clumsy things.. too many menus, toolbars and buttons cluttering the display.

I use Kate customarily for nearly all my programming work, coupled with DDD when a debugging need arises. I do Lisp programming with GNU Emacs and SLIME.

I'm talking about header files, and #include, these artifacts that shouldn't exist in a modern programming language.
No, not really, he talked about the benefits of static-typing, which I agree on, but he didn't explain why the heck we should declare class and function names before using them! (I can only think of one excuse, to eliminate one of the AST passes while compiling, which is really a lame excuse in today's standards).

I highly doubt that having all these in one application is what makes a programmer substantially more productive. It is a matter of effective use of available tools regardeless of how to use it.
Persoanally I don't want to see four or five stacks of toolbars with several dozens of toolbuttons, couple dock windows on the right, couple dock windows on the left, tabbed windows on the bottom, and a popup showing up every second to tell me what I have to write..
I like to use separate tools, and I'm not alone in this department. I do use a separate modelling tool, Umbrello, separate documentation viewers depending on what I'm hacking at, and a separate CVS client hangs around.. though I haven't gotten to use it too much yet.

It doesn't have to have them, does it?

For a start, error messages are in the realm of implementation-dependent aspects and mostly uncovered by the C++ standard. They don't have anything to do with the language or its standard library facilities.
But what strikes me in this sentence of yours is that you're suggesting that a "programming language is what the compiler implements". Based on this assumption, we can say that there is a MSVC++ programming language, an Intel C++ programmin language, a Borland C++ programming language, a GNU C++ programming language, a Comeau C++ programming language and so on, which not only is false, but also is ridiculous.
In my 3+ years of experience with GCC, I haven't encountered one error message that has confused me, in fact error messages and warnings it has issued have greatly helped me and have gained me more insight into my code. Please blame your lame compiler, and blame yourself for using it.

Okay, so physical tools to separate interfaces from implementations, in addition to its module-level logical separation (e.g. use of namespaces), is seen as "artifacts" by you, do you live in a world where all code gets written in one physical file and its interfaces are somehow magically revealed to its clients? Or is it that you do not rely on the concept of files at all in your programming practice?

The only solution to relieving the programmer of the task of mentioning what librariy facilities he'll be using, and I mean all facilities; system-level, third-party, and user-defined, is having the compiler or the interpreter (with non-trivial help from the operating system) to do this task for him ending up with tens of thousands of symbols available at the compiler's fingertips lest the programmer might, or might not, use any of these. And he'll invariably end up not using the overwhelming majority.

If we conisdered your argument that #include is an artifact, we cannot forget that Python uses an equivalent import mechanism, so does Java, and so is the using mechanism in C#. Are these languages not "modern" enough?

While we're at it, can you please define what constitutes a "modern programming language"?

I said a couple things about static-typing because your last point on your very first post was so vague that I explained it for myself in that way. Later you suggested a particular scenario, the class definition toy example, which I proved irrelevant.
In my experience, it usually is the case that you customarily use any facilities you are in charge to design only after designing and implementing them. After that, it doesn't really matter whether they're up there in the same source file as its clients or whether you assign it to a sepatate compilation unit and expose it to the client code via some interfacing means.

To make your point clear, you really need to present us with a real scenario (and not a toy example) of why having to declare facilities prior to its usage is actually hazardous, tedious and degrades overall code quality and programmer productivity.

Can you be more specific foaad ! Header files shouldn't be considered artifacts (I heard this word somewhere else ) -and I'm talking from a modern point of view- since Header Files (Interfaces - Protocols)/Source Files (Implementations - Services) philosophy literally correspond to Modularity, which is the Holly Grail of Software Engineering.
This topic was covered in details in a previous posting

forwarded declaration in general is not something related to speed-up compilation process only -since you're forwarding the compiler a hint about a variable existence with its name and type somewhere in code- as to forwarded class declaration, well, sometimes you must use it; your example wasn't quite satisfiable because it didn't give the necessity of forwarded class declaration its real importance, here's another one; consider two classes each of which is declared in its own header:
File: A.h

class A{
 B* f();
};

File: B.h

class B{
 A* f();
};

Notice that both classes A and B need the declaration of each other, so, putting #include "B.h" in A.h and #include "A.h" in B.h as a naive approach leads to circular dependency scenario.
The solution is by using forward declaration, so the previous script will become like this:
File: A.h

class B;
class A{
 B* f();
};

File: B.h

class A;
class B{
 A* f();
};

Even the previous example was trivial if we talk in large-scale projects context, where you have hundreds of headers files the thousands of dependency relations between different classes which increases the probability of unseen circular dependencies clashes hence forward declaration is extremely needed

No, I didn't say that, I've blamed C++ because I think this issue is probably due to the horrible syntax.
If it's the fault of MSVC++ compiler then I can't blame C++, but I really doubt it, so what I'm going to do is try to reproduce the problem and then try it on both compilers (MSVC++ and GCC) to see if it'll be any different.
Yes, I live in the land of milk and honey where the physical layout of the Classes inside the files doesn't mean a lot, if anything at all. Where the physical order of Classes inside the file have no effect at all, where you don't need to declare Classes and functions twice or three times to satisfy some weird limitation, where you can write a Class in one file and immediately be able to use it anywhere else in your project...
I know it's hard to believe but this place do exist
I'm not talking about referencing outside libraries.
The problem in C++ is that you have to use header files to export functionality even inside your project while in Java and C# you can access all of the public Classes immediately after coding them.
To reference a library in Java/C# you only need the library file (a DLL file for instance) while in C++ you need the library file and a header file.
That'll make a nice topic for a PhD thesis, don't you think

Now regarding c-style strings and "forwarded declaration" just please answer this question honestly:
Do you think you could write a real life application in C++ without the need to fiddle with c-style strings (including converting from and to them) and without using forwarded declaration?
No, Actually it's the greatest programmer sin at all "Writing the same code twice".
You mean you must use it in C++, right? (well, strontium90 might argue with that )
Because you do know that the example you gave would compile just fine in C# without the #include and without forwarded declaration.
Hence the usage of either #include or forward declaration in this case is considered an artifact. Actually there is a better word to describe it, 'cruft'.

Horribleness is in the eye of the beholder.
If your "horrible syntax" take is at the semicolon, or the equality operator like you said sometime ago, then please remember that your beloved "modern" programming languages have the exact same syntactical elements.
Can you perhaps present sounder arguments of what constitutes "complex syntax" without delving into drudgery?

Fortunately I know about these because I happen to be a Java programmer, and this also makes me realzie how dangerous the convenience of "writing a class in one file and immediately be able to use it anywhere else in your project" can get, because it is so easy to expose an implementation detail to clients which shouldn't know about them if you overlook your design.
Interface designing task is a fundamental programming activity that needs to be accomplished in parallel to any non-trivial programming task that has to build its own custom facilities, and every programming language supports interace design in a different way. Header files not only cater for interface design, but also for modular design because you can relocate complete definitions to header files.
OTOH, the issue of "forward declarations" or "distributed definitions" as you put it and insist on it have never plagued me, and being in the C++ programmer community I don't hear any such arguments form insiders. You're an outsider to this community, and it is apparent from your "criticisms" that you haven't programmed much in C++ beyond faculty courses, so I think it is normal to hear such irrelevant comments.

And so what? Isn't the mechanism there? Isn't it being used to introduce symbol names into the current scope? You're trying to escape the context again.

Why are you trying to compare 2 different categories of programming languages just on the basis that they all happen to offer a class construct and pose something that one offers as a "problem" in the one that doesn't? It is very obvious that definition resolution in the case of Java is left to the compiler, while in the case of C++ you have to say what you mean explicitly. And regardeless of that it always is a nice help to the reader of the code and to the programmer himself to hint at what the current source file uses, this particular point in both of the languages weren't designed in isolation of overall language design criteria.
And as I said in the above, to my knowledge C++ programmers who use the language day in and day out haven't expressed grief so serious about this "having to use header files" that it was deemed necessary to do something about it, so this again is irrelevant in the light of what really matters at the end of the day, and not a weak point, by any accounts, in the programming language.

That would make a rich material to pose hype at the helpless ones who have no idea about the software landscape and take the words from the mouths of biased men of industry players or complete ignorants instead of placing their judgement on conlcusions they draw out of their own research.

Yes, much of the C++ code I write doesn't use any of the "forward declarations" that were so frustrating to you in your Pascal and "horribly written" C++ assignments , because I design my code modularly both on physical and logicl levels, factoring out what my clients need to see, and what they do not, and easing future enhancement and maintenance work for myself. This commonly yields in a usage scenario that boils down to an inclusion of one header per logical group of services.I use std::string almost exclusively on "backend" code, and QString in the GUI interface code, and there do exist convenient conversions between the two.

In a previous post you suggested logic that says a programming language is what my compiler implements, and ran away from your own statement later presenting a "syntax complexity" excuse. Here you suggest that a declaration is the same as a definition.
I'm going to leave this at that, because I really cannot embed a C++ tutorial in a forum discussion thread in every post. In the end, I'm supposed to run a discussion on this level of technicality with people who do have the experience and know what they're talking about for this all to be worthwhile.
I just wish that you have presented one sound argument about the real weaknesses of C++ in your posts so far so that people could've learned something. So far you've presented none.

topic bookmarked for later reading.

How about the relevance of this statistic, huh? Everytime someone needs to pose as a serious guy who cites numbers comes up with this Sourceforge statistic as if it captures the entire software landscape. Do you think that I am an idiot? Or do you rely on that your readers may be idiots who don't know about the nature and lifetime of projects registered at Sourceforge?

Now do you think that big industry players are investing in C++0x because they have nothing better to do and because it is a dying language? Are C++ based programming tools and libraries still activelty being used and developed and more and more new systems are being designed and developed on top of it because the language is a thing of the past? Is C++ being used in large-scale distributed application development research because it is a fossil?

Besides, how can you so confidently say that the things foaad pointed at in this thread are "disadvantages" and that I am "defending disadvantages" when neither foaad nor you could still come up with real-life contexts of these conjectures that might be speaking for real problems? Do you think that the code snippet in the above or anything in the vein of toy examples is a valid demonstration of an argument against a programming language flaw in a general sense?

I do not believe that C++ is a perfect language, there's no such thing as a perfect language, there only is an appropriate language for a given task based on an array of considerations. However being the one who has used C++ the most among people who're discussing it here, the least that I expect is possessing information and experience before suggesting ideas because otherwise they may not go beyond unrealistic conjectures.
I asked for scenarios in the context of real-life code demonstrating those "disadvantages" and so far none of the "opponents" could come up with anything, this just questions the validity of points they've suggested and their ability to stand beside them.

At the end of the day, nodody's forcing you to use C++. If you cannot use it, don't, use whatever suits your mindset, your time, your applicaiton and the boss' quirks. You would gain little experience by bashing it, specially when you know so little about it, however you may lose some credibilty in the eyes of colleagues, if that means anything to you, should they realize that you don't know what you're talking about.

Hiding specifics and showing what really matters from both clients' and developers' point of view shouldn't be considered neither compared to "Writing the same code twice", talking about large scale projects where dozens of teams work together and they do need a high level of formality for coordination, developing third party libraries where it's necessary to hide the implementation and provide only the interfaces to customers ... common do I need to sort out all advantages of Modularity here?!

I introduced the example above to show the real necessity and use cases of forward class declaration because your above(r) example was misleading since it suggests that using forward class declaration is relatively stupid because it's merely related to the physical order of classes, afterwards, you claimed that it's designed, well, to lead the compiler because it's lazy!

First, it's pretty obvious that you can't through such judgments; people got bored with C++ so they started migrating to Java and here's a chart.
Second, real programmers know what they're doing, they DO need to harness memory, they DO NOT need some fancy wizard to collect their garbage, and obviously they'd rather a reliable OOP paradigm both conceptually and practically not a messed-up one with just a bright slogan "Everything is an Object!" on the cover.
Finally, between you and me, I really don't think that an experienced C++ programmer could migrate to Java by himself (unless his company changes its policy or he was forced to skim through it in some course at college!).

So everything I say is only my irrelevant personal opinion and everything you say is just facts!
I wish you were more objective, yes you know a lot more about C++ than we do, but you're deliberately covering for its mistakes, and I don't know why! I always like to point out the problems of anything that I use.

1- Syntax:
Yes I do hate semicolon, Curly-bracket etc... but that could be a matter of personal taste. (although It have been argued that it might be better to get rid off the semicolon)
BTW C# isn't my favorite language VB.NET is.
But the important thing here (and what I've been saying) is the extreme difficulty of parsing C++

2- Header files:
I've said it'll make you write the same code twice, and I strongly oppose that.

And that makes C++ better in that respect?! Oh no wait that makes them different! Yes definitely different, but nothing could make any language better than C++ in any aspect!
I can't see why it could be "dangerous"! Shouldn't encapsulation be enforced through access levels whether you're using Java, C# or C++ ?!

3- Forward declaration:
If no one should use it then why is it there?!
There is a couple of examples in wikipedia, but you probably gonna say they're irrelevant!

4- String:

Wouldn't be better to use only one kind of strings?!
Why is there a QString anyway?!
And you're saying that you don't use C-string?! I'm a little bit confused, don't you need it when using some C++ standard Library classes like ifstream.
And why they didn't use string instead of char* or at least why didn't they provide an overloaded version that takes string?!

--

So no one in the world could write an objective essay on what makes a good programming language?!
Then how could we improve programming languages if we can't know what is better and what is worse.
This is getting a little bit boring, don't you think? Anything you don't like is irrelevant!
Statistics about projects hosted at SourceForge.net are valid example and definitely provide some idea about the Open Source community.
And now you believe that big industry players' choices are based on what's best for the programmer?! Or they support what they think is the best programming language?!
Don't you think they have more important issues that they base their decisions on?! Like the code that they already have (which is literally their capital).
I don't think that we need to give detailed examples and pages of code! After all you can just give the title of what you're talking about.
It would be necessary to give an example if you're talking about something new something no one has ever pointed out before.
BTW I still owe you an example abut awful compiler errors.
So you could do by posting subjective and biased opinions.

And the only way to achieve Modularity is by using header files and writing method definition twice?!
I'll quote what the US democrat party have been repeating for the last few years "There is a better way"

Then what is its important purpose?! I mean what the programmer could benefit from it. Wouldn't it be better if the compiler figured it out on its own?!

Of course they won't migrate if it were up to them. They're not going to throw away their edge, they've worked for years to learn how to use C++ efficiently and now you want them to migrate to a language that anyone could learn in a few months and become as efficient in it as they are, I don't think so!