Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Future of C++

Reply
Thread Tools

Future of C++

 
 
kwikius
Guest
Posts: n/a
 
      08-06-2008
My hunch is my posts to clc++ are disappearing down a hole, so I post here
instead.

Future of C++ thread on clc++

"Abhishek" <(E-Mail Removed)> wrote in message
news:g77cj6$eij$(E-Mail Removed)...
> Hi All,
> This is a non-technical off topic post, so please excuse me for that.
>
> I wanted to understand from the Gurus of C++ out here about their opinion
> on
> the future of C++. I have spent eight plus years in the software industry
> working in applications programming on C++/ Windows. My current company is
> now moving big time towards Java/ J2EE based technologies. Most of the
> other
> companies which are writing application software are also moving (or have
> alreadt moved) to J2EE or to .Net. So is there no future for C++ in
> application software? What do the people on this group feel about it?
>
> I understand that Systems side and Embedded are still the areas where C++
> is
> being used well. But is that all? What do the people who have invested
> time
> and energy in C++ should do? Learn Java or C# because a significant
> majority
> of other developers (apparently) could not free the pointers and found
> garbage collector to be a great idea.
>
> Thoughts/ Suggestions/ Criticism?



AFAICS C++ is very much about a "craft" approach to software development.
For one It takes a long time to get good at it. Like any craftsman, say a
carpenter it costs. Once upon a time if you wanted a new door, you asked the
carpenter and he made you one to your spec. These days doors are all
standard sizes and you buy them off the shelf at a hardware superstore. A
similar situation applies with C++ and other languages in respect to
libraries. The modern trend is towards abstracting away the hardware. This
results in a loss of performance but much greater productivity, and
critically libraries which become unofficial standards within the language.
The classic example in C++ is GUI. Often newbies ask about the C++ GUI and
they are vaguely pointed off towards various libraries. In modern languages
there are usually one or two "standard" GUI libraries that everyone uses.

Because C++ is so expressive, if you start a new library ( or even
application ) then you are presented with a huge number of decisions. Do I
use templates or RTTI, Do I use Dll or static libs, Do I worry about cross
platform or target one. This all takes a long time and results in
fragmentation. In other less complicated languages, you don't have to worry
about these things. They have been solved or abstracted away. Hence
languages like Java, and Python have huge libraries because presumably they
are easier to write once in practise. The low level problems that confront
you in C and C++ are abstracted away.

That said C++ and C will be around a long time. For windows they will be
around as long as its around I guess, but I don't see there being as much
demand for C++ programmers.

regards
Andy Little





 
Reply With Quote
 
 
 
 
Pavel
Guest
Posts: n/a
 
      08-06-2008
kwikius wrote:
> My hunch is my posts to clc++ are disappearing down a hole, so I post here
> instead.
>
> Future of C++ thread on clc++
>
> "Abhishek" <(E-Mail Removed)> wrote in message
> news:g77cj6$eij$(E-Mail Removed)...
>> Hi All,
>> This is a non-technical off topic post, so please excuse me for that.
>>
>> I wanted to understand from the Gurus of C++ out here about their opinion
>> on
>> the future of C++. I have spent eight plus years in the software industry
>> working in applications programming on C++/ Windows. My current company is
>> now moving big time towards Java/ J2EE based technologies. Most of the
>> other
>> companies which are writing application software are also moving (or have
>> alreadt moved) to J2EE or to .Net. So is there no future for C++ in
>> application software? What do the people on this group feel about it?
>>
>> I understand that Systems side and Embedded are still the areas where C++
>> is
>> being used well. But is that all? What do the people who have invested
>> time
>> and energy in C++ should do? Learn Java or C# because a significant
>> majority
>> of other developers (apparently) could not free the pointers and found
>> garbage collector to be a great idea.
>>
>> Thoughts/ Suggestions/ Criticism?

>
>
> AFAICS C++ is very much about a "craft" approach to software development.
> For one It takes a long time to get good at it. Like any craftsman, say a
> carpenter it costs. Once upon a time if you wanted a new door, you asked the
> carpenter and he made you one to your spec. These days doors are all
> standard sizes and you buy them off the shelf at a hardware superstore. A
> similar situation applies with C++ and other languages in respect to
> libraries. The modern trend is towards abstracting away the hardware. This
> results in a loss of performance but much greater productivity, and
> critically libraries which become unofficial standards within the language.
> The classic example in C++ is GUI. Often newbies ask about the C++ GUI and
> they are vaguely pointed off towards various libraries. In modern languages
> there are usually one or two "standard" GUI libraries that everyone uses.
>
> Because C++ is so expressive, if you start a new library ( or even
> application ) then you are presented with a huge number of decisions. Do I
> use templates or RTTI, Do I use Dll or static libs, Do I worry about cross
> platform or target one. This all takes a long time and results in
> fragmentation. In other less complicated languages, you don't have to worry
> about these things. They have been solved or abstracted away. Hence
> languages like Java, and Python have huge libraries because presumably they
> are easier to write once in practise. The low level problems that confront
> you in C and C++ are abstracted away.
>
> That said C++ and C will be around a long time. For windows they will be
> around as long as its around I guess, but I don't see there being as much
> demand for C++ programmers.
>
> regards
> Andy Little


A couple of bare facts/observations with minimal comments:

1. A younger co-worker of mine left for Microsoft last week. What's
interesting, they took him to take part in writing their next generation
Visual Studio or whatever they will call it -- and it is going to be the
first version of it written wholly in C# (instead of C/C++, in which all
recent previous versions have been written). Maybe second next Windows
version will not be in C/C++ either?

2. I received the last issues of last professional C++ magazine I knew
(C/C++ User Journal) more than a year ago (I think). I then checked on
C++ Reports that I used to read much earlier just to learn it had been
dead for quite a while already. Was not very happy about it; this
newsgroup seems to be one of very few C++ dedicated resources.

I would not mind to read a civilized discussion about where C++ is
heading and why -- and I have some ideas of my own about it -- but not
sure if such discussion is an off-topic here or whether there is enough
interest. Also the topic may be quite flame-prone. Any opinions?

-Pavel
 
Reply With Quote
 
 
 
 
Stefan Ram
Guest
Posts: n/a
 
      08-06-2008
Pavel <dot_com_yahoo@paultolk_reverse.yourself> writes:
>2. I received the last issues of last professional C++ magazine I knew


Five years ago, I wrote:

http://www.purl.org/stefan_ram/pub/c..._extensions_en

 
Reply With Quote
 
Matthias Buelow
Guest
Posts: n/a
 
      08-06-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:

> To increase in emphasis on statically verifiable type safety. If you
> want type safety, you should be expressive. I believe being less
> expressive lead us to script programming.


I don't quite understand that statement. What do you mean? Static typing
and expressiveness in a language are two distinct concepts. C++ is in
some ways more expressive than C but not as expressive as Lisp (which is
a dynamically typed language). What's got one to do with the other?
 
Reply With Quote
 
kwikius
Guest
Posts: n/a
 
      08-06-2008
On Aug 6, 5:09*pm, Matthias Buelow <(E-Mail Removed)> wrote:
> (E-Mail Removed) wrote:
> > To increase in emphasis on statically verifiable type safety. If you
> > want type safety, you should be expressive. I believe being less
> > expressive lead us to script programming.

>
> I don't quite understand that statement. What do you mean? Static typing
> and expressiveness in a language are two distinct concepts. C++ is in
> some ways more expressive than C but not as expressive as Lisp (which is
> a dynamically typed language). What's got one to do with the other?


Wel heres my take on it.

If you have strong typing you can be more expressive in comfort
because errors in expressions will be caught by the compiler, whereas
dynamic typing postpones errors till runtime and it may take much
testing to try to locate all possible errors.

IOW the dynamic language is "expressive" of many things though some
are potentially incorrect, but the static typed language is
expressive, whilst being (arguably) proved correct prior to
execution.

regards
Andy Little
 
Reply With Quote
 
Pavel
Guest
Posts: n/a
 
      08-08-2008
kwikius wrote:
> On Aug 6, 5:09 pm, Matthias Buelow <(E-Mail Removed)> wrote:
>> (E-Mail Removed) wrote:
>>> To increase in emphasis on statically verifiable type safety. If you
>>> want type safety, you should be expressive. I believe being less
>>> expressive lead us to script programming.

>> I don't quite understand that statement. What do you mean? Static typing
>> and expressiveness in a language are two distinct concepts. C++ is in
>> some ways more expressive than C but not as expressive as Lisp (which is
>> a dynamically typed language). What's got one to do with the other?

>
> Wel heres my take on it.
>
> If you have strong typing you can be more expressive in comfort
> because errors in expressions will be caught by the compiler, whereas
> dynamic typing postpones errors till runtime and it may take much
> testing to try to locate all possible errors.
>
> IOW the dynamic language is "expressive" of many things though some
> are potentially incorrect, but the static typed language is
> expressive, whilst being (arguably) proved correct prior to
> execution.
>
> regards
> Andy Little


I am not sure one language is much more expressive than the other --
IMHO it is much more dependent on the style of use than the language
itself. I have seen quite understandable code in different Assemblers
and much more of inscrutable code in all possible languages even
including Python (although it is not too easy to write something
completely misleading in Python -- maybe only on purpose). But the "cost
of complete understanding" of a C++ program was always among the highest
for me -- often, I had to pre-process a source file to understand with
certainty what's coming from where. Consider this fragment:

int i = 0;
f(i);
myprint(i);

If it is written in Java (or C, for that matter), I can tell with some
certainty that myprint() receives 0 as an argument. But to tell
something about it in C++ I have to know whether f() takes a reference
or a value and, to make things even more fun, I never know which of
possible overloaded f's is called, -- not until I pre-process the code
and line up all possible fs. IDE with a browser may help somewhat but as
it jumps to the definition or declaration of f() it dislocates my focus
-- quite an overkill especially if the only purpose of my review is to
track down where that 'i' could get changed.

To review C++ code with a reasonable speed (as compared to Java, C or
even PL/SQL code of the same functional complexity -- even FORTRAN), one
would have to put a lot of trust to the people who wrote it. I
personally got burned too many times and I do not trust anymore so I
have to bite the bullet and jump the sources back and forth like crazy.
Which brings us back to the productivity question.. it should not come
at a surprise that in a project of any considerable size a developer
spends more time reading, researching and understanding the code than
changing it. From this perspective, unexpectedly, C is so much more
productive than C++ (plus, an equivalent C program usually compiles 10
times faster than C++ -- because "smart guys" like inserting templates
and meta-programming wherever they don't need them or at least they will
include a couple of "cool" headers -- so a change/compile/debug
iteration in C is much shorter than in C++).

Not sure how to break this vicious cycle -- it seems the more powerful a
language is the more it gets abused and the more it hurts the
productivity. Java is getting there too, BTW, and C# is almost there
already (see version 3.0 of the language). I, for one, have never been
more productive than when I wrote in FORTRAN 66 in my University -- and
I can still easily read those subroutines after 25 years. I wish I could
say it of my C++ code after 25 years..

-Pavel
 
Reply With Quote
 
kwikius
Guest
Posts: n/a
 
      08-08-2008
Pavel wrote:
<...>

> I am not sure one language is much more expressive than the other --
> IMHO it is much more dependent on the style of use than the language
> itself. I have seen quite understandable code in different Assemblers
> and much more of inscrutable code in all possible languages even
> including Python (although it is not too easy to write something
> completely misleading in Python -- maybe only on purpose). But the "cost
> of complete understanding" of a C++ program was always among the highest
> for me -- often, I had to pre-process a source file to understand with
> certainty what's coming from where. Consider this fragment:
>
> int i = 0;
> f(i);
> myprint(i);
>
> If it is written in Java (or C, for that matter), I can tell with some
> certainty that myprint() receives 0 as an argument. But to tell
> something about it in C++ I have to know whether f() takes a reference
> or a value and, to make things even more fun, I never know which of
> possible overloaded f's is called, -- not until I pre-process the code
> and line up all possible fs.


Deducing automatically which function to call based on its arguments is
certainly an important feature in making C++ what I would call
"expressive". Its obviously not available in C. (I cant remember if
there is an overloading scheme available in Java, but even if it is it
would be of limited use because Java is OOP and function overloading is
actually about expressions which are not part of the OOP vocabulary.
Note that Fortress Suns next generation language incorporates
overloading based on various constructs as well as many other familiar
general constructs that have been available in C++ for a long time)

I would prefer if the algorithm regarding which function is actually
called was more rigorously and concisely expressed itself. In general in
C++ you kind of hope that the expected version of a function will be
used, and thats arguably far from ideal (You can't blame C++ for its
complex and loose approach to overloading. C++ is essentially quite a
nice expressive language mixed up with C. The fact that its mixed with C
is AFAIK a major reason for its success, but also the source of many of
its problems (I think this is said somewhere by Bjarne Stroustrup)

In fact I am currently trying to find that simple algorithm regarding
expressions and their relation to types. Its important enough IMHO to be
basis of a whole language. Programming is essentially about writing
expressions. You want conciseness, intuitiveness and clarity with
generality. I am very grateful to C++ for showing me these things and
can now sit back in my armchair and see if and how to improve how C++
goes about it(but in another language, C++ is already seriously
overweight with new stuff) Standing on the giants shoulders and all
that. So can you have expressiveness, but also precision. C++ shows the
problem but not the full solution.

BTW. Note that in the example you gave, because the argument is an int
IOW an inbuilt type there are only a few functions that can be
called(unless you have brought in other namespaces!). If the argument is
a class (a user defined type or UDT) then the list grows large and if
the class involves templates the list grows even larger.

<...>

because "smart guys" like inserting templates
> and meta-programming wherever they don't need them or at least they will
> include a couple of "cool" headers -- so a change/compile/debug
> iteration in C is much shorter than in C++).


Unfortunately I am one of those guys

http://sourceforge.net/projects/quan

I wouldnt be without quan. It heavily used everyday in my work (though I
dont maintain publicaly any more) and currently C++ is the only language
it can be written practically in.


> Not sure how to break this vicious cycle -- it seems the more powerful a
> language is the more it gets abused and the more it hurts the
> productivity. Java is getting there too, BTW, and C# is almost there
> already (see version 3.0 of the language). I, for one, have never been
> more productive than when I wrote in FORTRAN 66 in my University -- and
> I can still easily read those subroutines after 25 years. I wish I could
> say it of my C++ code after 25 years..


Its an interesting problem. All succesful languages grow more complex. I
guess there is a solution, which is the one taken by Haskell... "Avoid
success at all costs". Its an enigmatic motto, but after many years I
finally understand it. I think its the best motto... if you want to stay
expressive

regards
Andy Little
 
Reply With Quote
 
Bo Persson
Guest
Posts: n/a
 
      08-08-2008
Pavel wrote:
> kwikius wrote:
>> On Aug 6, 5:09 pm, Matthias Buelow <(E-Mail Removed)> wrote:
>>> (E-Mail Removed) wrote:
>>>> To increase in emphasis on statically verifiable type safety. If
>>>> you want type safety, you should be expressive. I believe being
>>>> less expressive lead us to script programming.
>>> I don't quite understand that statement. What do you mean? Static
>>> typing and expressiveness in a language are two distinct
>>> concepts. C++ is in some ways more expressive than C but not as
>>> expressive as Lisp (which is a dynamically typed language).
>>> What's got one to do with the other?

>>
>> Wel heres my take on it.
>>
>> If you have strong typing you can be more expressive in comfort
>> because errors in expressions will be caught by the compiler,
>> whereas dynamic typing postpones errors till runtime and it may
>> take much testing to try to locate all possible errors.
>>
>> IOW the dynamic language is "expressive" of many things though some
>> are potentially incorrect, but the static typed language is
>> expressive, whilst being (arguably) proved correct prior to
>> execution.
>>
>> regards
>> Andy Little

>
> I am not sure one language is much more expressive than the other --
> IMHO it is much more dependent on the style of use than the language
> itself. I have seen quite understandable code in different
> Assemblers and much more of inscrutable code in all possible
> languages even including Python (although it is not too easy to
> write something completely misleading in Python -- maybe only on
> purpose). But the "cost of complete understanding" of a C++ program
> was always among the highest for me -- often, I had to pre-process
> a source file to understand with certainty what's coming from
> where. Consider this fragment:
> int i = 0;
> f(i);
> myprint(i);
>
> If it is written in Java (or C, for that matter), I can tell with
> some certainty that myprint() receives 0 as an argument. But to tell
> something about it in C++ I have to know whether f() takes a
> reference or a value


Using a better name than f() would help a lot!

Hardly a language problem.

>
> To review C++ code with a reasonable speed (as compared to Java, C
> or even PL/SQL code of the same functional complexity -- even
> FORTRAN), one would have to put a lot of trust to the people who
> wrote it. I personally got burned too many times and I do not trust
> anymore so I have to bite the bullet and jump the sources back and
> forth like crazy. Which brings us back to the productivity
> question.. it should not come at a surprise that in a project of
> any considerable size a developer spends more time reading,
> researching and understanding the code than changing it. From this
> perspective, unexpectedly, C is so much more productive than C++
> (plus, an equivalent C program usually compiles 10 times faster
> than C++ -- because "smart guys" like inserting templates and
> meta-programming wherever they don't need them or at least they
> will include a couple of "cool" headers -- so a
> change/compile/debug iteration in C is much shorter than in C++).


As usual, "You can write bad programs in any language".

Here is an example of what you can do in C
(http://www.ioccc.org/2004/hoyle.c), hardly 10 times easier to read
than anything else.

#include <stdio.h>
#include <stdlib.h>
#include <math.h>

#define _ ;double
#define void x,x
#define case(break,default) break[O]:default[O]:
#define switch(bool) ;for(;x<bool;
#define do(if,else) inIine(else)>int##if?
#define true (--void++)
#define false (++void--)

char*O=" <60>!?\\\n"_ doubIe[010]_ int0,int1 _ Iong=0 _ inIine(int
eIse){int
O1O=!O _ l=!O;for(;O1O<010;++O1O)l+=(O1O[doubIe]*pow(eIse,O1O));return
l;}int
main(int booI,char*eIse[]){int
I=1,x=-*O;if(eIse){for(;I<010+1;I++)I[doubIe-1]
=booI>I?atof(I[eIse]):!O
switch(*O)x++)abs(inIine(x))>Iong&&(Iong=abs(inIin e(x
)));int1=Iong;main(-*O>>1,0);}else{if(booI<*O>>1){int0=int1;int1=int0-2*Iong/0
[O]switch(5[O]))putchar(x-*O?(int0>=inIine(x)&&do(1,x)do(0,true)do(0,false)
case(2,1)do(1,true)do(0,false)6[O]case(-3,6)do(0,false)6[O]-3[O]:do(1,false)
case(5,4)x?booI?0:6[O]:7[O])+*O:8[O]),x++;main(++booI,0);}}}

Bo Persson


 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      08-08-2008
On Aug 8, 10:32 am, kwikius <(E-Mail Removed)> wrote:
> Pavel wrote:
> <...>


> > int i = 0;
> > f(i);
> > myprint(i);

>
> > If it is written in Java (or C, for that matter), I can tell
> > with some certainty that myprint() receives 0 as an
> > argument. But to tell something about it in C++ I have to
> > know whether f() takes a reference or a value and, to make
> > things even more fun, I never know which of possible
> > overloaded f's is called, -- not until I pre-process the
> > code and line up all possible fs.


That's not preprocessing. Preprocessing is something else
entirely (which C++ inherits from C). And preprocessing is a
problem: if myprint (or f, for that matter) is a macro, who
knows what the above means.

One of the evolutions of C++ with respect to C is to reduce the
need for macros---good C++ makes very, very limited use of
macros. So you should have less problems with the above in C++
than in C.

> Deducing automatically which function to call based on its
> arguments is certainly an important feature in making C++ what
> I would call "expressive".


Like everything which increases expressivity, it can be abused.
I'm tempted to say that if myprint is overloaded, and it matters
which instance of myprint is called, overloading has been
abused.

Of course, Pavel is right about one thing: the last line in the
above could be the declaration of a variable (which would be a
duplicate declaration, but if i were in some different scope, it
would be a legal declaration). IMHO, this goes beyond
"expressivity", and is frankly a defect. But it's one we
inherited from C, and the same ambiguity exists in C. (All
that's needed, in both cases, is that myprint is defined by a
typedef somewhere. And that's one ambiguity that isn't present
in Java.)

> Its obviously not available in C.
> (I cant remember if there is an overloading scheme available
> in Java, but even if it is it would be of limited use because
> Java is OOP and function overloading is actually about
> expressions which are not part of the OOP vocabulary.


Never the less, Java's overloading is almost identical to that
of C++. If it's less of an issue, it's only because Java
doesn't support as many implicit conversions (another thing C++
has mainly because of C compatibility).

> Note that Fortress Suns next generation language incorporates
> overloading based on various constructs as well as many other
> familiar general constructs that have been available in C++
> for a long time)


> I would prefer if the algorithm regarding which function is
> actually called was more rigorously and concisely expressed
> itself. In general in C++ you kind of hope that the expected
> version of a function will be used, and thats arguably far
> from ideal (You can't blame C++ for its complex and loose
> approach to overloading. C++ is essentially quite a nice
> expressive language mixed up with C. The fact that its mixed
> with C is AFAIK a major reason for its success, but also the
> source of many of its problems (I think this is said somewhere
> by Bjarne Stroustrup)


I don't know if Stroustrup said it, but it's certainly true.
The biggest single problem in C++ is the declaration syntax,
which is inherited from C. To many implicit conversions
(especially lossy conversions) would be another inherited
problem. (And it's too many implicit conversions which makes
overload resolution so complicated.)

> BTW. Note that in the example you gave, because the argument
> is an int IOW an inbuilt type there are only a few functions
> that can be called (unless you have brought in other
> namespaces!).


Or you have classes which have non-explicit constructors which
take a single integral type.

> If the argument is a class (a user defined type or UDT) then
> the list grows large and if the class involves templates the
> list grows even larger.


> <...>


> because "smart guys" like inserting templates


> > and meta-programming wherever they don't need them or at
> > least they will include a couple of "cool" headers -- so a
> > change/compile/debug iteration in C is much shorter than in
> > C++).


On the other hand, because of C++'s better type checking and
encapsulation, you normally need a lot less change/compile/debug
cycles than you would with C. Globally, development times in a
well run project are significantly less in C++ than in C (or in
Java, for that matter).

> > Not sure how to break this vicious cycle -- it seems the
> > more powerful a language is the more it gets abused and the
> > more it hurts the productivity.


That's why you need a development process, and to pay attention
to software engineering issues. Good code review can do wonders
in this regard. Greater expressivity does allow more ways of
screwing things up, but it also allows more effective solutions.
The trick is to manage things so you get the benefits without
the costs.

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      08-08-2008
On Aug 8, 10:46 am, "Bo Persson" <(E-Mail Removed)> wrote:
> Pavel wrote:


> > I am not sure one language is much more expressive than the other --
> > IMHO it is much more dependent on the style of use than the language
> > itself. I have seen quite understandable code in different
> > Assemblers and much more of inscrutable code in all possible
> > languages even including Python (although it is not too easy to
> > write something completely misleading in Python -- maybe only on
> > purpose). But the "cost of complete understanding" of a C++ program
> > was always among the highest for me -- often, I had to pre-process
> > a source file to understand with certainty what's coming from
> > where. Consider this fragment:
> > int i = 0;
> > f(i);
> > myprint(i);


> > If it is written in Java (or C, for that matter), I can tell with
> > some certainty that myprint() receives 0 as an argument. But to tell
> > something about it in C++ I have to know whether f() takes a
> > reference or a value


> Using a better name than f() would help a lot!


> Hardly a language problem.


Yes and no. It's only a fragment; let's expand it some:

int i = 0 ;

void
myFunction()
{
f( i ) ;
myprint( i ) ;
}

Now throw in a "typedef double myprint;" before the first line.
Rather changes things, don't you think?

No matter how you consider it, the declaration syntax of C is a
mistake. A mistake which C++ inherits. It's the price we pay
for C compatibility.

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
The Future of Voice Communication @ BonaFideReviews Silverstrand Front Page News 0 09-27-2005 01:47 PM
Microsoft Windows and the future of Firefox? Victor Firefox 19 06-12-2005 02:04 AM
future of high-speed cable modems? Midnight Java Junkie ASP .Net 0 06-20-2004 06:58 AM
Future Considerations Mr. Garrett Hord Microsoft Certification 1 01-09-2004 06:43 PM
Does EIGRP have a future? Brad Hill Cisco 6 01-07-2004 04:19 PM



Advertisments