Board index » kylix » Re: The future..

Re: The future..


2004-01-24 11:09:49 AM
kylix2
Quote
I believe the future lies with gadgets and they will run Linux embedded
or perhaps not embedded (should be capable). All the top gadget
producers are working on a standard see
But thats just the point. The gadgets coming out are so diverse that
its really impossible to create a standard. Sun and m$'s "one size
fits all" really dont apply in this space. You need a development
platform environment as flexible and lean as possible. That's why
C/C++ does and will continue to for a long long time own these
emerging devices.
These a great times to be a C++ developer :)
 
 

Re:Re: The future..

Quote
positioned (xplatform and j2ME has improved dramaticlly), and C++. I think
Borland is pursuing the right course with Builder X. They have lost their
dominence in the Java IDE field (it is hard to compete with free, though
JBuilder is still the best IDE right now), so new markets are in order.

What is j2me good for besides building 3rd rate games running on
{*word*99}py phones? Have you ever tried building a real app in it? I have
and it sucks. The API is so crude and provides no access to the
underlying hardware which is critical in a space as diverse as the
emerging devices space.
 

Re:Re: The future..

Quote
I agree with your message except for the last part. C and C++ are two
distinct languages. C++ doesn't cover the C99 specs. C is weak typed and C++
is strong typed. You can use C++ perfectly well for application development
due to the existence of abstraction layers like STL, boost, VCL, wxWindows,
Qt, MFC and Nokia Series60 or UIQ (for Symbian) etc.


Peter


well C++ is fine and dandy on a desktop but try using it in all its
glory on symbian or the palm platform. I tried using the STL and
string classes in my app and it blew up my code size. You can use C++
but things like virtual functions and the STL make the code to large
and too slow for today's PDA's/Phones. C is fine for developing
PDA/Phone apps. Too bad with Symbian you dont even have the choice to
use C. You have to use their bizarre and inconsistent C++ library.
Palms C base API is so much easier to use. If you want to use C++
there's always POL. A fine MFC type library for the palm.
 

{smallsort}

Re:Re: The future..

Quote
some low level functionality that C or C++ affords us quite well. C++ is
not nearly as strongly typed however as say Java or Delphi. It can be, if
Why is C++ not as strongly typed as java? Unless you are throwing
void pointers around C++ is pretty darn strongly typed.
 

Re:Re: The future..

Quote
Struts cannot contain methods for one thing, another is the way that they
Yes they can
Quote
are instantiated and destroyed. Objects have scope and
constructors/destructors which defines instantiation and the cleanup of
that Object. If you use a struct, then the construction and deallocation is
left up to however it is referenced and in whatever units it is used.
What are you talking about. Even in the days of "C" you could declare
a struct on the stack. if you dynamically allocate the struct then
you have to free it.
Quote
It
is very easy to pass a struct around in serveral units and lose track of
where the original pointer was allocated to initialize the structure for
use. Classes or Objects can be abused in like manner (pointers to Pointers
of Objects), but this is a no-no from the world of OOP and Class/Object
structure.

Boost::scoped_ptr or use copyable objects and dont pass pointers
around. At least with C++ you have the choice.
Quote
The fact that structs is not self contained and has no constructor nor
deallocation mechanims within the structure, makes it quite different from
a class/object, IMHO.

Sure it does. As stated, the only difference between a class and
struct in C++ is stuff is public by default in a struct.
Quote
There is alot of free hand allowed in C++ that would not be allowed in a
more OOP paradigm. The freedom to mix C and C++ is exactly what I have in
mind. I just used a struct as an example, BTW. But it fits as it seems you
I see this as a strength. Not everything has to be an object. Being
boxed into one way of doing things is exaclty why I cant stand java.
 

Re:Re: The future..

Quote
And what of all of the new cellphones and PDAs that are running Linux?
Well motorola dropped out of symbian consortium and announced they
will be creating linux phones. They are creatinbg m$ smartphones to.
Just hedging their bets I figure.
The largest market in the world is China and they have stated publicly
that all phones will have to run some form of open source software.
As far as I know that pretty much narrows it down to linux.
 

Re:Re: The future..

Quote
Servers using Windows also grew, rising 10.3 percent to $3.4 billion, IDC
Yeh and in the same time period, linux servers grew like 30%. Thats
probrably just the linux servers using a license. The whole market is
growing amd m$ is losing overall share to linux.
 

Re:Re: The future..

Quote
It is sold on a per seat basis with copying, modifying, etc. prohibited. In
fact, I'm not sure how it can even be reconciled with the GPL. Some of the
They would have to turn over kernel modifications but they do not have
to turn their custom developed apps that run on it.
 

Re:Re: The future..

Quote
I do feel for those who are betting their futures on a true xplatform
DOT.NET however.

I read the patent section on the mono site and it's a little scary.
Their solution is to just "rip out" the offending API's when m$ comes
a callin. It doesnt really seem like they thought it out completely.
Typical geeks :)
I mean why even both porting winForms and ado.net when they already
have better solutions in the open source world? I like the idea of
having a portable CLI that supports multiple languages and creates
standard calling conventions and basic types.
 

Re:Re: The future..

Quote
I am not 'syntaxtically' C++ developer so there would be a learning
curve. I would prefer the Delphi,Java,C#,PHP language if I could help it.

If you stay away from the pitfalls, C++ is actually a really nice
language and very easy to use. Just use the subset you are
comfortable with.
While I use the STL, I dont feel comfortable writing my own templates.
So I dont.
Dont use printf, sprintf, fopen, fwrite, etc. use streams. They are
typesafe.
I dont use const because I dont feel the benefit outweighs have to
cast it away all the time.
The big myth is you have to use pointers everywhere. Not true. I
hardly ever use pointers (well except when interacting with the VCL)
anymore since you can copy objects with 0 code or use references.
when you do have to dynamically allocate objects, use scoped pointers
to destroy them when every reference to the pointer goes out of scope.
Most of the time, if the compiler compiles my code it just works.
It's pretty cool.
 

Re:Re: The future..

Mike Margerum wrote:
Quote
>And what of all of the new cellphones and PDAs that are running Linux?
Well motorola dropped out of symbian consortium and announced they
will be creating linux phones. They are creatinbg m$ smartphones to.
Just hedging their bets I figure.

The largest market in the world is China and they have stated publicly
that all phones will have to run some form of open source software.
As far as I know that pretty much narrows it down to linux.
Yep, but JQP has just informed us all that no one will be selling their
products to China. Well, at least he got it half right. As a Windows only
programmer, he will not be able to. :)
 

Re:Re: The future..

Mike Margerum wrote:
Quote
>positioned (xplatform and j2ME has improved dramaticlly), and C++. I think
>Borland is pursuing the right course with Builder X. They have lost their
>dominence in the Java IDE field (it is hard to compete with free, though
>JBuilder is still the best IDE right now), so new markets are in order.
>
What is j2me good for besides building 3rd rate games running on
{*word*99}py phones? Have you ever tried building a real app in it? I have
and it sucks. The API is so crude and provides no access to the
underlying hardware which is critical in a space as diverse as the
emerging devices space.
Yes we are building now J2ME programs for PDAs, using Jeode, not the Sun
version.
I agree that the base J2ME from Sun leaves some holes. But look at something
like Jeode and the Mokia J2ME chips for a better understanding of a much
more rich and powerful J2ME than the generic one offered by Sun. This is
the way most small electronic devices are going. They are building their
own Java runtimes and JITs or native compiled Java, or using one developed
especially for this field, or they are using Java Chips.
The problem with C/C++ is that compilers for all of these different devices
and chips must be built and maintained. As long as the compile options are
there, certainly nothing wrong with the C/C++ option.
However, many companies have reported that they would rather use a GCed
language. If your Cell Phone or PDA has a memory leak and crashes, not many
options here.
Of course the ultmitate task is always choosing the right tool for the task
at hand, whether that be Java, C++, or something else.
 

Re:Re: The future..

Quote
I agree that the base J2ME from Sun leaves some holes. But look at something
like Jeode and the Mokia J2ME chips for a better understanding of a much
more rich and powerful J2ME than the generic one offered by Sun. This is
the way most small electronic devices are going. They are building their
own Java runtimes and JITs or native compiled Java, or using one developed
especially for this field, or they are using Java Chips.

yes but you still have that very crude GUI layer and very limited data
store access. How Do i for example integrate with the built in PIM
apps? what if i want to integrate with the camera API, the voice
recording API, SMS, the list goes on and on. Companies like nokia
have added on to the j2me to allow some of these things but in non
standard ways which was the whole point of using java to start with
right? Why cant there be a standard set of C++ classes to code by for
phones/pda's? Because noones done it yet. Only reason.
Quote
However, many companies have reported that they would rather use a GCed
language. If your Cell Phone or PDA has a memory leak and crashes, not many
options here.

The GC was exactly what killed me. I was running out of memory
because the GC wasn't kicking in properly. worse yet, when it did, i
had 30 second delays in my app.
The lack of pointers on a PDA/Phone is killer when you have tons of
data in recordStores. I just want to lock a handle to a record and
access it through a pointer. It's already in memory. With java, I
had to copy it into a byte array and the turn that into a string
,allocating the memory effectively 3 times. I have to plow through
thousands of packed records at time with sub second response times.
Java just don't cut it.
Quote
Of course the ultmitate task is always choosing the right tool for the task
at hand, whether that be Java, C++, or something else.

Agreed. With my C++ hammer, everything looks like a nail :)
Seriously, the only language that has come along that has interest me
is python because it is the perfect complement to C++.
 

Re:Re: The future..

Quote
Yep, but JQP has just informed us all that no one will be selling their
products to China. Well, at least he got it half right. As a Windows only
programmer, he will not be able to. :)

:)
China's already playing hardball. They are coming up with a competing
standard to 802.11 and if you want to sell wireless hardware there you
have to implement it and worse yet pay royalties to one of 6 "offical"
companies with rights to the IP. They dont respect anyone elses IP
but we are supposed to honor theirs. Things are gonna get real
interesting over there.
 

Re:Re: The future..

Mike Margerum wrote:
Quote
>Struts cannot contain methods for one thing, another is the way that they
Yes they can

>are instantiated and destroyed. Objects have scope and
>constructors/destructors which defines instantiation and the cleanup of
>that Object. If you use a struct, then the construction and deallocation
>is left up to however it is referenced and in whatever units it is used.
What are you talking about. Even in the days of "C" you could declare
a struct on the stack. if you dynamically allocate the struct then
you have to free it.

That was what I was referring to, dynamic allocation.
Quote
>It
>is very easy to pass a struct around in serveral units and lose track of
>where the original pointer was allocated to initialize the structure for
>use. Classes or Objects can be abused in like manner (pointers to Pointers
>of Objects), but this is a no-no from the world of OOP and Class/Object
>structure.
>
Boost::scoped_ptr or use copyable objects and dont pass pointers
around. At least with C++ you have the choice.

That is the problem, I have seen much too often in the past where I worked
more closely with C/C++. Pointers being passed around everywhere and it is
very easy to lose track where the first allocation took place.
Yes, I realize this is bad code design in the first place, but it is common
and with C or C++ easy to get away with in coding and at runtime, hard to
trace down and debug.
Quote
>The fact that structs is not self contained and has no constructor nor
>deallocation mechanims within the structure, makes it quite different from
>a class/object, IMHO.
>
Sure it does. As stated, the only difference between a class and
struct in C++ is stuff is public by default in a struct.

I have been so informed.. Admmitedly, I was ignorant of the fact that C++
structs could contain methods.. See my follow up later :).
Quote
>There is alot of free hand allowed in C++ that would not be allowed in a
>more OOP paradigm. The freedom to mix C and C++ is exactly what I have in
>mind. I just used a struct as an example, BTW. But it fits as it seems you

I see this as a strength. Not everything has to be an object. Being
boxed into one way of doing things is exaclty why I cant stand java.
Well, different strokes for different folks. I actually like the OOP
structure MUCH BETTER.. IT enforces better use of design.
The only exception is when dealing with primitive types. Then Object
allocation can be a waste of precious memory (bet I get attacked on that
one <G>).
Please note, I am not against either C or C++. They both have their places
and especially when doing low level work, they are a better option than
Java. For general Networked based development and/or general application
development, Java is better overall, IMHO, since it inherently enforces
structure and it lends itself to much more rapid development and
deployment. Of course if you add xplatform, Java definitely wins. C is
portable as long as you can avoid GUI and processor specific instructions.